Slashdot Mirror
Man-In-the-Middle Vulnerability For SSL and TLS
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."
Only with quantum physics can we actually get a secure data transfer. Or not or both.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
If the only place the exploiters were getting their info from was Slashdot, this world would be a much more secure place, and the attacks that did make it through would have more ponies.
Millions of ordinary people didn't know there was a vulnerability until now. Who knows how many bad guys knew already though?
Knowing of a potential vulnerability allows people to alter their behaviour if they deem that an appropriate response. Systems administrators can examine setups to see if they can use other methods to secure communications and it also allows all those who have written applications to examine their code.
I'd rather know of a vulnerability and respond, than not know while others are potentially exploiting it.
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.
Its the same man in all 3 places.
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
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.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
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.
Give me Classic Slashdot or give me death!
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.
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.
Of course it is! This is terrible advice!
SSLv2 isn't widely used any more precisely because it's got systemic vulnerabilities. What's needed is a new revision of the protocol or the removal of the renegotiation feature.
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.
Blasphemy is a human right. Blasphemophobia kills.
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:
/OrderTheFrogs HTTP/1.0
/address > < /xml >
/OrderTheFrogs HTTP/1.0
/address > < /xml >
/OrderTheFrogs HTTP/1.0
/address > < /xml >
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!
while (sig==sig) sig=!sig;
Let the user [...] be responsible for their own security
Yes, because as all of the botnets have shown, that works so well in practice.
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?
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.