Data Transfer with SSID
Big problems almost always start as small problems – which is the best point in time to tackle them. This ancient wisdom, commonly attributed to the founder of Taoism, Lao Tzu, is probably known to many of our readers.
But size does not only matter in Lao Tzu’s teachings, but is also a theme of Guido Vranken’s recently published paper concerning the so-called HTTPS Bicycle Attack. Simply put, Vranken states that the usage of stream-based ciphers in TLS connections leads to a disclosure of the length/size of the payload when the network traffic is observed by a potentially malicious actor. The encryption effectively hides the content of the transmission, but the sizes of individual requests in sequence lets an attacker glimpse it’s structure of shape. Hence the name Bicycle Attack in reference to a gift-wrapped bicycle: Brand, color and the specific components of the item wrapped are unknown, but the fact that the item is indeed a bicycle is thinly veiled at best.
The concern, that the length of TLS payloads is not effectively concealed is not necessarily new. In September 2013, Alfredo Pironti of INRIA Paris-Rocquencourt released an Internet-Draft bearing the title Length Hiding Padding for TLS Protocol proposing some methods to avoid the disclosure of payload sizes, such as Range Splitting.
But Vranken’s publication does raise some new practical concerns regarding attack vectors based on this behavior. One interesting approach is to use known sizes of requests and responses to fingerprint specific sequences of HTTP requests. For example, requesting the login form of the popular blogging platform WordPress leads to a total of five requests with individual lengths. These are directly correlating to each other in a fixed ratio. Example:
Vranken uses the correlation coefficient (Bravais/Pearson) to identify the displayed sequence in a stream of encrypted requests. This constitutes an interesting approach, since the Pearson correlation is not a one-to-one numeric comparison: As long as the relative relations between the single requests are correct, identification is possible despite slight difference, such as for example different browser headers sent by the affected client. This approach potentially allows an attacker to passively identify software products being used by the target.
A second approach Vranken describes deals with the possibility of deducing the length of unknown factors, for example a password, from passive analysis. This does, however, require a number of prerequisites, such as knowledge of the specific browser being used as well as the specific resources being requested by the target. If all these prerequisites are met, an attacker might be able to deduce the length of a password from observing the difference in length between the baseline requests and the observed requests of the target.
This attack, as outlined in Vranken’s paper, appears only partially practical at this point in time. Even when successful, existent standard security controls such as account lockouts would still deal with most attempts of a brute-force attack against a password – even if the length of said password is known and the potential options to guess it are massively reduced.
The last example in the paper uses the scenario of an application that frequently updates a remote endpoint by sending GPS coordinates over a SSL-encrypted HTTP connection. By passively observing the lengths of said requests, an attacker could potentially guess the geographical movements of the target to a certain degree. An example:
If the sum of characters contained in the parameters for longitude and latitude is exactly two (2), an attacker can assume that the target is currently located within the area Cameroon and/or Congo. If this length increases to three characters (3), the target would most likely have moved to the north or to the east. This approach is limited in its practical usage though: If the sum of characters in the aforementioned parameters increases to four, deviations all directions become feasible assumptions.
All restrictions aside: Considering that this analysis can be conducted entirely passive without any tampering of the traffic it is targeting, it’s a legitimate to assume that this might be a considerable method of observing large amounts of network traffic for suspicious behavior.
Despite the potential risks implied by these scenarios, the question of relevance must be asked: Currently, in spring 2016, stream-based ciphers are rather unpopular, due to known problems with RC4. Until Salsa20 becomes more popular and is more widely used, the scenarios outlined above are currently to be considered rather unlikely. One exception might be the usage in which block-based ciphers are used stream-based (Galois/Counter) due to performance issues.
These limitations aside, an application-based solution the problem is moderately easy to achieve: Using Request Padding, applications could provide any sensitive field with a padding buffer, bloating the request to a uniform size, rendering analysis as described above mostly impossible.
Or, to keep Vranken’s analogy: If you don’t want your gift to be identified as a bicycle on first sight, maybe put it into a wooden crate.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here