Re: Swiss Researchers Find A Hole In SSL

[Vin McLellan]

Slashdot has posted an update and an informative note from Paul Kocher.
_Vin

------------------
<http://slashdot.org/articles/03/02/20/1956229.shtml?tid=93&tid=172>

Posted by timothy on Thursday February 20, @03:13PM
from the there's-holes-in-everything-over-there dept.

in4mation writes "The folks at LASEC have found a flaw in the SSL protocol. Quoting Professor Serge Vaudenay from a BBC article the security problem is in 'the SSL protocol itself and not in how we use it or how we implement it.' Apparently the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack."

Update: 02/20 20:52 GMT by T:

Kurt Seifried writes to say that this is almost exactly wrong: "The flaw is in IMPLEMENTATION, NOT THE PROTOCOL. Due to the way error checks are handled an attacker can find out which error condition occurred by measuring the response. The solution is trivial, a path that forces OpenSSL to do the second check even if the first one fails, thus denying the remote attacker any information as to which exact error condition occurred." He includes a link to the security advisory at openssl.org. Update: 02/20 21:49 GMT by T: Read on below for some more information from SSL 3.0 designer Paul Kocher.

----------------------
Kocher, President & Chief Scientist of Cryptography Research, Inc., writes:

The referenced paper (http://lasecwww.epfl.ch/memo_ssl.shtml) describes how timing variations in SSL/TLS implementations can be used in certain situations to slowly gather information about encrypted data. If the certain conditions are met, the attacker can decrypt some information from the message (e.g., a password). Strictly speaking, the fact that implementations reveal sensitive information in timing channels is an implementation issue, not a flaw in the underlying cryptographic protocol. This doesn't make the issue unimportant, however, and timing attacks are big deal for implementers because they are easy to introduce, notoriously tricky to detect, and often difficult to eliminate.

Answers to general questions:

1. Is it still okay to send my credit card number over SSL? Yes. This attack is not applicable to web shopping and there are much easier ways that fraudsters steal credit card information (e.g., breaking into merchants' web sites -- a problem that SSL can't solve). In any case, the bank is generally responsible if someone steals your card info.

2. Is the paper "real" or another bogus "I broke SSL" claim? The paper is legit. The Slashdot announcement suggests that SSL itself is broken, however, which is a bit misleading.

2. Is this a practical attack to exploit? Cryptographers need to be paranoid about unexpected situations. As a result, attacks can be important even if they are not practical to exploit under real- world conditions. The attack described in this paper is similar; while there are quite a few preconditions for mounting the attack, this does not make the research unimportant or mean that people should ignore the work. Specific requirements to mount the attack include:

* The session has to use CBC mode. The vast majority of SSL connections use RC4, for which the attack is not applicable. Because of the algorithm negotiation used in SSL/TLS is secured in the initial handshake, man-in-the- middle attackers should not be able affect the outcome of the algorithm selection process.

* The attacker has to act as an active man-in-the-middle attacker. Passive eavesdropping is not sufficient.
* The server's SSL implementation has to be vulnerable (see #3 below). The protocol also has to be oblivious to repeated failures.

* The target protocol also has to have some very specific characteristics that allow the adversary to form the right kinds of messages. For most uses of SSL (e.g., normal web browsing), this type of attack does not generally apply.

3. Can affected implementations be fixed? Yes. OpenSSL has been updated (http://www.openssl.org/news/secadv_20030219.txt). For more information, also see http://www.openssl.org/~bodo/tls-cbc.txt. I don't know what other vendors/projects are doing.

4. Is this an issue for the client or the server? Normally, this would only be an issue for the "server" (i.e., the party that receives the connection request), since normal SSL clients don't automatically large numbers of connections.

A couple of final comments:

I'm constantly amazed by the number of ways that it's possible to screw up security. Overall, SSL 3.0 seems to have aged well, but I wish I'd done a better job of handling errors in the design. In particular, error handling was involved in both of the attacks against SSL that I consider non-obvious, notably Bleichenbacher's attack and CBC-padding attacks such as this one. While these types of attacks weren't known when I was designing SSL 3.0, I generally wish I'd provided less information in error messages.

Finally, I also want to give thanks everyone who has helped to study SSL's security, contributed to implementations, and helped shepherd it through the standards processes."



"Cryptography is like literacy in the Dark Ages. Infinitely potent, for
good and ill... yet basically an intellectual construct, an idea, which by
its nature will resist efforts to restrict it to bureaucrats and others who
deem only themselves worthy of such Privilege."
_ A Thinking Man's Creed for Crypto _vbm.

* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
22 Beacon St., Chelsea, MA 02150-2672 USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]