Is it possible to eavesdrop HTTPS encryptions by file size?

Question

I see that HTTPS uses symmetric encryption for the file transfer, often AES. I also read that AES uses padding to help obfuscate the data itself. Though I am curious how powerful that padding is when downloading files.

If a server has a public list of available downloads (in the thousands), and a user were to download one over HTTPS, would the padding be enough that it would be impossible to know what file was being downloaded? Or by inspecting file HTTPS traffic transfer sizes, would it be possible to know exactly what was downloaded?

Answer 1

The padding isn't really meant to hide file size, if the domain doesn't serve any other content (ie, a dedicated domain for file downloads), their size all differs by more than TLS maximum 16 KB record, the user is confirmed to only download one file and there's no redownloading of some parts, then it can be deduced what exactly is the file that has been downloaded.

However, if the user downloads another file during that period, cancels it after a random delay, and the combined total transfer exceeds at least two files in the collection, it would be impossible to conclusively determine the actual file that is downloaded to completion.

Answer 2

TLS (the security layer that protects HTTPS) doesn't actually transfer files at all - just streams of bytes, which may flow or stop flowing in either direction at any time - but HTTPS requests are predictable enough that an attacker monitoring them can often recognize when a request starts and stops, and when a response starts and stops. The attacker has no way to know for sure if a given response contained a "file" or not, but if it's a wildly different size than other content (e.g. web pages, scripts, stylesheets, images, etc.) then it's reasonably likely. ("file" in quotes there because you can't actually transfer a file over HTTPS, you can only transfer data which you may have read out of one file, and you can tell the client that it should write the data into a file, but the client is under no obligation to obey and also can't tell whether the data came from a file originally or not.)

To address your specific scenario, if the downloads are different enough sizes (a few tens of bytes should be different enough, a few hundred bytes is definitely enough), an attacker can probably figure it out. Just remember that you're not only looking at the "list of available downloads" but also all other content the client might get from the server, such as images that are part of web pages, or search results in the form of JSON, or whatever.

The main obstacle to recognizing a message by length is not the padding - padding on TLS is never more than 16 bytes and is in fact skipped entirely for the most common modes in modern TLS - but rather the other stuff sent along with the download (the HTTP response headers, in particular). There's also some cryptographic metadata (nonce, authentication tag, etc.) but that's fixed-length and fixed-location so the attacker can just not count it.

If you want to, you can easily add additional padding to HTTPS responses that rounds files out to a particular length. You could either pad the body (with some way to tell the client "hey, the body is actually only length X"), or add arbitrary-length nonsense in the headers (which the client will ignore unless asked about specifically). This does of course increase the amount of data you must transmit.