Jump to content


0
[Tutorial]

Is SSL broken? – More about Security Advisory 2588513



No replies to this topic

#1 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38688 thanks
  • LocationActive Directory Inside

Posted 27 September 2011 - 11:01 AM

http://blogs.technet.com/b/srd/archive/2011/09/26/is-ssl-broken-more-about-security-advisory-2588513.aspx


Today the MSRC released Microsoft Security Advisory 2588513 alerting customers to a new vulnerability reported in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability.
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.
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 a potential attack 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:
Posted 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. 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.
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:  Posted Image
To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here:  Posted Image
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.
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.
- Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 1 Member:
Dreamfall



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Organization

Community

Downloads

Test Providers

Site Info


Go to top