# Can the lengths of HTTPS requests be used to deduce which public pages on a site are visited?

I thought of this recently:

There are some websites which have many publicly accessible pages, some of which could be embarrassing despite being public (e.g. Wikipedia). The HTML for these pages also references other resources (other pages, images, Javascript, etc) whose sizes are also known to the attacker.

An attacker can observe the lengths and timing of requests made over an HTTPS connection. Given this, can an attacker reliably deduce which page a victim visits despite the connection being "secure"?

I know there is some message padding to integer multiples of a certain length; however, could the lengths of enough messages be combined to give a good guess as to which pages the victim visits? Also, has there been any work done on this or a similar attack?

Here's an example:

Website A has 3 public pages with the following sizes:

A1 100 bytes - embarrassing
A2 200 bytes
A3 100 bytes


Let's assume that A1 and A2 reference an external resource with size 300 bytes.

If an attacker observes a response with length 100, she knows the victim has requested either page A1 or A3. Then, if she observes a response of length 300, then she can deduce that the victim has visited page A1.

• This is possible. On our university, the "Network Security" course actually demonstrates this in one of the lectures. – dsprenkels Aug 2 '18 at 7:20
• Do you have a link to more specifics? – theunamedguy Aug 2 '18 at 15:33
• While it's not directly related, it remembers me of the attack which abused compression before encryption to leak a secret (like cookies) even though it is protected by TLS. This shows that length-related side-channel-attacks are possible on HTTPS. – VincBreaker Aug 5 '18 at 9:44

Yes, you can often learn a lot just from the length of encrypted data (more generally the segmentation pattern of an encrypted stream). All the attacks that I know about leverage the data-dependent effects of compression.

It sounds like your question covers both HTTP requests and responses. There are indeed attacks that target exactly this side-channel. See the discussion here:

• CRIME attack: if the user's HTTP requests support compression (which is possible as a TLS option) then private cookie data can be stolen by causing the victim to make many HTTP requests that include attacker-controlled content, and then measuring the size of the resulting (compressed) requests.

• BREACH attack: Similar but works on the HTTP response.

Regarding the length of HTTP responses, here is a proof of concept showing how the length of different images from Google Maps can be used as a "fingerprint" of what area you are browsing. This one is probably the simplest example of this kind of attack, and closest to the simple fingerprinting thing you describe:

Vincent Berg: I can still see your actions on Google Maps over SSL

The same concepts generalize to encrypted streams. When the compression uses variable-bitrate encoding, it leads to different segmentation/burst timing patterns.