Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security IT

Man-In-the-Middle Vulnerability For SSL and TLS 170

imbaczek writes "The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an 'authentication gap' exists during the renegotiation process, at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS."
This discussion has been archived. No new comments can be posted.

Man-In-the-Middle Vulnerability For SSL and TLS

Comments Filter:
  • by jellomizer ( 103300 ) on Thursday November 05, 2009 @09:25AM (#29994474)

    Only with quantum physics can we actually get a secure data transfer. Or not or both.

  • More cyber terror :)

  • So are these man in middle exploits fixed in the latest Ubuntu release ?
    • "So are these man in middle exploits fixed in the latest Ubuntu release ?"

      No, they've just changed the name to "koala in the middle" exploits.

  • We need someone who can eliminate these middle men! Where's Tom Shane on this??
  • by AbbeyRoad ( 198852 ) <p@2038bug.com> on Thursday November 05, 2009 @10:06AM (#29994938)

    Am OpenSSL patch (http://www.links.org/files/no-renegotiation-2.patch) disables SSL
    renegotiation, closing the security hole.

    But let me ask this : who would ever require SSL renegotiation in practice?

    I mean seriously -- changing the cipher in the middle of an SSL session??
      -- no mainstream scenario would ever do this.

    A question comes to mind why renegotiation was ever supported in the first place.

    The next question is what OTHER seldom-used "features" are supported by
    most SSL implementations that are just supported so that the implementation
    can claim full RFC compliance, but are never actually used by real web sites.

    My own SSL builds disable everything except RC4-*-RSA

    • by dopodot ( 1559063 ) on Thursday November 05, 2009 @10:32AM (#29995268)
      It's more than changing the cipher type, it's also negotiating up from anonymous client to verified client. The second situation occurs ALL THE TIME in web services that require different levels of trust for different content within the same site. So it's not a "seldom-used" feature in the least.
      • Re: (Score:3, Insightful)

        by John Hasler ( 414242 )

        > The second situation occurs ALL THE TIME in web services that require
        > different levels of trust for different content within the same site.

        Don't do that.

    • by Anonymous Coward on Thursday November 05, 2009 @11:06AM (#29995656)

      "But let me ask this : who would ever require SSL renegotiation in practice?"

      from,

      http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html

      SSL renegotiation is useful in the following situations, once you have established an ordinary SSL session:

              * When you require client authentication
              * When you are using a different set of encryption and decryption keys
              * When you are using a different set of encryption and hashing algorithms

      The last two are kind of useless in practice. The first one is very useful to authenticate the client. Actually, if this is the only way to verify client cert, then SSL renegotiation is vital part of SSL.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.

        • Umm, you want to rotate your block ciphers on long-running connections. Saying this isn't useful in practice implies that you must reset connections and recover at the application level instead, or risk using the same block ciphers for too long.

          Exactly. I was going to say the same myself.

      • by EelBait ( 529173 )
        You can also use renegotiation to derive new keys after X amount of data has passed. This would be for long running connections.
    • But let me ask this : who would ever require SSL renegotiation in practice?

      I mean seriously -- changing the cipher in the middle of an SSL session?? -- no mainstream scenario would ever do this.

      A question comes to mind why renegotiation was ever supported in the first place.

      Client certificates need this.

    • by cananian ( 73735 )
      RC4? Really?! Dude, that's totally broken -- see http://en.wikipedia.org/wiki/RC4#Security [wikipedia.org] and especially http://en.wikipedia.org/wiki/Fluhrer,_Mantin,_and_Shamir_attack [wikipedia.org] . Ron Rivest makes lots of good stuff, but all of "Ron's Codes" have been broken. (Except maybe RC6, but the AES committee determined that Rijndael was better than it.) Classic example of amateur cryptography actually resulting in a system that is *weaker* than the alternative. Le sigh.
  • Use PGP/GNUPG auth (Score:2, Insightful)

    by elucido ( 870205 )

    Maybe its time we stop using SSL and just use GNUPG Auth. Let the user generate their own key and be responsible for their own security, or lets just use smart card readers. We make impossible to secure our machines due to our institutional insecurity. This way we can use it as an excuse to blame terrorists and get the feds involved.

    Why aren't smart cards the norm? Why are we using passwords at all?

    • by schon ( 31600 ) on Thursday November 05, 2009 @12:14PM (#29996532)

      Let the user [...] be responsible for their own security

      Yes, because as all of the botnets have shown, that works so well in practice.

      • by elucido ( 870205 )

        When have we given the user the choice to have an operating system not vulnerable to botnets? They don't get a choice. And let's be realistic, botnets are offtopic.

    • Note that using a smartcard in this case would not help you. Smartcards provide a protected place to put your keys and do "private" stuff (like signing) but all the same protocols are usually used on top of that (including SSL/TLS).

      I doubt GNUPG Auth is without fault itself. It's really hard to do security and crypto stuff correctly. Really, really hard as even the best mathematicians, theorists and developers in the world get caught out all the time.

    • That will not happen, because there is no money in it. Tunnelling over ssh has the same problem.

    • You are clearly confused. This is about a flaw in the SSL protocol, not a flaw in X.509/PKI. The only real difference between PGP and X.509/PKI is in key management. Using PGP's extremely expensive, time-consuming, and error-prone key distribution method is the reason PGP is going extinct. Your grandma will never go to a key-signing party.

      Another thing you are confused about: smart cards? What? What do they have to do with anything? Smart cards typically use X.509, not PGP. And in this case, smart cards wou

      • by elucido ( 870205 )

        How would a smartcard ever be less secure than a password?

        The problem is SSL. Did you do your research as to what GNUPG auth is? Sure it does not replace all the functions of SSL, but SSL if it's this broken isnt really much better. I think there should be an alternative to SSL so that SSL actually has reason to improve. If you only offer one crypto protocol and one set of options then what do you expect?

    • Because you haven't understood security at all!

      Smartcards still need a password, or they are no more secure than a fingerprint (cut off the finger) or a credit card (buy something immediately after stealing it).

      Passwords alone of course a also not great. But at least nobody can steal a password that is stored only in your mind.

      • What password of random characters can you actually store in your mind and how many? If anyone actually has access to your machine then all your passwords are useless. Assuming your passwords cannot be cracked is silly. The smartcard removes the need to enter a password into a machine, this prevents remote users from using a software keylogger.

        Passwords are why everyone is so easy to hack today. Nobody picks a secure password because those passwords cannot be remembered, and the passwords which can be remem

  • Wrong Impression? (Score:3, Insightful)

    by Dareth ( 47614 ) on Thursday November 05, 2009 @10:27AM (#29995190)

    I had the impression that we paid money to SSL certificate providers because they provided security and identify confirmation. Maybe that was just a wrong impression.

    • by John Hasler ( 414242 ) on Thursday November 05, 2009 @10:55AM (#29995542) Homepage

      You pay money to certificate providers so that your customers won't be frightened away by scary browser warnings.

      • If phishing attacks are any indication, the scary browser warnings don't work anyway.
      • Re: (Score:3, Insightful)

        by muckracer ( 1204794 )

        > You pay money to certificate providers so that your customers won't be
        > frightened away by scary browser warnings.

        Which they get anyway....and next ignore. Yippie Skippy!

        While the SSL crypto part is pretty neat, I always felt the commercial CA
        thing is one of the biggest money-making rip-off's in the entire IT field.
        Nor do I believe it to be secure or "trust" it. We always assume MITM's to be
        someone without access to the CA's themselves. Frankly, the people I worry
        more about are those, that DO have a

        • by amorsen ( 7485 )

          Indeed. GPG and SSH have workable trust models. Not perfect, but workable. The model in TLS is just wrong. Anything which requires me to trust the (hopefully merely incompetent) people working for Verisign is a loss.

    • You're confusing a single vulnerability with a systemic problem. When this is fixed, that's what SSL certificate providers will do again.

  • I read the first article (second won't load...probably hosed by the /. effect) and it's still not clear to me why this is a big deal. Can someone explain how injecting prefixes compromises my secure datastream?

    • From what I understand, the MITM could "swallow" the original HTTP request from the client, inject their own URL (with parameters in the query string) into the request all while continuing to forward the client authentication cookies. Imagine prefixing an HTTP GET request for a poorly written webapp: GET bad.webapp.com/payment/send.php?account=12345&amount=1000000000.00 HTTP/1.1
    • by Burdell ( 228580 )

      Let's say you are paying your mortgage, putting in your bank account information for a transfer. An attacker could inject additional HTML (Javascript, etc.) that sends your response to the attacker's server instead of the mortgage company's server, compromising your account info.

      Or a simpler attack would be the bank's online banking login page: again, inject additional HTML to the bank's response, and now you submit your username/password to the attacker's server.

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        Actually, this isn't true. This attack only allows for injecting data into the request from the client to the server. The attacker doesn't even get to see the result, much less modify it.

        Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants. You know, the kind of thing you could do with a simple injected IMG tag.

        • Re: (Score:3, Informative)

          by radtea ( 464814 )

          Basically, the only thing the attacker gets is the ability to make the client's browser request whatever the attacker wants.

          Oh, is that all? So for example, you can serve something that looks like my bank's home page but originates on your server.

          Then when I enter my user name and password your server collects them, and if you're feeling particularly clever redirects me back to my bank's real site. Now you have access to my account, and I'm none the wiser.

          This is far more serious than image loading, becau

          • Re: (Score:3, Informative)

            Erm, no, you're getting it wrong. What this attack means is that the attacker gets the ability to make arbitrary requests for resources on behalf of the user.

            So no, it doesn't mean that the attacker can now serve you malicious web pages that will appear to be coming from your bank's web site. What it does mean is that once you go to a secure page on your bank site, the attacker can instruct the bank to transfer money from your account to his, without you ever knowing. This is kind of similar to the IMG tag

    • by Anonymous Coward

      You're right, this isn't a big deal. What they're describing is essentially a very complicated CSRF. The upshot is that you can get the user's browser to visit a URL of your choosing, but you can't see the results from that page. Sound familiar? That's because all you'd have to do is embed an IMG tag in some HTTP that the user is getting back in order to accomplish the exact same thing -- no fragile renegotiation attack required.

      Thank you security industry for all the hype.

      • The key difference is that with IMG tag the attacker can only get the user's browser to make GET requests, whereas this attack enables POST requests as well. Any reasonably well-designed online banking application should not be exploitable via GET requests.

        Also, the attack vector here is different compared to a "regular" CSRF through XSS. Which one is more practical is open to debate.

    • Re: (Score:3, Informative)

      by WhiplashII ( 542766 )
      Let's say you have a web service exposed to your clients that processes orders. The error allows an arbitrary amount of data to be injected into the beginning of the client request - so the "bad guy" takes your request:

      POST /OrderTheFrogs HTTP/1.0
      content-length: 20

      < xml >< orderafrog number=1/ >< address > my address < /address > < /xml >

      And converts it to:

      POST /OrderTheFrogs HTTP/1.0
      • So it's really not that big of a deal for HTTPS. Attacks exactly like that already exist, they are called cross site request forgery. However this is a significant attack against other SSL wrapped protocols.

        • Well, it's slightly bigger than that. With a cross site request forgery, the cert is off. So it can be detected pretty easily. With this, the client doesn't necessarily know that it happened.

          That said, there aren't that many case where this can be exploited really.
    • by CompMD ( 522020 )

      As Admiral Kirk taught us when facing Khan, when you inject prefixes over a datastream like a comm channel to another Starfleet vessel, you can take command of their consoles and lower their shields.

    • by Lehk228 ( 705449 )
      "prefix" contains an HTML page that looks like your bank page, and asks for your bank password, and your browser "confirms" that you really are at your bank's website.
  • Phew! 2 hours later and only 51 comments. This must not be a big deal.

    Y'all had me worried there...

    • by 6Yankee ( 597075 )

      I think it's more that most of us don't understand this stuff. I know I don't, and freely admit it.

      Admittedly, I've never had to touch SSL (and if I did, you can be damned sure I'd be learning it inside out), but if I'm a web developer and don't understand it, how can we expect Joe Sixpack to?

    • It is a complex issue that has no simple/obvious solutions. That's why the usual blah is not occurring.

      It is a huge thing because we used to design web services ala 'Slap SSL onto it, and traffic can not be modified and wiretapped' (assuming the server cert is right).
      That beauty of SSL, just to add a layer that will take care of it all, is gone ... as the pdf [extendedsubset.com] states, even if no client certs are involved, the current protocols and all client/server software is vulnerable, and at least some of the attack scen

  • They just keep coming. Is the Web fundamentally, unfixably, insecure?

    (That's the Web, not the Net)

  • by Xylantiel ( 177496 ) on Thursday November 05, 2009 @12:45PM (#29996906)
    The linked articles only discuss authentication via client certificates, which seems pretty rare currently. How does this vulnerability actually impact the "usual" web commerce usages of SSL, which involves a server certificate? Also it does not appear that there is any way to force a re-negotiation from outside. And while re-negotiation appears common for client certs, I would expect it to be somewhat uncommon for server certs except for the initial up-negotiation to a secure connection for TLS. How important is this for the common-use cases of e-commerce and banking?
    • Re: (Score:3, Informative)

      The linked articles only discuss authentication via client certificates

      Not true. From http://extendedsubset.com/Renegotiating_TLS.pdf [extendedsubset.com] :

      Cases not involving client certificates have been demonstrated as well.

      It is a complex issue that has no simple/obvious solutions. The current protocols and almost all client/server software is vulnerable, and at least some of the attack scenarios are not uncommon.

      • by trifish ( 826353 )

        > and at least some of the attack scenarios are not uncommon.

        That sentence is modded informative? Where is the informative part? WHICH scenarios? References?

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...