New design flaw found in crypto's TLS: Pretend to be a victim online Security researchers have developed a new man-in-the-middle attack against the cryptographic protocol TLS – a protocol that is used to encrypt online banking and shopping, and other sensitive connections, to thwart eavesdroppers. The so-called Triple Handshake attack can, in certain conditions, outwit vital checks carried out …
Yes you're completely right - but not in the way you think you are. Both are headline-grabbing and both can be made to sound far more serious than they really are, especially the GnuTLS non-issue.
The TLS issue is clearly not widely exploitable. However in the case of GnuTLS, this package is almost universally replaced by OpenSSL on all sensible Linux distros. The only people that use GnuTLS are extremist "free" software nuts for whom the fact that OpenSSL is open source but has an Apache-style license means that it's not really free software.
Oh, and even GnuTLS was patched within hours of the vulnerability's discovery.
The TLS issue is clearly not widely exploitable
"The TLS issue" also applies to DTLS, and parts of it apply to SSLv31. While client certificates are rarely used by hoi polloi, they do see significant use in a number of specialized areas - I've seen them used in a number of sensitive web-service interfaces, for example. The three-handshake attack breaks PEAP, SCRAM, GS2, and ChannelID, so applications using TLS for channel binding are in trouble.
It may not be "widely" exploitable, but it's exploitable in enough situations to be a problem.
1Specifically the UKS attacks also apply to SSLv3, which means that if a similar amplification mechanism were found for SSLv3, you'd have the same problem there. In fact offhand I can't say why the problem doesn't apply to SSLv3, but I haven't read through the attack section of the paper yet.
OpenVPN uses OpenSSL instead of GnuTLS, meaning it's not affected by this particular issue.
This isn't a GnuTLS issue. It's a flaw in TLS itself, and applies to all implementations, including OpenSSL. The authors have a tested patch for OpenSSL that mitigates the issue, but it's not in production yet.
Any TLS application that uses client certificates, uses RSA or DHE handshaking, and allows session resumption (including with TLS tickets) is vulnerable. An active MITM can impersonate the client when the session is resumed for the third time.
It's ironic that its the Enterprise type services that typically use Digital Certificates that will be more vulnerable than the standard home users who "just have a username and password".
But then if the certificate was backed by a username and password you'd have a multi-layered security model that isn't as weak as it's weakest link.
I think the op's point is that the certificate itself is protected by a password (ie. you can't use the certificate without entering a password), not that you use a certificate to authenticate for an SSL session through which you then login to a service with a username and password. It's wheels within round things inside hoops surrounded by loops within wheels...
It's ironic that its the Enterprise type services that typically use Digital Certificates that will be more vulnerable than the standard home users who "just have a username and password".
To this particular attack. I don't see that as ironic, just as an instance of the less-probable case occurring.1 Usually certificates present a considerably better risk profile than conventional username+password credentials, though still inferior, under many reasonable threat models, to that of some of the alternatives, such as ZKP-based credentials (SRP, PAK-RY, etc).
But then if the certificate was backed by a username and password you'd have a multi-layered security model that isn't as weak as it's weakest link.
What, two-factor authentication has more factors than single-factor authentication?
Of course the real beauty of this scheme is that it increases the burden on the user for a minor pruning of the attack tree. The user already likely has a passphrase of some sort to protect the private key associated with the certificate; now let's require either a second password, or let him use the same one, so that if that leaks the private key is vulnerable.
1Technically, of course, that could be ironic; irony, one of the "master tropes", is simply any case in which expectations are violated. (In information-theoretical terms it's the purest and most basic of all tropes, since without the violation of expectations you have no information, and thus no communication. There's no such thing as unironic communication.) But as I strive to be a Bayesian reasoner I always try to admit the possibility of the less-likely case, so violating my expectations takes some effort.
... breaking SSL/TLS security in the name of improved performance since 2003.
(And yes, I know that for large SSL/TLS workloads the handshake overhead is a considerable burden, though HTTP persistent sessions helped a lot. Still, the sorry parade of these "whoops, it's still not right" attacks is not encouraging.)
In the described scenario - how the malicious server would obtain a ligitimate server's private key to decrypt the Pre-Master Secret (PMS) sent by the client. Or, why would a client run the session with a serve which presented a bad server certificate ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
