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."
Re:oh joy (Score:3, Insightful)
Re:oh joy (Score:5, Insightful)
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.
Dissabling SSL re-negotiation? (Score:4, Insightful)
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
Use PGP/GNUPG auth (Score:2, Insightful)
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?
Re:This is news? Come on! (Score:1, Insightful)
It's news in the sense that TLS provides an authentication mechanism specifically designed against this kind of attack.
Re:We need to invest in Quantum Physics. (Score:4, Insightful)
What will really irritate quantum physicists in this instance is that, unfortunately, the joke is both funny and unfunny at the same time. The state of the joke relies upon the opinion of the observer, not any quantum juxtaposition.
In fact, I'm not so sure this is related to quantum phy... Oh.
Wrong Impression? (Score:3, Insightful)
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.
Re:Dissabling SSL re-negotiation? (Score:3, Insightful)
> 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.
Re:Wrong Impression? (Score:5, Insightful)
You pay money to certificate providers so that your customers won't be frightened away by scary browser warnings.
SSL is broken and the world has ended? (Score:1, Insightful)
Most people don't use client authentication and there is typically little reason to ever configure a server to change ciphers or otherwise initiate renegotiation.
If the server does not initiate renegotiation the MITM attack does not apply! This is why there is such focus on client authentication because this is realistically the only real world case where renegotiation makes any logical sense. Sure you can dream up other scenarios where the server forces you to use a higher strenght cipher to access specific content but realistically this is nonsensical. Operators make a global stand WRT cipher strength at the site level.
TLS was written back in the day when we had low and ultra low export quality ciphers and more international encryption issues than exist today. All sane operators have since disabled these and all browsers that matter have reasonably high strength ciphers available to them mitigating any reason to renegotiate.
Yes it should be fixed.
No its not the end of the world.
Re:Disabling SSLv3 in Firefox (Score:5, Insightful)
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.
Re:Wrong Impression? (Score:3, Insightful)
> 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 access to the CA's and are thus able to
create perfectly valid certificates at a whim for any application, incl. a
chained MITM attack. SSL is, IMHO, not in any shape safe from certain
government intrusions. Ironically, likely due to the so-called "trust" model
it employs.
Re:Dissabling SSL re-negotiation? (Score:1, Insightful)
No, SSL client auth works just fine w/o renegotiates. Only some scenarios (client auth only for some resources on the site) or implementations (a webserver made in the american north-west) use renegotiates.
Re:Use PGP/GNUPG auth (Score:5, Insightful)
Let the user [...] be responsible for their own security
Yes, because as all of the botnets have shown, that works so well in practice.