Internet Explorer 6 may display an error message similar to the following when visiting a Secure Sockets Layer (SSL) web site that uses the TLS security protocol for encryption:
The page cannot be displayed.
This behavior occurs due to an additional TLS extension added to the client request after installing the Microsoft security update 980436. Security update 980436 adds a TLS Client Renegotiate information extension to the initial TLS Client Hello request to the web server as per IETF RFC 5746. A web server that is not IETF RFC 5746 compliant may fail when presented with this new extension data in the Client Hello request and reject the client's connection request, thus causing the issue described in the "Symptoms" section of this document.
This behavior is usually due to the web server, or the intermediate proxy, not correctly supporting the behavior in RFC 5746. This is very rare, and should not affect most web sites. If the issue is persistently seen across multiple web sites, Microsoft recommends to evaluate whether the intermediate proxy server may be causing this behavior.
To properly resolve this issue, the web server or intermediate proxy server that is generating the error must be updated to be IETF RFC 5746 compliant. To do this, please contact the administrator of the web or proxy server question.
IETF RFC 5746 recommends sending the TLS Renegotiate extension in the TLS Client Hello packet from the client. However, in some cases, there might be the need to change this behavior to prevent problems accessing web servers that are not IETF RFC 5746 compliant. Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require web server implementations to ignore data following the Client Hello that they do not understand. However, some web servers that implement SSLv3 and/or TLS 1.0/TLS 1.1 incorrectly fail in such a case, which means that clients that offer the additional TLS Client Renegotiation information extension may encounter browsing failures to web sites hosted on these web servers. In order to work around issues with such servers, IETF RFC 5746 defines a second signaling mechanism (section 3.3) via a special Signaling Cipher Suite Value (SCSV) that will appear as an "unknown" or "empty" cipher suite to a non-RFC 5746-compliant Web server. Since web servers that implement SSLv3 and TLS are also required to ignore unknown or empty cipher suites as per the SSLv3 and TLS specifications, this SCSV cipher should be able to be sent to any web server that implements SSL or TLS.
To implement this workaround, you must add a registry value on the machine running Internet Explorer 6. To do this, follow these steps:
1. Click Start, click Run, type regedit in the Run box, and then press ENTER.
2. Locate and then click the following registry subkey:
3. On the Edit menu, point to New, and then click DWORD Value.
4. Type UseScsvForTls, and then press ENTER.
5. Right-click UseScsvForTls, and then click Modify.
6. In the Value data box, type 1 , and then click OK.
7. Exit Registry Editor.
Restart requirement: You must restart the computer for this change to take effect.
Please note that as per IETF RFC 5764 the behavior change created by the above registry modification is not recommended, but can be used to work around issues with Web servers that are not compliant with IETF RFC 5746.
Security update 980436, which is documented in security bulletin MS10-049, complies with the IETF RFC5746 standard. This changes the signaling method that SChannel uses when connecting to SSL web sites using the TLS protocol, and adds a new extension (extension 65281) to the initial TLS Client Hello request made by the client to the Web server. If the web server does not support this extension, the connection request to this web server using the TLS protocol may fail, causing the symptoms described in the "Symptoms" section of this document.
For further discussion on the topics introduced in this article, please see the following blog: