Jump to content
Sign in to follow this  
mashti

Is SSL broken? – More about Security Advisory 2588513

Recommended Posts

Hidden Content

    Give reaction to this post to see the hidden content.

 

 

Today the MSRC released

Hidden Content

    Give reaction to this post to see the hidden content.
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

Hidden Content

    Give reaction to this post to see the hidden content.
, 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

Hidden Content

    Give reaction to this post to see the hidden content.
compliant configuration. Please refer to

Hidden Content

    Give reaction to this post to see the hidden content.
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:

Hidden Content

    Give reaction to this post to see the hidden content.

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:

Hidden Content

    Give reaction to this post to see the hidden content.

To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here:

Hidden Content

    Give reaction to this post to see the hidden content.

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

Hidden Content

    Give reaction to this post to see the hidden content.
.

Why TLS 1.1 is not enabled by default?

The main reason to not enable TLS 1.1 by default is due to

Hidden Content

    Give reaction to this post to see the hidden content.
. 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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...