3

On a website with user accounts, all HTTP requests coming from the submission of a login form kind of contain the same info, there are only a few things that are different in the HTTP requests, such as the entered username, the entered password, and a few headers, such as User-Agent. If HTTPS is used to encrypt the request and a hacker would inspect the encrypted request and know the user tries to login as Alice using Firefox, would the hacker be able to figure out the length of the password by looking at the length of the encrypted HTTP request?

I guess my question is if (or to which extent) HTTPS is leaking the length of the encrypted message.

Improve this question
1
  • Knowing Firefox is not enough; to resolve the request headers within a few chars, attacker needs version, build, platform, configuration, and environment. In addition any competent website today includes some kind of CSRF token, and that can vary in a way that defeats attacker, although it often doesn't.
    – dave_thompson_085
    Commented Jun 3, 2021 at 0:03

2 Answers 2

Reset to default
8

HTTPS leaks password length only roughly based on input. For example, AES CBC operates with with blocks of 128 bits. If total plaintext size is dividable by block size without remainder, then ciphertext size will match plaintext size. If not, then plaintext is padded with bits to make plaintext message dividable by 128 without remainder and only then plaintext is encrypted. In other words, ciphertext size is calculated (for AES CBC) as:

cipherTextLength = (plainTextLength / 16 + 1) * 16

having ciphertext size and exact source message where only password is variable and unknown, then you can guess password length with 16 byte precision.

Updated based on comments: unlike block cipher, stream ciphers (like AES GCM) perform bit-by-bit encryption and total ciphertext length will equal plaintext length in bits, i.e.

cipherTextLength = plainTextLength

however, it doesn't mean that block cipher is better than stream. In fact, AES GCM is slightly better than CBC in security and much better in performance, because it can parallelized. But that is a very different question.

p.s. thanks to nobody for corrections.

Improve this answer
8
  • 2
    TLS also allows CHACHA20 and AES-GCM which are stream ciphers. So I believe they would leak the exact length of the plaintext request.
    – nobody
    Commented Jun 2, 2021 at 13:10
  • There's a lot of variability in the length of the data portion of the associated TCP packets. I don't think the password is usually sent as an entirely separate packet.
    – Royce Williams
    Commented Jun 2, 2021 at 15:28
  • TCP packet doesn't provide any security, TLS works on top of TCP. TCP is just a reliable transport to carry upper-level protocol data.
    – Crypt32
    Commented Jun 2, 2021 at 15:43
  • 1
    Well, then I think you shouldn't be giving a blanket statement saying "HTTPS leaks password length only roughly based on input." Because TLS could be using a stream cipher and then the exact length would be leaked, no?
    – nobody
    Commented Jun 2, 2021 at 18:06
  • 3
    A padding scheme that doesn't pad for exact block input must corrupt some user data and has not been acceptable for decades. For TLS all ciphersuites that use CBC (in 1.2 and below) by default first add HMAC (20-32 bytes, known) then pad (at least 1 byte and permitted to be more than a block up to 255, but rarely is); however if 7366 is implemented (which Eve can see) the order is reversed. AEAD suites like ChaCha and/Poly GCM add 8 or 16 bytes MAC (known) and in 1.3 there is also an inner/hidden rectype (at least one byte) and optional padding (varies).
    – dave_thompson_085
    Commented Jun 3, 2021 at 0:15
0

When you don't use "padding" the size of an encrypted message corresponds mostly linearly to the size of the clear text message.

A 10 character clear text message will have a much shorter encrypted message than a 1 TB clear text message.

The current HTTPS specification, the TLS 1.3 specification allows for but does not mandate specific padding: https://datatracker.ietf.org/doc/html/rfc8446#section-5.4

But most block ciphers do require plain text input that is a multiple of the block size, so messages may have to be padded to bring them to this length.

In that case supplying a slightly longer or shorter password will only increase respectively reduce the amount of padding needed without changing the over-all total number of blocks and an attacker won't learn anything.
Once the password length increases so much that the blocksize boundary is crossed, then the attacker still won't know exactly by how much the clear text message size was increased due to that padding.

Improve this answer
1
  • 2
    Blockciphers aren't really relevant here, since all modern ciphersuites behave like a stream cipher in that regard (including AES-GCM).
    – CodesInChaos
    Commented Jun 2, 2021 at 19:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .