Bryan A Ford <brynosau...@gmail.com> writes: >The idea of encrypting TLS record headers has come up before, the most >important purpose being to hide record lengths and boundaries and make >fingerprinting and traffic analysis harder.
Argh, no! I sent the following to the SSH list a few days ago in support of someone else's suggestion to finally abandon this misguided idea: -- Snip -- SSL/TLS have used unencrypted lengths for twenty years without there being any (known) attack or weakness based on this. OTOH SSH has used encrypted lengths for nearly the same period, and there have been several attacks/weaknesses based on that. Security-wise, it has the opposite effect of the one intended, it makes the protocol weaker, not stronger. My real issue with it though is that, as you've pointed out, it makes it impossible to create an efficient streaming implementation. With TLS you read the length at the start, stream the rest into the target memory location, and decrypt in place. With SSH you have to read a single block, decrypt it, make sure you're not providing an oracle for the attacker, copy what's left around, read more encrypted data onto the end, decrypt the remainder, ugh. -- Snip -- Encrypting the length information is a serious step backwards both in terms of security and processing efficiency. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
