.NET HTTPS connections timeout on SNI TLS Warning


Recently, a handful of folks have emailed me complaining that some HTTPS sites cannot be reached by their .NET programs or from any program when Fiddler is configured to decrypt traffic. Notably, these users only have problems when running on Windows Vista or later.

So, what’s going on?

When I need to troubleshoot issues that occur below Fiddler, NetMon is a good choice. Taking a look at the HTTPS handshake, the problem is immediately apparent:

Netmon Screenshot showing 01 70 bytes

This server is returning a TLS Alert at the beginning of the handshake. The alert severity is 1 meaning WARNING, and the code is 112 (0x70) which is the unrecognized_name alert. With this alert, the server is indicating that it does not recognize the hostname provided by the server’s Server Name Indication TLS extension. This warning is only encountered when the client is running on Windows Vista and later because the SChannel HTTPS stack on Windows XP doesn’t support SNI and other TLS extensions.

The server’s behavior is explicitly not recommended according to the standards:

If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication.

The server’s behavior is problematic because the .NET Framework’s HTTPS implementation is unable to ignore this warning and it is not able to automatically “fail over” to an earlier protocol version, leading to a  lengthy delay (~80 seconds) before a connection failure in Fiddler or other .NET applications.

To enable Fiddler to workaround sites with this problematic configuration, click Rules > Customize Rules. Scroll to the OnBeforeRequest method and add the following block:

if (oSession.HTTPMethodIs("CONNECT") && oSession.HostnameIs("BuggySite.com"))
{
  oSession["x-OverrideSslProtocols"] = "ssl3";
  FiddlerApplication.Log.LogString("Legacy compat applied for inbound request to BuggySite.com");
}

Save the script and this block will force Fiddler to handshake with the server using only the SSLv3 protocol, which does not send TLS extensions, avoiding the problem.

To apply the same workaround in your .NET application without Fiddler, use the same trick: ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;

 

-Eric

Comments (2)

  1. Magnus Holmgren says:

    Why, exactly, is the implementation unable to ignore the warning? Why does it just sit there instead of terminating the handshake right away? It's almost as if it becomes confused for a moment, misses the certificate that arrives directly afterwards, and continues waiting for it until it times out.

    EricLaw: Sorry, I don't have access to the source in question, so I'm not sure why the behavior exists this way. Given that the standard explicitly suggests not sending a warning here, it seems that buggy behavior like this isn't entirely unexpected.

  2. Per "Bulletproof SSL and TLS", a Java client encountering a server like this will abort the connection with an exception: "javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name"

Skip to main content