Man-In-the-Middle Vulnerability For SSL and TLS 170
Posted
by
Soulskill
from the alphabet-soup dept.
from the alphabet-soup dept.
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 is news? Come on! (Score:1, Informative)
Anyone who knows anything about TLS/SSL knows that MitM attacks are always the biggest risk.
Heck, appliances like the IronPort devices use exactly that to inspect user traffic.
Re:oh joy (Score:5, Informative)
I wouldn't be so sure on that, anyone can read a mail-listing Ill quote this from Marsh Ray on the ietf mail list:
I can confirm the severity of the TLS MITM bug. I've had a working
exploit going since the end of August.
Steve Dispensa and myself put together (with help of many of course) an
industry working group to address it. I think we were successful in
producing a preliminary fix, which vendors are in various stages of
testing and deployment.
We'd agreed to responsibly delay disclosure to give the industry time to
coordinate the fix.
Re:Maybe because the "hackers" are writing the cod (Score:4, Informative)
Never attribute to malice that which may be adequately explained by incompetence. There is of course always the possibility that someone would do this on purpose. But I still trust people who let us see the code more than those who don't.
Re:Dissabling SSL re-negotiation? (Score:5, Informative)
re: How does this compromise SSL? (Score:2, Informative)
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.
Re:Dissabling SSL re-negotiation? (Score:5, Informative)
"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:How does this compromise SSL? (Score:3, Informative)
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, because you can serve arbitarary web pages to me. As others here have pointed out, you could even serve my bank's authentic webpage but with some added javascript to just forward my username and password to you. Can you do that with an embedded image tag?
No, I didn't think so.
Re:How does this compromise SSL? (Score:3, Informative)
POST
content-length: 20
< xml >< orderafrog number=1/ >< address > my address <
And converts it to:
POST
content-length: 24
< xml >< orderafrog number=100/ >< address > evil address <
POST
content-length: 20
< xml >< orderafrog number=1/ >< address > my address <
by using this attack to insert the evil request before yours. Now 100 items are sent to the evil address, and presumably are billed to you!
Re:How does this compromise SSL? (Score:1, Informative)
Dude, no. This attack does not allow me to impersonate any website. It does not allow me to intercept your credentials. It does not allow me to read *anything*. All it allows me to do is make your browser request a page from a *legitimate server*, without me being able to see the response. It is functionally identical to me passing you an IMG tag for a link that your browser follows. There is literally no advantage over more sane CSRF techniques.
Re:How does this compromise SSL? (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 attack but it's more difficult to defend against.
Re:Dissabling SSL re-negotiation? (Score:2, Informative)
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.
Re:Client certificates only? is this important? (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.