Windows SSL/TLS update for secure renegotiation

6 Comments

Couple of weeks ago Microsoft released an update to the SSL/TLS stack to implement secure renegotiation as described in RFC 5746. The Microsoft KB article describes the three settings controlling the behavior of the patch, but a bit more detail can be useful.

A bit of background first. TLS extensions are a method of extending the TLS protocol without having to change the specification of the core protocol and are described in RFC 4366. It is defined as arbitrary extra data that can be appended to the ClientHello and/or ServerHello messages (which are the first messages sent by each side). Servers are supposed to ignore data following the ClientHello if they don’t understand it.

Since the TLS extensions were not a formal RFC in the past, some server implementations were written to fail requests which have more data following the ClientHello message, which makes them non-interoperable with clients that send TLS extensions. This is the precise reason why RFC 5746 has adopted the idea of Signaling Cipher Suite Value (SCSV) to avoid breaking interoperability with servers not accepting TLS extensions. The recommended approach, though, is to use the TLS extension defined by the RFC.

Now here are the important details. By default, any version of Windows prior to Vista did not send TLS extensions when using the TLSv1.0 protocol. With the new update, this has changed and if TLSv1.0 is enabled, then the renegotiation indication extension will be sent as part of the TLS handshake, as recommended. So the small set of servers (no one that I know of knows the actual percentage of such servers) which do not tolerate this behavior will cause interoperability problems. This is where the UseScsvForTls setting described in the Microsoft KB comes in. Setting the registry key to non-zero value will cause the SSL/TLS stack to generate TLS ClientHello messages containing SCSV and without extensions, so interoperability with such servers can be restored. As far as the other two keys, AllowInsecureRenegoClients and AllowInsecureRenegoServers, they control the compatible vs strict mode and will not make any difference on the structure of the messages on the wire. The only effect is whether communication is allowed to continue with unpatched party or not.

Signaling Cipher Suite Value

Tags: , , , , , , ,

6 Responses to “Windows SSL/TLS update for secure renegotiation”

  1. Rich Says:

    The UseScsvForTls doesn’t work in windows 7, don’t suppose you know a way producing the same results in windows 7?

  2. Nasko Says:

    There is no way to produce the same results on Windows 7, since it pretty much sends TLS extensions on all ClientHellos. You need very awkward configuration to cause it to send extensionless ClientHellos. What type of failure are you seeing that you want to use this reg key? There is a fallback mechanism built into WinInet that will fall down to SSLv3 in certain TLS failures, so IE and other apps built on top of WinInet should work just fine.

  3. adrian Says:

    awkward configuration(no extensions) = SSL 2.0 compatible Client Hello with no SSL 2.0 cipher suites ? :)
    should be pretty straight on Win 7 for IE8 for example, just check SSL 2.0 in IE8 and disable by registry or group policy the enabled SSL 2.0 cipher suites.

  4. Nasko Says:

    I guess I should’ve been more clear. I meant TLS client hello without extensions. If you configure Win7 with SSLv2 compatible hello, you should see the SCSV included in the ciphersuite list.

  5. Bob Baker Says:

    We have an ancient OCX that uses TLS without extensions to transact with a Stratus server without the RFC patch. The Registry key addition worked on the XP clients. What, if anything, could we do when the clients are moved to Win 7 soon? Would XP Mode be a viable option, or would Win 7′s networking stack intercept and wrap any TLS conversations? Thanks.

  6. Nasko Says:

    Do you know that the server you use does fail if you send TLS extensions? If it doesn’t, then it should work fine.
    If the server misbehaves when the client sends extensions, then using Vista or Win7 will cause the failures. I don’t know exactly how XP Mode works, but I’ve heard it is just an XP VM. If this is true, then the TLS stack should be the one present in XP and should be an option.

Leave a Reply

You must be logged in to post a comment.