21

Recently a novel attack on TLS stream ciphers was developed by Guido Vranken, dubbed Bicycle and referenced in this Websense's blog post.

It was based on a characteristic of stream ciphers that says that there is a 1:1 relation between plaintext length and ciphertext length (although they may not be the same), allowing an attacker to correlate some known data from the request and discover the length of the fields (password length, for example). If you know that the user has an 8-char passphrase, you will cut a lot of work out of the bruteforcing, coming up with a dictionary that will get you in after a few hours.

The full explanation is in the PDF hosted in the first blog post linked above, for those that care to understand how it really works.

Basically it affects all stream ciphers, notedly Galois Counter Mode (GCM), mainly used with TLS 1.2 for being part of the AEAD cipher suites. A quick search of the other AEAD ciphers shows that they are also stream ciphers, therefore also being vulnerable to this issue. Or are they not all affected?

So the question is, which cipher can be used? Block ciphers are not affected by this particular problem, but most of them have issues of their own, making this a question of "pick your poison" instead of bringing the antidote. Does anyone here know of a known cipher (recommended by NIST) that could be used with TLS 1.2 that does not bring its own flaws into the equation?

DarkLighting
  • 1,523
  • 11
  • 16
  • 12
    Funfact: You can't hide the message length and it's not an objective of crypto to hide it. Even CBC (the only non-streaming mode in use) does leak plaintext length by simply telling you [via the `length` field for each TLS fragment](https://tools.ietf.org/html/rfc5246#page-20). – SEJPM Jan 07 '16 at 15:19
  • 10
    I don't think this is novel attack. That all stream ciphers leaks the data length is well known, and no serious security systems relies on the attacker not knowing password lengths. Many server-to-server and REST APIs use fixed-length tokens (essentially passwords), in which the length is fixed into the API spec. In practice, knowing password length isn't very useful in breaking strong passwords; browsers reuses TLS connections fo; and natural variance in the data and header length; and if you enforce, say, minimum 12 character passwords, then knowing the length won't really help any. – Lie Ryan Jan 07 '16 at 16:03
  • @SEJPM - Why can't crypto hide the message length either deliberately or as a side effect? Encfs can round up filenames to the block size of the encryption cipher. So, for example, with a blocksize of 16, an attacker can't tell the difference between a single character filename and a 16 character filename (which might otherwise leak enough information for an attacker to find the file he's seeking) – Johnny Jan 07 '16 at 16:58
  • Even for a purely numeric password, the number of possible passwords of length equal to n is 10^n whereas the number of possible passwords of shorter length is 10^(n-1)+10^(n-2)+... , less than 10^n/9. So if you brute-force from short to longer you gain only about 10% of time (much less if letters and special chars are allowed). So for *passwords* I doubt there is much gained by the attack. – Hagen von Eitzen Jan 07 '16 at 19:52
  • @SEJPM actually not; `TLSPlaintext` is only used during initial handshake, after that it's `TLSCiphertext` which exposes only the encrypted length which includes padding if CBC (and MAC in all cases, but that has length fixed per version&ciphersuite). ALSO: the PDF example ignores the fact that even security ignorami should know to include non-alphanumeric aka "special" in password and *in HTTPS request* (but not SSL/TLS generally) almost all non-alphanumeric encode as 3 and sometimes 6 or more bytes, giving a discouragingly wrong length without any effort at all. ... – dave_thompson_085 Jan 08 '16 at 00:00
  • ... Plus it's not hard to choose 8-char passwords, even limited to ASCII printable (which you probably should for browsers), with 52 bits entropy, which I guarantee no dictionary has a nonnegligible probability to break in 'hours', and at the same time easy (and too common) to choose passwords of 15 or 20 or even more characters that fall to a suitable dictionary in minutes. IIRC some of the Ashley Madison breached passwords were "secretloveaffair" -- 16 chars but probably seconds to break. – dave_thompson_085 Jan 08 '16 at 00:07
  • I'd hope that anyone serious about security would consider "... Does anyone here know of a known cipher (recommended by NIST) ... " as an oxymoron in the context of assuring security. This is NOT to cast aspersions on NIST's integrity - just noting that assuming such integrity as a key part of overall security is inconsistent with the object of the exercise in this field. – Russell McMahon Jan 08 '16 at 08:33

1 Answers1

46

The PDF of the article begins with:

It is usually assumed that HTTP traffic encapsulated in TLS doesn't reveal the exact sizes of its parts

This is not what I would have said. Rather, let's say that it is usually assumed by people who do not know better. TLS is encryption and encryption is good at hiding data contents, not data length. This is not exactly novel. However, it is true that the idea that TLS "hides everything" is still widespread (it is wrong, has always been, but education is slow, especially when people don't want to be educated).

Some people have argued that CBC-based cipher suites imply a padding that might somehow hide the fine details of the encrypted data length, since the length is padded to a multiple of the block size. This "hiding effect" does not really hold in practice, so it is saner to assume that no cipher suite will help you hide the length of the data you are sending.

If you really want to hide, say, the length of a user's password, then you must do it properly, by making the sender pad it to a fixed length before sending it (this can be done in a few lines of Javascript). However, consider that the length will still leak in many places; notoriously, the length will impact processing time on both the client and server, and this can be detected (at least, that kind of side-channel leakage was demonstrated in lab conditions). Also, when the user types his password, any attacker within earshot can simply count the strokes and obtain the same information (practically, by recording the noise with his smartphone and playing it later on at low speed -- the attacker may even get information on the actual letters because they make distinct noises in a typical keyboard).

A realistic answer would be to point out that if leaking the password length allows breaking it, then this is a poor password to begin with, and you should probably fix that. The length is only a small part of the issue, which is that bad passwords are bad.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • @DavidGrinberg I would have put it slightly different. Authentication algorithms requiring the server to see the password are bad. Get rid of those and you not only eliminate the problem of leaking password length through the encryption, but you also eliminate most of the problems associated with password reuse, and the problem of poorly hashed passwords. – kasperd Jan 07 '16 at 19:30
  • @kasperd That may go down the dangerous path of client-side hashing or JS crypto which are even worse than the server seeing the password. All client-side security measures must assume the server and HTTPS are secure. – billc.cn Jan 07 '16 at 19:47
  • @billc.cn Doing most of the hashing in javascript code will make it possible to increase the iteration without it becoming a DoS vector that can consume loads of CPU time on the server side. And using javascript to prevent the server from seeing the password will only be a very minor security benefit. There are a few ways to use javascript crypto for good and loads of ways to use it poorly. What I had in mind was something implemented natively in the browser such that the browser can guarantee that even a malicious site doesn't get to see the user's password. – kasperd Jan 07 '16 at 20:00
  • @kasperd A solution alreay exist: client certificate authentication, but it is hard to deploy. Alternatively federated authentication partially alleviates the problem. // I think you agree that any solution that is done in script will obviously not be safe. The browser will have to take over password entry which will be web designers' worst nightmare. And how to prevent a pwned server becoming a phising site for plain text password? It will be very difficult to educate users to distrust the same site with a valid certificate.... – billc.cn Jan 07 '16 at 20:22
  • 1
    @billc.cn I was thinking more along the lines of [SCRAM](https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-15). – kasperd Jan 07 '16 at 21:37
  • (It certainly seems like) By just having the server not unpad the password, one can make the server's processing time not leak anything about the password's length that doesn't follow from the ciphertext's length. ​ ​ –  Jan 08 '16 at 08:43