On January 10th, Microsoft released MS12-006 in response to a new vulnerability discovered in September in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability and workaround options Microsoft has released if you discover a compatibility issue after installing the update.
Is SSL broken?
Yes and no. Yes means that under certain circumstances, the attacker can decrypt the encrypted SSL traffic. No means that there are significant mitigating factors that would make the attacks difficult or impossible. By default, SSL 3.0 and TLS 1.0 are enabled on Windows operating systems.
What does the update do?
The update modifies the way that the Windows Secure Channel (SChannel) component sends and receives encrypted network packets. This addresses the vulnerability affecting WinHTTP and provides the possibility to enable the protection system-wide. However, in order to be protected from the web-based attack vector through Internet Explorer for this vulnerability, customers must install both MS12-006, and the Cumulative Security Update for Internet Explorer (2618444), MS11-099.
Attack vector
In the advisory, it is mentioned that the vulnerability could allow the attacker to decrypt the SSL 3.0/TLS 1.0 encrypted traffic. While the affected component is a Windows component, the primary vector is to attack the browser’s use of the HTTPS protocol to intercept sensitive information, such as the session cookie of the HTTPS session.
Mitigation
Based on our current investigation, the following are mitigating factors that would make any potential attack via currently known exploit vectors difficult or impossible:
- The HTTPS session must be actively attacked by a man-in-the-middle; simply observing the encrypted traffic is not sufficient.
- The malicious code the attacker uses to decrypt the HTTPS traffic must be injected and run within the user’s browser session.
- The attacker’s malicious code needs to be treated as from the same origin as the HTTPS server in order to it to be allowed to piggyback on an existing HTTPS connection. Most likely it requires the attacker to exploit another vulnerability to bypass the browser’s same origin policy.
Therefore, if the user closes all existing HTTP tabs and untrusted HTTPS tabs, then browses to the trusted HTTPS site, such as the log-in page of hotmail.com in a new browser session, and logs out of that HTTPS session before browsing any other HTTP sites or untrusted HTTPS sites, the user will NOT be at risk for this attack.
Workaround
One workaround we would encourage the web server administrators to do is to give a higher priority for the RC4 Cipher Suite than CBC since the attack only affects cipher suites that use CBC. By giving a higher priority for RC4 on the server, RC4 instead of CBC will be used in the security communication since all of windows clients support RC4, unless put in FIPS compliant configuration. Please refer to this MSDN article to learn how to perform this operation via group policy. It is an effective option for web server administrators using Windows Vista or Windows Server 2008 and later platforms. We recommend putting TLS_RSA_WITH_RC4_128_SHA as the top of the priority list, as indicated in the following image:
We would also encourage users and web administrators to enable the newer security protocols, such as TLS 1.1, on both the client side and the server side. By default, these are disabled (more below). If the browser and web server both enable TLS 1.1, the HTTPS traffic uses TLS 1.1 protocol instead of SSL 3.0/TLS 1.0, and thus won’t be affected by such attacks. TLS 1.1 protocol is supported in Windows 7 and Windows 2008 R2.
Automated FixIt Options:
Microsoft has released several FixIts to help automate enabling TLS 1.1 and a workaround FixIt to disable the functionality of the update if you find a compatibility issue that you need immediate ability to rollback without uninstalling.
To ENABLE TLS 1.1 for Internet Explorer and other WinINET-based applications running on Windows 7 and Windows Server 2008 R2, please click here:
To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here:
If you would like to revert the changes made by these FixIt’s, you can find a corresponding DISABLE Fixit for both the client side and server-side changes at http://support.microsoft.com/kb/2588513.
To temporarily DISABLE the security update to confirm a compatibility issue without having to uninstall it, click here:
To re-enable the security update, click here:
Why TLS 1.1 is not enabled by default?
The main reason to not enable TLS 1.1 by default is due to compatibility problems. We need more servers to implement HTTPS protocols correctly so we can enable TLS 1.1 by default in the client in the future versions of IE. We will work hard to drive adoption of TLS 1.1 or TLS 1.2 as an industry-wide effort.
Special thanks to Nasko Oskov and Eric Lawrence.
Update Sep 27 - Mitigating factors list applies to all currently known attack vectors. Thanks for the suggestion to clarify, Juliano.
Update Mar 14, 2012– Renaming to reflect release of MS12-006 and adding links for additional FixIt items. Special thanks to Kevin Ledman.
- Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering