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?
length
field for each TLS fragment.TLSPlaintext
is only used during initial handshake, after that it'sTLSCiphertext
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. ...