The HTTPS bicycle attack

While HTTPS is an encrypted protocol, it does leak a certain amount of information about the communication—the source and destination addresses, at a minimum. But a newly reported technique can actually "see" inside of the encrypted data without requiring the key or cracking the encryption. By using the length information inherent in the protocol, some simple math can be done to determine the length of some portions of the encrypted data, which can be used to figure out things like password length. It only requires a recording of the packets in a session of interest, along with a bit of information about the target, which means it can be performed days or months later.

In a paper [PDF], Guido Vranken described the weakness that he has dubbed the "HTTPS bicycle attack". The name comes from the idea that wrapping a bicycle as a gift doesn't really hide what is inside the package. Similarly, HTTPS doesn't entirely obscure the contents of its encrypted payloads.

Vranken concentrates on stream ciphers in the paper, noting that they have a 1:1 relationship between the plain text and the cipher text; adding one byte to the plain text results in an additional encrypted byte in the HTTPS payload. The attack only considers messages that have the "application data" content type (0x17 in the first byte) and uses the length information stored at the fourth and fifth bytes of the message. From that, coupled with a little detective work, things like the length of a password submitted to the site can be derived.

The bicycle technique will be most effective for targeted attacks, where an eavesdropper can record the traffic to and from a host of interest. In particular, the "user agent" header being sent by the browser (or, really, its length) is helpful, though not necessarily required. It can be captured, along with other standard headers sent by the user's browser, from a regular HTTP request to any site. There may be other unknown headers in the HTTPS requests, but their length can be deduced from other encrypted requests as Vranken has shown.

The other major piece of the puzzle is that the attacker must also record their own session that exercises the web application in the same way that the victim has. Because they can decode their own traffic, the attacker gains the knowledge of the contents and lengths of various resources requested in the process. That allows the attacker to figure out which HTTPS messages correspond to the ones they are interested in.

For example, if a particular login page consists of half a dozen different resources (e.g. images, style sheets), each with a distinct length, it is relatively straightforward to isolate that part of encrypted stream even if the requests are handled in a different order. In addition, the analysis can ignore any constant difference in the sizes of the requests that comes from additional or different headers that the victim's browser sends. (Vranken used Pearson correlation to match a WordPress login page and its resources in the paper).

Once the messages of interest are identified, the request that sends the login credentials is scrutinized. Its length will consist of a mixture of known headers, unknown headers, and the actual form parameters that are being submitted. The length of the unknown headers can be derived from the other requests since the attacker knows the lengths they recorded from their own session. The difference between those other requests and what the attacker recorded can be used to adjust the length of the authentication message, which just leaves the length of the form parameters.

The login credentials consist of both a username and password, of course, so all of the analysis only gives the combined length of the two. That, again, is where targeting comes in. In general, finding out the username for a target is not that difficult. Subtracting its length gives the attacker the length of the target's password.

That may seem like a fair amount of work just to get the length of the password, but that can be used in various ways to potentially compromise the account (e.g. brute force, dictionary attacks). In addition, Vranken showed several other ways that the length of a string in a web request or response (e.g. geographic coordinates, IP addresses) might be used to peer inside the encrypted data to extract useful information.

Vranken offered some suggestions for mitigating the problem. Using JavaScript to hash the password (using SHA-256, say) on the client side would be one way to do that, since all passwords would hash to the same length. That would also mean that the server never has access to the plain-text password. While that would be advantageous in some ways, it would prevent the server from validating the password (e.g. that it must contain letters and digits), which might be undesirable.

Padding the password is another option, though there are some potential pitfalls there. Ensuring that the browser does not strip the padding characters is obviously essential. Variable-length padding seems attractive, but will actually leak information as well. Vranken recommended using the ASCII NUL ("\0") character for padding, then hexadecimal-encoding the password plus padding into a string to be sent to the server.

This attack is another reminder that encrypted communication is not necessarily a panacea. There are certainly government security agencies that have tons of HTTPS traffic stored that could be used to target a variety of web applications for a subject of interest. Placing the length parameter in the unencrypted portion of the message certainly helps here; if the message boundaries were obscured, this kind of attack would be more difficult, at a minimum.