Swiss Researchers Find A Hole In SSL

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

Comments

Ugh...

[Anonvmous Coward]

"Swiss Researchers Find A Hole In SSL"

Isn't that their style?

Yeah, I know, that joke was cheesey.

The Swiss

[bytesmythe]

Those damn army knives have a tool for everything nowadays...

OpenSSL new version has fix already

[linuxbaby]

Since not everyone reads the article, don't miss this line from it:

In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.

Released yesterday: http://www.openssl.org

Re:OpenSSL new version has fix already

[cicadia]

The attack works because the attacker can distinguish between an error in the message padding and an error in the MAC, by careful timing of the wait for the response from the server.

This is possible because SSL implementations typically abort processing a message immediately if the padding is incorrect, without testing the MAC, meaning that they respond a couple of milliseconds sooner than they would have if the padding was correct.

The openssl countermeasure is simply to perform a MAC test in all cases, whether the padding was correct or not, before returning an error to the client.

But what if I'm a repetitive compulsive buyer?

[djeez]

I don't know, maybe I'm going to buy 160 different items, one at a time, each time sending my credit card number.

Re:Arg!!!!

[delta407]

Relax. It's a possible attack when plaintext is repeated over multiple sessions and a non-critical error occurs that forces a key renegotiation, not something a script kiddie will run and get a list of every credit card number on amazonl.com.

Besides which, openssl 0.9.7a was released yesterday, and it addresses these issues.

banking too

[sarice]

"Apparantly the flow only affects webmail and not banking or credit card payments"

The article didn't make that claim, and in fact says:

TLS/SSL are used in other secure Internet applications such as e-banking and e-commerce meaning that an attacker could potentially intercept banking transactions, credit card numbers, etc.

Re:A different kind of SSL?

[Anonymous Coward]

The problem comes from forming the same strings, crypting them and sending them over and over again. Banking sessions, etc, do not send your authentication tokens over SSL many times, they simply send once, and then set a secure cookie.

This cookie would be vulnerable (it gets sent with each request) except that each HTTP request is formed with a fair amount of variance in it. More data goes back and forth (requests for HTML files, graphics files, etc) so there isn't that one little message being sent many many times.

Again, RTFA. The problem comes from the same message being crypted and sent again and again. This is why only very specific things are vulnerable.

Re:Wait...

[Oculus Habent]

Webmail is insecure because it resends the same data (username & password) regularly to the server. Credit Cards submissions and sign-in pages are unlikely to keep sending the same data repetetively.

Of course, we just need a better webmail application, and you'll be fine.

Flaw is in OpenSSL implementation, not protocol

[seifried]

As usual the slashdot editors have gotten it completely wrong. The flaw is NOT in the protocol. It is in the implementation. When checking CBC (Cyclic Block Chaining) packets for errors (i.e. the kind created by a man in the middle attack) two error checks are done. If the first one fails a reply is sent, if the first one passes and the second one fails the same error is sent, but of course it takes a bit longer then if the error had been triggered by the first error check. This allows an attacker to replay data from another users session against the server, creating errors, by knowing which of these errors occured they can mount an adaptive attack and home in on the data. This attack requires an attacker to be able to monitor data between a client and server, as well as establish a connection with the server.

The fix is pretty trivial, the second error check is done even if the first fails, thus removing any time based information (i.e. data takes about the same time to traverse both checks whether it fails the first or second one), thus denying the attacker the needed information. Fixed versions of OpenSSL have already been released. For more information please see OpenSSL Security Advisory [19 February 2003].

As a further note the BBC article is wrong, the quote "It is the first time we have noticed a security problem in the SSL protocol itself and not in how we use it or how we implement it" is either a misquote or flaw. If the flaw were in the protocol itself the solution would not consist of a 30 line patch to OpenSSL's error checks.

Re:SSL mail

[Forgotten]

It doesn't matter whether you're using webmail (the article is mistaken in this respect). The issue is if you're doing regular periodic mail checks to a POP or IMAP server where you authenticate over a TLS channel. Because you're constantly sending the same credentials, the SSL/TLS weakness can be exploited and the credentials extracted. This is as true of Pine as of Eudora or a browser that keeps refreshing the inbox page. It's somewhat akin to the way 802.11 WEP's weakness is exploited.

It's long been obvious that periodic mail checks are a great sniffing opportunity for credentials (especially since many people are using the same userid and password elsewhere). Doesn't surprise me that it can also be exploited to break SSL/TLS. From that angle I would say that part of the overall issue is after all the way we're using TLS (though the underlying leakiness is how the exploit actually occurs). The problem is, what do you do instead?