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

Wait...

[Anonymous Coward]

What are the actual implications of this hole? "A different kind of SSL" ? Do they just mean a different cypher/key-strength? And if so, it's then fairly technically incorrect to state "it's just webmail" since last I checked, SSL doesn't know or care about the data being transmitted, and isn't going to up and change the protocol features based on if it's webmail or online shopping; any idiot using the broken/weak encryption would be screwed no matter what data is being transmitted.

Also, the hole was "passed on to the developers, and will be fixed in the next version of the software." So what, is this just some particular implementation of the SSL protocol? Is it MS', OpenSSL's, whose?

A different kind of SSL?

[griffjon]

"But the researchers say the loophole does not apply to credit card transactions, as banks and e-commerce sites use a different type of SSL (Secure Sockets Layer) technology"

Um? Well, are they talking about 64 vs 128 bit keys? The article later indicates it's a weakness in sending the same password often within one session, which would be actually, an implementation problem as opposed to an SSL problem. Anyone have a mirror of the actual paper and not ust the bbc article yet?

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

[rp44]

Well actually it's any application where interesting plaintext is sent at a known offset in the conversation over and over again.

I think that this means that HTTP Basic Auth over buggy SSL is vulnerable (in other words password protected web pages). Remember that the Auth header is sent in each and every page request, although its absolute offset in each HTTP req will vary with URI length in the GET/POST header. If this is known though...

Re:Flaw is in OpenSSL implementation, not protocol

[jaspetry]

I hope people take your advice and actually read the OpenSSL Advisory, which does a fairly good job of explaining the problem and the fix. This is an implementation "flaw" only in the sense that the implementation failed to protect against a previously unknown timing attack. OpenSSL is almost certainly not the only implementation to get this wrong. Wonder how long it will be before someone finds this flaw in MS's CryptoAPI libraries?

So what the man in the middle does

[roystgnr]

Is receives your public key, and sends his public key to the SSL server in it's place. He also receives the SSL server's public key, and sends his public key to you in it's place. He then decrypts every message you send to the server (which you will have encrypted using his public key, thinking it was the server's public key), reads it, and reencrypts the plaintext using the server's real public key before sending it on to the server.

Granted, this sort of attack can't be very easy unless he has total control of a router in between you and the server, but unless there's some out of channel way of verifying the private keys (web of trust or certifying authorities, for example) then this is at least theoretically possible.

Re:Not so sure

[blibbleblobble]

"This looks like a 'man in the middle' attack to me, not so much a failure of ssl."

Okay. I recently suffered a man-in-the-middle attack. I was faced with the choice of using insecure alternatives to communicate, or not being able to read email or update my website.

My family quite often have problems with secure email. It doesn't take a genius to work out that when their secure email fails, they turn it off and write plaintext emails.

MitM attacks are not to be sniffed at. With the clueless [or deadline-pressed] public, you can defeat encryption just by scrambling it.

Differences Between Post and Article?

[RAMMS EIN]

I have the feeling the assertions made by the original poster and the researhers are rather different. A few examples:
"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.'"
This is different from what it says in the LASEC memo, which identifies a timing attack as necessary to distinguish MAC errors from PAD errors. This suggests that if random delays are added to the error messages, the vulnerability disappears. The article also mentions (obligatory?) that the hole has been fixed in OpenSSL 0.9.7a, which clearly means that the vulnerability is implementation-dependent.

"Apparantly the flow only affects webmail and not banking or credit card payments and took less than an hour (160 attempts) to crack."
The LASEC article does not mention webmail at all, it talks about MicroSoft Outlook connecting to an IMAP server as a convenient example of a situation where the attack is fairly easy to carry out. The point is that the information that is being sent is the same every time, so that multiple guesses can be made. Additionally, in the example, Outlook connects to the server and sends the password every 5 minutes, so that multiple guesses can be attemted in a reasonably limited time span. This means that an attack is feasable for services like email, where the same information is transmitted frequently, and harder for services where the frequency is lower, e.g. SSH sessions.

just my thoughts, I'm not a security expert - yet.

---
All generalizations are false.

This is not a new vulnerability

[apankrat]

The article in question merely extends previously announced Vaudenay attack against CBC-based symmetric ciphers.

Vaudenay algorithm is a Man-in-the-Middle type of an attack that relies on SSL error messages (invalid_pad and invalid_mac) to effeciently deduce message padding information and (somehow) use it to bruteforce the key.

The attack in current article merely fights the fact that certain SSL/TLS versions do not provide error feedback that is required by the Vaudenay algorithm. So, they measure server response time instead and use it to estimate how much of the message processing the server has performed prior to failing the exchange. This obviously provides a missing information to the Vaudenay algorithm so that it can function as designed.

Webmail?

[gmuslera]

The problem seems to be when you have a long session with the server, be webmail, imap over ssl or whatever that makes you be in ssl mode for a lot of time. If you are connected in ssl mode to a site where you be for an hour, and at last you buy something with your credit card, you credit card transaction will be vulnerable. Is not related to what travels, but for how long you are connected.

email...

[RAMMS EIN]

The one service I can think of that this poses a serious threat to is email (especially POP3, IMAP could be secured by varying the length of the identifier, rendering the position of the password unpredictable), as it's one of the few services that send the password often. Well, it's not like email is in any way confidential; it's usually sent over unencrypted connections anyway. The real danger is in using the same password with multiple services, which opens up all those services once the password is obtained from any one of them.

I read all my email over an SSH link to the mail server, using the mail client installed there. This means I send my password over the net about once a week, namely only when I open a new SSH session. My /. pass is a different story, but that's a different password anyway.

---
Anyone who believes that corporate research can or should replace university research deserves to live in a world where this has taken place.

Re:Heise and OpenSSL developers tells the opposite

[lazyl]

Not quite.

The error messages are encrypted. The attacker can't read them. All his information is based on timing. Because of the implementation a padding error will return faster than a MAC error. After sufficient attempts the attacker can statistically guess which error he's getting. That info can be used to crack the cipher.

I don't know the details of the OpenSSL fix, but they don't have to change the error message to fix the problem. They just have to change the timing. So it's purely an implementation problem; nothing to do with the protocol.

I don't know why Vaudenay said (in the interview) that it was a problem with the protocol because according to the LASEC memo, it's not. Vaudenay didn't write the memo, so it's hard to guess how directly involved he was with the work. The project is based on a method of attacking SSL developed by Vaudenay though. From the memo:

In 2002, Vaudenay [10] presented an attack which enables the decryption of blocks provided that error messages are available (as a side channel attack) and sessions do not abort. This is not the case with TLS/SSL. We can solve the latter problem in the case where a TLS/SSL session includes a/several critical plaintext block which is/are always the same (e.g. a password). The former problem of availability of error messages (encrypted in TLS/SSL) is solved by performing a timing attack i.e. by measuring the taken for error messages to come back from the server. It is then possible to perform the attack over several sessions of TLS/SSL.

There's a much bigger hole

[crosbie]

1) Create a spoof website that impersonates a login page of a eCommerce/eBank site of your choice.

2) Send a junk mail (to everyone - false hits don't matter) advertising a special offer or something to get people keen to click the URL to your spoof login.

3) 99% of punters will a) not look for the 's' on https, and b) not look for the weeny padlock icon.

4) Harvest the passwords, use 'em, and then scarper.

SSL is only secure if a) the user knows how to be sure that it's in use, and b) can trust their own PC.