Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I am using Firefox browser version 28.0. To access https://www.yahoo.com, I put a proxy with a self-signed certificate in between and my client PC can access the HTTPS site. I then sniffed traffic in my client PC and observed a strange thing;
Each HTTPS request sent from Firefox is split into two TCP segments. One is only one character long ("G"), the other includes the rest ("ET / HTTP 1.1 ...")
Why does Firefox behave like this?
This is the "1/n-1 split" technique which has been deployed in SSL libraries as a workaround for the BEAST attack.
The BEAST attack is the application to a Web context of a chosen plaintext attack. The attack works when:
In SSL 3.0 and TLS 1.0, the IV for a record is the last encrypted block from the previous record, so the attacker can see it by spying on the line (the attack setup supposes that the attacker can eavesdrop on the line and send information to some evil Javascript planted in the victim's browser -- this is realistic in the "WiFi in a restaurant" scenario, with an attacker-controlled access point).
The "1/n-1 split" prevents the attack because the frame with 1 byte includes a MAC value, that the attacker cannot predict, and that gets encrypted as well. The subtlety is a question of timing: when the attacker gets to choose the data which will be encrypted, neither the "1" nor the "n-1" records have been emittted; only when the attacker has pushed his n bytes will the two records be computed and sent. The net effect is that the attacker will not be able to know the IV for the n-1 record before sending his n bytes to encrypt. The attacker will still be able to predict the IV for the "1" record, but one byte is not enough for the attacker to pull off the BEAST attack.
Theoretically, a "0/n split" would be possible (a first frame with no data at all, then the actual frame) and would be even better (in an academic way), but, though it is supported as far as the standard is concerned, a number of deployed implementations choke on empty records, so the "1/n-1 split" is deemed more practical.
The BEAST attack also requires that the attacker gets a lot of control on the bytes he needs to send, e.g. he must not be restricted to only ASCII characters; the prototype attack relied on a pair of extra vulnerabilitiies which have been fixed since, so even without the 1/n-1 split, the attack would no longer work. But SSL library designers are cautious and don't want to see the SSL security being jeopardized by a vulnerability in another component of the application.
TLS 1.1 and later versions are immune because their record header includes a record-specific IV.
