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 + <vin at theworld.com>    *
             22 Beacon St., Chelsea, MA 02150-2672 USA



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com