ssl: Add BEAST mitigation selection option

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============2766631594707236867==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="HpxhVG7fAGAN8epsmvjjLTkpFa8AobUSD"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HpxhVG7fAGAN8epsmvjjLTkpFa8AobUSD
Content-Type: multipart/mixed; boundary="d8Obs4rXPUQOAmEX2afGur7fOg6MToeWd"
From: Kenneth Lakin <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: ssl: Add BEAST mitigation selection option

--d8Obs4rXPUQOAmEX2afGur7fOg6MToeWd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I'm more than happy to field questions or participate in additional
discussion regarding the proposed new feature.

The PR is at:
https://github.com/erlang/otp/pull/1041

You should be able to fetch with:
git fetch git://github.com/kennethlakin/otp.git beast-mitigation-options

And compare with:
https://github.com/erlang/otp/compare/master...kennethlakin:beast-mitigat=
ion-options
https://github.com/erlang/otp/compare/master...kennethlakin:beast-mitigat=
ion-options.patch

Here's the EEP Light describing the new feature:

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
ssl_record:split_bin/5.)

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.



--d8Obs4rXPUQOAmEX2afGur7fOg6MToeWd--

--HpxhVG7fAGAN8epsmvjjLTkpFa8AobUSD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXKDTAAAoJEDpEx4ha9HUKMwoQALCDQtSdKpZZsJKOvvsxl6Gx
d1y/XlmJHNvi/gLs8K3q9zbyr0A12a8FGWtKIg+td7FZZ28tnjCkDOnEBbt7IDDP
IItqRWApxb7kvM5JYn4OaE3trWqNbOs9hOWQN0HGdREAM9d9ET7HGqMFsfvOkDmo
ghcd0pl+F1MHVHVy4M1OsVktQUafe6Ge2oPxT3S9e7at9kZlal0Mjc3Y0EBZ1s6D
qjqVIcTsa8antxng5/63Q4V+Rp5+d5lyV6gLf9xNeqVEVUmnQ6VnMmE9BF3v1o2l
YAozFG/JtryVOCRrRsX4CmKUzvwmQEWO9Nv5yLo+PsGPxpZ9/e4apPsGz/bRx0MS
H7TBSe+zGCDBkX3yamqGfx2T4FeWw45qEXvmmgOlF2fnF2MJA7IRMnH6LLjB6u5s
+gHN8JxJCxRu6EXgSzeFtlxJtilLIu5xFUCXLYEVoPRT2Ro0E3Bk/DwxZrWMjG5c
ZyHAowl05Rw4TYxW8sYYKDgwevBjK1/eL4xDeIHkgdUnkMtN+dkaxTHc21rqeIJh
Xnef+V+IIW+W4vZ1hEdxw6XiCZpMc6IA3a0C+ynGVvCdWymMF/nn0F8UgI2yAQUo
gsYd4Ebve74k+F6d1qgMRoTAoJWcpv6xHhJvlZqN5gNou4o0giFsT9Z9EU2K4bWm
lFGLgs2SiYlPBKRhjzXg
=aHDG
-----END PGP SIGNATURE-----

--HpxhVG7fAGAN8epsmvjjLTkpFa8AobUSD--

--===============2766631594707236867==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches

--===============2766631594707236867==--