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:
- The encryption uses a block cipher in CBC mode.
- Right before sending his bytes to encrypt, the attacker knows the IV that will be used with CBC mode.
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.