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.
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
You pay money to certificate providers so that your customers won't be frightened away by scary browser warnings.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
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?