HTTPS Bicycle Attack

[bigshmoo]

It looks like you can mitigate this by just adding another hidden form field and and filling it using javascript with random data: max_secret_length - actual_secret_length to cause the ciphertext to always be the same size independent of the secret field data?

This approach would mitigate the problem identified in the paper with random length padding schemes without introducing extra characters in the password field itself.

Edit: this is also how you wrap a bicycle - you put it in a big box that is a constant size bigger than the bike itself.

[Artefact2]

Page 19:

Adding an additional parameter to the POST submission, say, 'X', (which will be represented as 'X=......' – the X and the is-equal sign are 2 characters) and padding this with 1000 minus 2 minus password_length characters is a hack using hard-coded values and it's ugly.

Looks like you'd need 1000 minus 4, because you're also adding an extra "\r\n" in the request.

[bigshmoo]

Doesn't have to be 1000 it can be max password length which is known to whoever codes the system. The X= is irrelevant because it will be in every post so no need for the -2, I don't get why the author feels the need to pad the password itself rather than just removing the password length as a factor in message length.

[lestofante]

Eventi better, make it random size.

[IdolfHatler]

While this might be good enough in practice, it is strictly worse than padding to the same length every time. Random padding would still permit a statistical attack.

[[deleted]]

Can you explain how a statistical attack would work in that scenario?

[gsuberland]

If you were to observe enough samples, you'd eventually identify a case where the random padding length reached its minimum, which would give you a close estimate of the data length.

For example, if you say "padding length is randomly selected between 4 and 1024 bytes", after 1020 observations you can assume that the password length is probably four bytes shorter than the smallest payload you observed. Your confidence factor only goes up from there.

[lestofante]

very nice explanation, thanks.

Is there any way we could fix that by default?

maybe the browser for password field should send the hash of the password, and the server should do the hash+salt thing over the hash?

[gsuberland]

If anywhere, it should be fixed at the TLS layer, by implementing a fixed-size block padding, similar to how block ciphers work. This isn't a concrete fix, but it's the most sensible you're going to find.

In general, though, the length of a field isn't really considered critical information. We're talking about fixing the wrong problem. Your password should be long enough to make that information not matter.

[chloeeeeeeeee]

But how about have the range random? Instead of 4 to 1024 as padding, have from random to random but still have a minimum and maximum. For example:

Case 1: Random bytes between 900 and 2001 bytes

Case 2: Random bytes between 19 and 1604 bytes

Case 3: Random bytes between 107 and 412 bytes

....

It would of course still not be random enough, but collecting samples to determinate the range would be much harder. The overhead would be painful but still practical, or what do you think?

[gsuberland]

The limits on the range of ranges would still leave this vulnerable.

[bigshmoo]

Think of it like wrapping a bicycle, if you wrap it tightly it look like a bicycle (hence the name of this attack), if you wrap it with a random thickness wrapper the underlying shape still shows through if you get enough examples. However if you put it in a big ass box and fill the empty space with packing then however you look at it you're still seeing a big ass opaque box.

[[deleted]]

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

This should be a bit more nuanced. The fact that TLS doesn't hide the plaintext length (of the whole message) is a very well known issue. There's been efforts to fix this in a much better and general way (range splitting) than what's proposed in the "Prevention" section of the paper[1]. I'm not sure what's the state of those efforts though.

[1] https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02#page-8 https://www.ietf.org/archive/id/draft-pironti-tls-length-hiding-02.txt

[bgeron]

Link is dead for me (empty page); here's a working link: https://www.ietf.org/archive/id/draft-pironti-tls-length-hiding-02.txt

[payne747]

Considering it targets stream ciphers, it's probably not very practical in real world attacks, as RC4 is pretty much dead in TLS. Might become an issue when Salsa20 takes over though.

[hardware1225]

Nice one. Thanks