Sign in / up

back to article Hackers break SSL encryption used by millions of sites

Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that's passing between a webserver and an end-user browser. The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the …

COMMENTS

House rules Send corrections
This topic is closed for new posts.

Page:

    1. Mike Cardwell
      Reply Icon

      You misunderstood the attack

      The javascript is being slipped into a http response from a site other than the target https site.

      The trouble is, people visit https and http sites at the same time. If the target is logged into a https page, and then visits a http page on a different site. You can inject stuff into that http page that will initiate requests against the target site.

      Eg, you could stick this bit of code in the http page if the target site is vulnerable to CSRF:

      <img src="https://target.site.example.com/changepassword.cgi?newpassword=foo">

      And if the target site doesn't use Strict-Transport-Security, and hasn't set the Secure flag on their cookie, you can cause the browser to initiate a non-ssl http request against the target to leak their cookie by simply slipping this into some unrelated http request to a different site:

      <img src="http://target.site.example.com/">

      You'll notice how both of those attacks work against browsers that have javascript disabled. This is why I use the Firefox addon RequestPolicy alongside NoScript.

      3 0
      1. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Well maybe, but...

        Give us an example of a high profile site which resets passwords as a GET, rather than a POST.

        If there aren't any that example doesn't work.

        0 0
        1. Mike Cardwell
          Reply Icon

          Irrelevant

          Most sites don't check to make sure that the request was a POST rather than a GET. This is unimportant anyway, because creating cross-site POSTs is almost as easy as creating cross-site GETs:

          <form method="post" action="https://target.site.example.com/changepassword.cgi">

          <input type="hidden" name="newpassword" value="foo">

          <input type="submit" id="submit" value="submit">

          </form>

          <script type="text/javascript">document.getElementById('submit').click();

          There are defenses against this attack, but 99% of sites don't use them. And before you go off on one about sites requiring you to enter your old password as well, stop attacking the particular example, and think about the "class" of attacks that are available.

          1 1
          1. Anonymous Coward
            Reply Icon
            Anonymous Coward

            Mike

            Not at all irrelevant, entirely relevant.

            Your POST example uses Javascript. Your GET example was to show this can be done without using Javascript.

            I'm unaware of sites which expect POST data which also accept the same data being submitted as a GET. Can you suggest any?

            0 0
  2. Anonymous Coward
    Anonymous Coward

    @AC 22:20 GMT: Re Opera

    Yes just tried it and it does support TLS 1.2, though this is not enabled by default (TLS 1.0 is).

    Also Opera fails when to try "Check for updates" if you have TLS 1.0 disabled...

    2 0
    1. Robert Carnegie Silver badge
      Reply Icon

      There's probably an alternative to "check for updates" in the app.

      Visit the product's web site and read the latest version number. But that isn't secure. Someone could set up a fake Opera site, and serve out trojan software.

      0 1
    2. garbo
      Reply Icon
      Linux

      Update...

      Running Opera 11.10 with TLS 1.0 disabled (on Linux Mint 11). Check for Updates offers me Opera 11.51 at the Opera website. Could your problem be OS related?

      0 0
  3. Steve 53

    Re AC 06:11

    Operas update servers are behind a load balancer which is currently only TLSv1 and not reneg patch, which has been a big source of frustration to the opera security team.

    If I'm right at guessing which load balancer they refer to, then they've just produced a new release with TLSv1.2 - suspect it'll need some testing before deployment

    Generally, on this subject, hmmm...

    Well I can't see the face of the world changing, but it is concerning.

    - The javascript injection would be to another page you're visiting at the same time, I suspect. So its relatively easy to say "Ok, I'll keep a separate browser for secure transactions"

    - The packet capture (In reality) is difficult for someone that isn't in direct control of the network (Who could therefore probably do nasty things in much easier ways).

    In the real world, I suspect it'll be considerably easier to for mass fraud to find yourself a nice drive-by zero day, drop a trojan and profit.

    1 0
  4. Steve 53

    TLSv1.1/1.2

    Looking at RFC5246..

    " IV

    The Initialization Vector (IV) SHOULD be chosen at random, and

    MUST be unpredictable. Note that in versions of TLS prior to 1.1,

    there was no IV field, and the last ciphertext block of the

    previous record (the "CBC residue") was used as the IV. This was

    changed to prevent the attacks described in [CBCATT]. For block

    ciphers, the IV length is of length

    SecurityParameters.record_iv_length, which is equal to the

    SecurityParameters.block_size."

    Which then references http://www.openssl.org/~bodo/tls-cbc.txt

    So further

    - Not a new attack, but the method of injecting chosen plaintext is

    - Block ciphers are affected, I'm guessing the venerable RC4 algorithm isn't

    1 0
  5. LawLessLessLaw
    Boffin

    So it's BROWSERS that are broken NOT TLS ?

    Because TLS is used in other places than the web browser, in your Email connections for instance:

    Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11])

    (using TLSv1 with cipher AES128-SHA (128/128 bits))

    0 0
    1. Mike Cardwell
      Reply Icon

      SMTP can already be trivally MITMd

      SMTP can already be trivially MITM'd because SMTP servers don't do any sort of certificate verification. Basically the majority of SMTP is unencrypted, and even that which is protected by TLS is "protected" by self signed certificates that aren't even checked/verified.

      SMTP TLS is good for defending against passive observers opportunistically, but if somebody can intercept the connection, on either the sending *or* receiving side, you're screwed.

      1 0
      1. Vic
        Reply Icon

        SMTP can be protected against MITM

        > SMTP servers don't do any sort of certificate verification.

        That's a choice.

        You *can* enforce cert verification if you want. Most people choose not to, because OE - although susceptible to MITM - is better than a kick in the nads.

        But if you wanted to ensure that all mail to/from a particular server/domain is encrypted using a verified cert, you set your MTA up to enforce that. It's easy in sendmail - and I'm sure other MTAs can match that.

        Vic.

        0 0
        1. Mike Cardwell
          Reply Icon

          "That's a choice."

          "That's a choice."

          I know that you *can* enable certificate verification. I've done it myself in Exim. That only happens in very limited and minor cases though. Where the two communicating systems know each other and the administrators of both systems have a reason to want to enforce it.

          I'd bet at least 99.9999% of SMTP traffic is either not encrypted, or encrypted without certificate verification.

          0 0
    2. Ken Hagan Gold badge
      Reply Icon

      Re: So it's browsers that are broken, not TLS?

      Not by my reading, it isn't. The weakness is that TLS 1.0 doesn't use a "sufficiently random" encryption key. TLS 1.1 and 1.2 do, and most browsers support them. The problem is that most *web-sites* don't.

      But yeah, this doesn't necessarily affect any other use of SSL.

      0 0
      1. bazza Silver badge
        Reply Icon

        @Ken Hagan. Title not optional

        "But yeah, this doesn't necessarily affect any other use of SSL."

        I'm half wondering if the basic technique is re-usable. These chaps have used Javascript as a way of targetting SSL/TSL sessions in use by a web browser. But I'm guessing (without any real knowledge) that the basic technique could be re-packaged as, for example, a trojan which might intercept any SSL/TSL traffic. Any thoughts?

        0 0
        1. Tomato42
          Reply Icon
          Boffin

          reuse

          As been said, the attack is used to guess the used HTTPS session cookie. You can't force a mail client or VPN client to repeatedly make new connections to a server with plaintext chosen by you before the interesting piece of information is exchanged (the password).

          Mail is insecure. If you want secure mail, use OpenPGP or S/MIME, TLS is there to protect passwords, not the messages.

          What's more, this attack is still highly theoretical for any non HTTP use of TLS.

          0 0
  6. XMAN

    If these guys have worked it out..

    then I'm sure most governments have had this capability for many years

    2 0
  7. max allan

    Doesn't NEED Javascript!

    For everyone getting het up about the existence of Java in this exploit, that is just an example of how it could be released into the wild. (If you can decrypt SSL, then you can probably add extra text into the connection to include your java)

    BUT I don't think you need it.

    I suspect you just need a packet sniffer and the code and away you go.

    So, for example, sit in a public place with a dodgy wifi AP and everyone surfs through you thinking "haha, I'm safe, I've got a green padlock". In the meantime you've captured all their login/password information etc. Presumably you can decrypt it all at your leisure and then login to their paypal/bank account a few days or weeks later and pay yourself a little bonus.

    If it takes java 10 minutes to decrypt, then a bit of nicely written OpenCL with a pile of GPUs will probably crack it realtime. That's something I'd like to see! (not on my connection)

    0 2
    1. Daniel B.
      Reply Icon

      Er...

      Java != JavaScript.

      That said, the JS piece is needed because it is a chosen-plaintext attack. It basically exploits the broken IV implementation used for TLSv1.0 to defeat CBC, so the JS thingy is needed...

      2 0
    2. Loyal Commenter Silver badge
      Reply Icon

      Putting aside that Java != Javascript, as mentioned above.

      As I read it, this allows the attacker to glean the authentication information for the SSL session. provided they can do this in less time than the session exists for, they could use it to spoof the session from another machine / browser tab, etc.

      This would not automatically get them your user name and password. It _may_gain them access to the change password facility of the site in question, and would most lilely allow them to eavesdrop and/or control the session with that web site for as long as it is active. However, most sites when changing a password would require you to enter the old password, so you would only be vulnerable to leaking your password if you changed it during a compromised session.

      Most sites also only require the user name during log-on, and since the attack is not instantaneous (i.e. takes 10 minutes or so to crack the session authentication), you will most lilely have done the whole user name and password log on bit long before the attacker can compromise your session. The exception I can think of to this is if you leave your browser at on a login page with an established SSL session but don't log in for ten minutes.

      0 0
  8. Ian Chard

    Trusteer

    Sadly this will just make my bank even more eager for me to install this Trusteer dreck...

    3 0
  9. DannyJr

    Opera may have TLS 1.1 and 1.2 on by default but almost no website support it. I tried using Opera with only 1.1 and 1.2 on, and almost every https website fails to load. We need to have the major websites like GMail to support 1.1 and 1.2 so that we can safely turn off 1.0 and SSL 3.

    6 0
  10. RickDeckardt

    http://eprint.iacr.org/2006/136 :

    Cryptology ePrint Archive: Report 2006/136

    A Challenging but Feasible Blockwise-Adaptive Chosen-Plaintext Attack on SSL

    ...

    It took them 5 years to create an exploit?

    0 0
  11. I know better

    Sandboxing

    Would be nice to be able to sandbox a tab on your browser so that the site you're using can't be shared with another tab. No session information, cookies or anything. Like a private browsing session for a single tab. That would solve it? You'd just start a "secure" tab, go to PayPal, pay then logout out and close the tab. The other tabs would be oblivious and wouldn't be able to share any data.

    0 0
    1. Boothy
      Reply Icon

      Around already, but not common (yet!)

      Secure tabs are already available on mobile devices, at least the default browser on my Android 3.2 tablet has this feature. Just select an new secure tab, rather than a normal tab.

      0 0
    2. Loyal Commenter Silver badge
      Reply Icon

      I can't see how this would work.

      How does your browser know that a request from another tab to the same site should be blocked? How does the browser distinguish between traffic from the 'secure' tab and traffic from other tabs in terms of which sites it is allowed to send request to? As far as the server is aware, it is authenticated to a given IP, not an individual tab in a browser. As far as not leaking information between tabs goes, this should already be the case, presumably with the exception of cookies which relate to specific sites/resources, so are available for all to read if they know the cookie's 'name'. Of course, if a site is so badly written that it leaks important information into cookies left right and centre then you're pretty screwed anyway.

      0 0
      1. I know better
        Reply Icon

        Agreed but

        ... if the attacker can't get any of the information (session cookie etc) from your session then all the attacker can really do is have a parallel session with their own session cookie.

        0 0
      2. Mike Cardwell
        Reply Icon

        "How does your browser know that a request from another tab to the same site should be blocked?"

        It doesn't need to block anything. The "secure tab" gets its own cookie store. When you log into a site inside that secure tab, the secure tabs cookie store contains your session cookie. Any other tab that tries to launch an attack against the site, will be launching it against a site which it isn't logged into.

        This would also allow people with multiple accounts at the same site to log in multiple times from different secure tabs.

        0 1
    3. CD001
      Reply Icon

      You can do that in the browser-that-shall-not-be-named-for-fear-of-being-accused-of-fanboyism (rather than the other browser that shall not be named because it's crap).

      1 0
    4. Ken Hagan Gold badge
      Reply Icon

      Re: sandboxing

      For those browsers that actually *let* you start a second instance, I imagine that this would have a similar effect. On top of that, depending on your OS, you may have a mechanism to start the second browser in a restricted/safe context.

      Worst case scenario: just don't be doing any other browsing the next time you are shopping or fiddling with your bank account.

      0 0
  12. ewil

    Best practice: HttpOnly

    When setting cookies, could use of the 'HttpOnly' flag resolve this vulnerability? (In supporting browsers, at least?)

    0 0
    1. Mike Cardwell
      Reply Icon

      No

      In this attack, the cookies aren't being read using JavaScript. HttpOnly doesn't help.

      0 1
  13. The Alpha Klutz

    we need something other than general purpose web browsers

    for secure traffic.

    Using a general purpose web browser to do your banking is getting to be like cleaning your teeth with a shotgun. We need something much less powerful, with much more emphasis on safety.

    We need simple 'banking clients', based on the best available encryption technology, and everytime that technology gets patched, your client breaks until you download the update. Your bank should rightfully be seen as negligent if they too do not upgrade ASAP (yes, that means someone at the bank actually has to do some WORK once in a while, sorry to break it to you like that). It is a deriliction of duty to use the same shit that doesn't work for decades, then sit on your hands and blame everyone else when it goes wrong.

    Yes you can bitch and moan about having to install constant updates, but this is security we're talking about, not some fucking parlor game.

    A web browser is like a pub, different pubs are good for different reasons, but none of them are good for banking. Thats why you go to your local BANK, if they're not too busy closing it down so the CEO can pocket another hundred million.

    So in summary, bankers are the only people in the world who can afford to take on such a software project, and they're still not going to.

    which means the government has to do it, which means, guess what, that'll be another billion taxes straight to Microsoft. Maybe Microsoft should just buy HMRC. And, 25 years later, they might come up with some dicky bullshit software based on a phone tablet toaster PC that you can use on your flower arranging table on the moon. And it'll only cost a million pounds in the UK and 3 dollars in the US.

    2 1
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: we need something other than general purpose web browsers

      .... and you can bet your arse that my OS won't be supported......

      No, I'm not going to switch to windows/OS X/Linux to use banking....

      0 0
  14. Vladimir Nicolici

    Opera

    I don't know why everyone belives Opera has TLS 1.1 and 1.2 by default.

    I just installed it, and both options were not enabled by default.

    3 1
  15. hexx

    ok, i'm moving to a bunker. will store cash in the pillows and will live w/o net - wait, the last bit is already happening, been waiting for sky for 3 weeks

    0 0
    1. I know better
      Reply Icon

      Lucky!

      You're lucky, I've been living with mobile broadband in a rural area for over a year! Paris, because I can't see an icon of Scarlett anywhere...

      0 0
  16. Anonymous Coward
    Anonymous Coward

    Call me back

    when you have a general MITM attack against the encrypted stream that does not require the client or server to be compromised. Malicious JS is not news.

    0 0
  17. John F***ing Stepp

    I will try to explain my objection.

    Phorm.

    Putting an ad into your webpage.

    Now doing it if you are using ssl.

    Now maybe over in the UK your ISP is too nice to do that but I live in the USA and these people are not as nice as BT et al.

    0 0
  18. Tagware

    Goggle Search results based upon sites SSL level

    Well,

    This would be easy. If Google and other search engined announced that the search rating would take account of the SSL level the site used. So, 1.2 gets highest rating.

    You would find rather a lot of Websites upgrading to the newest SSL.

    Dead simple really. Google and other search engines then get the credit making the internet a more secure place.

    0 1
    1. Jeff 11
      Reply Icon
      Thumb Down

      @Tagware

      Yeah great, force us all to use HTTPS for unsensitive content that requires no encryption. Ranking sites on that metric would be a printing press for the cartel of CAs.

      0 0
  19. Dan Goodin (Written by Reg staff)

    Correction -- Opera doesn't support TLS 1.2 by default

    Dear readers,

    Contrary to what was published earlier, Opera doesn't support TLS 1.2 by default. Our apologies for the error.

    0 0
  20. Oh my furry ears and whiskers
    Devil

    A bonanza for Microsoft as users move from XP to Windows 7?

    If TLS 1.1 and 1.2 are unavailable on XP (and Microsoft and others don't change this), does this mean that XP has to be scrapped when this exploit becomes widespread? Will we have to move our XP boxes to Windows 7 (or another OS)? Presumably we can't fix the issue with Opera (or a fixed Firefox)?

    I'd have thought that most people wouldn't trust their ISPs (and others in the IP connection chain) not to listen in to their banking sessions. So most people would want to move to TLS 1.1 and 1.2, which means a lot of work for those running SSL sites and new OS's for machines that can't move to TLS 1.1 and 1.2.

    0 0
    1. Richard Gadsden
      Reply Icon

      Opera is a fix

      It's only schannel on Windows XP that doesn't support TLS 1.1 / 1.2, not the entire OS.

      If, like IE and Safari, you use the OS' native crypto library, then the problem arises that you only get TLS 1.0 . Microsoft could release an updated schannel for Windows XP that included support for TLS 1.1 / 1.2 (but they won't).

      For the other browsers, Firefox and Chrome share a common open-source library (Network Security Services); that will need to be upgraded to incorporate support for TLS 1.2, or they will have to switch to a different library (NSS is developed by Mozilla, so Firefox won't switch, but Google could write their own crypto library in theory).

      Opera uses their own library, and Opera on Windows XP does support TLS 1.1 / 1.2 - you just have to enable it as it's disabled by default.

      0 0

  21. This post has been deleted by its author

  22. Anonymous Coward
    Anonymous Coward

    Errrr - wasn't TLS 1.0 already at issue and superceeded

    I was under the impression TLS 1.0 was already a borken standard and why it was superceeded . IIRC it was broken and news over 5 years ago. Oh well

    0 0
  23. Anonymous Coward
    Anonymous Coward

    How about contributing instead?

    What an unnecessary sensationalist article! OpenSSL is an open source project. Anyone is free to contribute code to the project. Maybe these so called researchers should contribute working code instead of trying to break everything.

    0 1
  24. OrsonX
    Facepalm

    Symantec

    Recon your advertisers will be dead chuffed with you running this story!

    1 0
  25. tvdp
    Stop

    OpenSSL does have a TLS 1.1/TLS 1.2 implementation

    Guys, in the article is stated that OpenSSL has yet to implement TLS 1.1 and TLS 1.2

    However, those versions of TLS have already been implemented as of OpenSSL 1.0.1

    Although OpenSSL advertises version 1.0.0e as latest stable version, a stable version with TLS 1.1 and TLS 1.2 seems to be right around the corner.

    0 0
  26. Xeon
    Linux

    I can't be 100% sure, but I've done work with SSL in the past and the encryption used during SSL is determined during the handshake process. That being said most sites use AES-256 industrial grade encryption as the primary encryption suite on SSL connections, so if this story is correct it could have more far reaching implications with regards to AES-256 encryption. That's why I feel this story might be bogus. If this BEAST tool had a valid certificate from a trust certificate authority it could launch a man-in-the-middle attack, but that's only as long as the certificate authority wasn't blacklisted. Again forgive me if my SSL/TLS knowledge is a little rusty, its been 2 years since I've had to code an application that dealed with the knitty gritty details.

    0 0

Page:

This topic is closed for new posts.

Other stories you might like