Slashdot Mirror
Swiss Researchers Find A Hole In SSL
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."
Released yesterday: http://www.openssl.org
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.
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.
The article didn't make that claim, and in fact says:
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.
I would note that the one hour figure is for a dictionary attack, implying that the password was, in short, a bad one (not many universities/corporations would even allow a normal word as a password for one of their accounts). If a brute force method is used on a 256 character set, the time required is about 26 times as long (26 times greater complexity). Still a major hole, but more than a day is quite different from an hour.
Commentor says: "Apparantly the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack."
The actual linked article 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."
Nobody should dismiss a vulnerability just because the exploit was used againest something that "doesnt'" matter. SSL use with IMAP, POP, FTP or any other protocol all relates to each other. Thus a vulnerability in one can lead to more understanding and discovery of more vulnerabilities.
But if you RTFA then you would know that there is a fix already out there for the Linux community at least.
:)
In the case of openssl [9], a new version has already been released (0.9.7a) with a countermeasure against our attack.
And I'm glad I was told about this, now I can go and update my server with the latest version of openssl and recompile stuff that links against it, and I'm now secure against the Swiss
find ~your -name '*base* | xargs chown
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.
Only email is vulnerable because email programs automatically check for new mail at regular intervals. This vulnerability requires that the password be sent frequently to the server. In most other transactions, it's only sent once.
Wait, your *both* right.
The flaw is in the protocol. OpenSSL has produce a security patch in *their implimentation* that protects the hole in the protocol, but the flaw in the protocol remains.
All other implimentations that have not been so patched remain vulnerable.
KFG
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.
Of course its insecure, they programmed their security in basic.
Those of us who wonder what the "basic" in HTTP's "basic authentication" really stands for should read RFC 2617.
Will I retire or break 10K?
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.
The biggest security hole sits between the keyboard and chair.
-Andrew McAllister
Here's the article itself
This flaw is specific to the SSL protocol. OpenSSH only uses OpenSSL's crypto library, not its SSL stack. (Open)SSH should not be affected.
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.
Most people here seem to be latching on to this quote, as well as the one on the swiss site which mentions that other web-based services using SSL may also be vulnerable, and assuming that a contradiction exists.
By "a different type of SSL," they may be referring to the SET protocol that machines use when communicating directly with credit card companies. It's been a long time since I looked at SET authentication, but it may not be vulnerable to this sort of attack.
I can imaging the BBC reporters learning this, through talking to the researchers, and eventually coming up with that line, which implies that e-commerce sites over SSL are safe (which is very likely wrong)
Living better through chemicals
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?
This attack is mitigated by checking to make sure the CN matches, and verifing the SSL public key you get is signed by a CA that's in your trusted list. So if an attacker wanted to pull this off, he would need to sign the key with a CA thats in your browser (or get the user to click ok on a warning message).
> Granted, this sort of attack can't be very easy unless he has total control of a router in between you and the server ... or he can spoof a DNS reply and thus entice you open your connection to his MITM station in the first place.
Slashdot? Oh, I just read it for the articles.