Some legacy TLSv1.0 clients react poorly to certain BEAST mitigation
methods. (In particular, every TLSv1.0/PEAP client I have tested fails
to function with the 1/n-1 content split method, but works just fine
with the 0/n split method.) For greater compatibility, this patch adds a
three-way switch to control the BEAST countermeasure used with the given
connection, as well as tests and documentation updates.
Because the switch defaults to 1/n-1 mode, there are no known
incompatibilities. The 1/n-1 content splitting mode was the default for
all SSLv3 and TLSv1.0 connections that did not use an RC4 cipher suite.
TLSv1.1, TLSv1.2, and connections using an RC4 cipher are not vulnerable
to BEAST, and do not need content splitting.
It is possible -but unlikely- that I have misunderstood how the 0/n
content splitting method works. Every description of the 0/n splitting
method that I have read indicates that it will generate an extra
Application Data record that is discarded by the receiving side. Packet
captures indicate that an extra Application Data record is generated
when using either the 1/n-1 or the 0/n splitting method. The unit tests
demonstrate that -unlike the 1/n-1 method- the 0/n splitting method does
not generate an extra plaintext message. That is to say, given the
payload "Hello world" when one uses the 1/n-1 method, the receiver will
receive "H" followed by "ello world". If one uses the 0/n method, the
receiver receives "Hello world". (Content splitting is done in
The feature is implemented as an ssloption called 'beast_mitigation'
that is valid for both servers and clients. The option has three legal
values: 'one_n_minus_one', 'zero_n', and 'disabled'.
This option could have also been implemented as an environment variable
(see 'protocol' and 'protocol_version'), but 'padding_check' -a similar
compatibility option- did not have a corresponding environment variable.
The option could have been a simple on/off switch, but that would have
been strictly less useful and not significantly easier to implement.