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.

Wow

[Anonymous Coward]

The article (the LASEC memo) cites standard, well-known weaknesses in block ciphers. I haven't heard anyone give some of their specifics before (timing attack might be possible with encrypted error messages, for instance), but it's not really a breakthrough.

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.

Heise and OpenSSL developers tells the opposite

[kju]

Regarding to what the heise newsticker wrote, this fix IS actually in the implementation and was fixed in OpenSSL 0.9.6i and 0.9.7a. So who is right?

Heise says: "OpenSSL developers already reacted and issued versions 0.9.7a and 0.9.6i of openssl, which close this security flaw. In a posting on bugtraq they recommend this update for all users." (translation done by me).

I have read the bugtraq announces as well, they specifically state that the update DOES fix this bug. So it is NOT a bug in the SSL protocol itself, but in the implementation, at least regarding to OpenSSL developers.

Re:Heise and OpenSSL developers tells the opposite

[nestler]

It's a slight bug in the SSL protocol that is entirely fixeable in the implementation.

The bug in the protocol is that the RFC says that for block cipher decryption errors, you should report a "decryption failed" alert but for MAC errors you should report a "MAC error" alert. This opens you up to attacks.

A good implementation will report "MAC error" in both cases, and take the same amount of time to do that reporting in both cases (this is what OpenSSL's fix does). This doesn't follow the RFC but it shuts down this avenue of attack.

So OpenSSL is safe and the Heise was overstating things in a very misleading way.

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.

Huh? We must not have read the same article...

[aborchers]

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

The linked article reports a timing-based attack that could be used to identify passwords when the encrypted message is repeated, as in the case of communicating with an IMAP server. IMAP is not webmail, it is a mail protocol (a popular alternative to POP3) that is frequently secured with SSL/TLS. Once the password is cracked, it could be used to compromise other resources if the IMAP server and those other resources share the same password. It may not be likely that your bank provides your IMAP server, but it is not as unlikely that an IMAP account might share a password with other network functions that you'd want to keep secured...

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 easily avoidable; use RC4

[nestler]

The easiest way to avoid this flaw (which unfortunately few people know because of all of the poorly written hype) is to use RC4. The flaw is only present when using block ciphers, and RC4 is a stream cipher.

This measure can be taken on the client side by setting your browser's SSL preferences. All good SSL-enabled browsers (Mozilla, Opera, etc.; basically anything except IE) will let you disable non-RC4 ciphers for SSL. Turn off RC2, DES, 3DES, and AES. Only leave RC4 suites (or C4 suites as they are called in Opera).

This measure can be taken on the server side by configuring your web server's SSL configuration to only support RC4 cipher suites (RC4 is the only stream cipher defined in SSL).

If you are using OpenSSL, they made a new release (0.9.6i and 0.9.7a) yesterday that prevents this attack from working. Basically, they made the new code take identical amounts of time for the block decryption failure vs. the MAC failure which thwarts the timing attack described by LASEC. Even their old code has been smart enough to report the same error on the wire, but the old code had a timing difference (block error would skip the MAC computation).

This is not the end of the world. This is not an insurmountable flaw in the SSL protocol (although they really shouldn't have specified block decryption error as one of the alert types in the first place).

Just use RC4 for now and upgrade your web servers when you can.

Re:flaw is easily avoidable; use RC4

[arivanov]

RC4 has a history of implementation flaws. It is a good algorithm but it is quite often applied to the wrong problem and IMO anything that is not classic stream and has known plaintext fragments is a "wrong problem". The results of such misapplications are well knonw. MSFT 40 bit PPTP, WEP are just a few fine examples.

So for this specific case I would personally run away from RC4 like hell.

Also, in order to do this attack the attacker has to a be a man in the middle with capability to intercept and replace traffic. Outside the scope of a university campus network the possibility for such attack is becoming a very rare occurance as most networks do not have a suitable point to do this without exposing yourself.

Re:flaw is easily avoidable; use RC4

[fv]

the attacker has to a be a man in the middle with capability to intercept and replace traffic. Outside the scope of a university campus network the possibility for such attack is becoming a very rare occurance

I wouldn't say that at all. DNS spoofing is sadly still feasible in many situations and easily gives you this capability. It is trivial if the attacker is on the same layer 2 network (insider attacks are extremely common, and so are outsiders who own one machine on the network and then leverage that for more.) Remember that the SSL certificate validation process won't protect you from this attack, since that part of the protocol is proxied through unmolested.

-Fyodor
Concerned about your network security? Try the free Nmap Security Scanner

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.

More from OpenSSL changelog

[XenonOfArcticus]

*) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked via timing by performing a MAC computation even if incorrrect block cipher padding has been found. This is a countermeasure against active attacks where the attacker has to distinguish between bad padding and a MAC verification error. (CAN-2003-0078)

I interpret this to mean that all implementations of SSL, including OpenSSL, _could_ have this information leakage behaviour, depending on how they are implemented. OpenSSL did happen to have this behaviour, and has now been altered to take the same amount of time in either case, thus not giving the attacker any useful information.

Re:It's a floor wax. No, it's a dessert topping.

[kju]

Ok, but then the slashdot article was some sensation laden journalism. It specificially said that the flaw is in "the SSL protocol itself [...] not [...] how we implement it". So this leads to the impression, that SSL is flawed by principle and could not be fixed without altering the protocol.

Obviously this is wrong. The OpenSSL developers were able to fix the problem WITHOUT breaking compability to other SSL implementations. So how can this be a problem with the protocol itself, if it can be fixed without actually altering the protocol?

This does not make real sense.

protocol is slightly flawed

[nestler]

The protocol RFC says that you should send different alert codes on the wire for the two different cases which is what this attack needs to work. So the protocol is flawed in the sense that following the RFC to the T makes you vulnerable.

However, it is not an unfixable problem (implementations can avoid the attack if they so choose) and it is certainly not as dire as the BBC article would make it out to be.

Webmail?

[korny69]

The attack deals with reoccuring data being sent between the client, man-in-the-middle, and the server. This deals with any data being sent many times across an SSL session and not just passwords, although passwords coming from a mail client such as Evolution, Outlook, Outlook Express, or whatever is a good example.

The description is a little misleading with the webmail and not cc info. If I sent my CC info across a SSL session many times, it would be just as bad as an email password.

Although, if I sent my CC info across any session more than once, I would be asking for it anyways.

Note: Gentoo and Entrust have already released updated packages for users to install. It will not be long until RedHat, SuSE, and others do as well.

Not vulnerable to MITM as you describe

[Brian Hatch]

SSL is not immune to man in the middle attacks. Where did you get that?!? Any public key system is vulnerable during the first key exchange.

Bull pucky.

SSL is not vulnerable to a MITM during key exchange as you describe iff you are verifying certificates. HTTPS, as implemented in web browsers and other software that includes a list of trusted certificate authorities (CAs) does verify certificates. Not only that, but it requires that the common name (CN) match the host name, to prevent me (I have a cert for ssl.example.com) from interposing myself between a client and your server (www.some_domain.com) with my valid CA-signed ssl.example.com certificate.

Now if you use a client that does not support certificate verification, then yes, you are vulnerable to a MITM. For example when you use SSH and connect to a host for the first time and do not already have a copy of the host key stored on your machine (perhaps you got it on a floppy, loaded it from a web page, or some other method of getting it that you trust) then you must blindly say "Yes, I trust this fingerprint is correct." If you do this, then you may have been MITM'd, and you wouldn't know.

The best bet in this case is to check the actual server certificate once you log in and make sure that it matches the one you just accepted. You'd need to "cd /etc/ssh; cat ssh_host*.pub" and compare the output of the server keys to the one just entered into your ~/.ssh/known_hosts file. True, if you were MITM'd, then the cracker could be re-writing the keys you read from your cat command, but that's a pretty high bar for it to get over. (You might run 'less' or 'more', etc, so it's difficult for it to know when you're viewing the actual server key.)

So, in summation, if your use of SSL (or any public-key crypto) doesn't include certificate verification (or the appropriate analog), you are always vulnerable to a MITM attack. Major HTTPS implementations do not fall into this category.

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?

SWISS CHeesE

[ksplatter]

The Swiss are all about Holes huh? First Swiss Cheese, Now This!

Did you know that they invented Donut Holes as well. No Actually a man names James Vindenhaffer broke into the Duncan Donuts research facility and went through all of the garbage. He first tried to glue all the Holes together to make new donuts but after being frustrasted with their odd shapes decided to leave a good thing untouched.

This is where Jamie BrickenHymer took over. After buying a holeless Donut from a Donut shop in Clevland Ohio he wondered where all the other Donut Holes went. Little did he know that he was being bugged by Micrsoft. 3 Days later Microsoft had the patent for the Donut Hole and sold the Rights to Dunkin Donuts for 43 Billion Dollars.

Giggle.

[Black Parrot]

Q: Is it still okay to send my credit card number over SSL?

A: Yes, after last weekend everyone already knows your credit card number anyway, so don't worry about it.