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."
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.
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.