Improve documentation related to SWEET32 and --reneg-bytes
PATCH 1/1 Improve documentation related to SWEET32 and --reneg-bytes
There have been several support questions related to the enforced renegotiation happening in OpenVPN v2.3.13. This will also be visible to users when they upgrade to v2.4.0.
These patches updates both master (including release/2.4) and release/2.3 branches with additional details to hopefully make it a bit less surprising.
--
kind regards,
David Sommerseth
OpenVPN Technologies, Inc
PATCH 1/1 docs: Further improve --reneg-bytes and SWEET32 information
There are still some support tickets related to SWEET32 and our defult enforced --reneg-bytes 64 when using weaker ciphers (less than 128-bits cipher blocks). Try to clarify this even more.
Also fix a few mistakes, saying less than 128-bits and not 128-bits and less.
--- Changes.rst | 6 +++--- doc/openvpn.8 | 13 ++++++++++--- 2 files changed, 13 insertions(+), 6 deletions(-)
Changes.rst +3 -3
@@ -57,10 +57,10 @@ Improved UTF-8 support Behavioral changes ------------------ -- OpenVPN will complain loudly about ciphers with 128-bits block sizes or less +- OpenVPN will complain loudly about ciphers with block sizes less than 128-bits - OpenVPN will by default re-negotiate the tunnel after 64MB when used with - ciphers using cipher blocks of 128-bits or less + ciphers using cipher blocks sizes less than 128-bits - Remove --enable-password-save option to configure, this is now always enabled
@@ -121,7 +121,7 @@ Version 2.3.13 Ciphers with cipher blocks less than 128 bits will now do a renegotiation of the tunnel by default for every 64MB of data. This behaviour can be - overridden by explictly setting --reneg-bytes 0 in the configuration file, + overridden by explicitly setting --reneg-bytes 0 in the configuration file, however this is HIGHLY discouraged. This is to reduce the risk for SWEET32 attacks. The general recommendation
doc/openvpn.8 +10 -3
@@ -4612,11 +4612,18 @@ such as TCP expect this role to be left to them. .B \-\-reneg\-bytes n Renegotiate data channel key after .B n -bytes sent or received (disabled by default). +bytes sent or received (disabled by default with an exception, see below). OpenVPN allows the lifetime of a key -to be expressed as a number of bytes encrypted/decrypted, a number of packets, or -a number of seconds. A key renegotiation will be forced +to be expressed as a number of bytes encrypted/decrypted, a number of packets, +or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer. + +If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0,but this is +.B HIGHLY DISCOURAGED +as this is designed to add some protection against the SWEET32 attack vector. +For more information see the \-\-cipher option. .\"********************************************************* .TP .B \-\-reneg\-pkts n
Signature · 1 line
1.8.3.1
Re: [Openvpn-devel] [PATCH release/2.3] docs: Further improve --reneg-bytes and SWEET32 information
Hi,
doc/openvpn.8 such as TCP expect this role to be left to them. · line 4623
Quoted 3 lines · David Sommerseth
doc/openvpn.8 +3
-0+If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0,but this is
(As in the patch for master:) missing space behind the ,.
ACK once that's fixed.
-Steffan
Re: [Openvpn-devel] [PATCH applied] docs: Further improve --reneg-bytes and SWEET32 information
In reply to David Sommerseth-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Your patch has been applied to the release/2.3 branch
commit 49e6ce5b9dea9b7beadb9a6e2586770090c5556b
Author: David Sommerseth Date: Wed Dec 21 21:54:50 2016 +0100
docs: Further improve --reneg-bytes and SWEET32 information
Signed-off-by: David Sommerseth <[email protected]...>
Acked-by: Steffan Karger <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg13662.html- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYXS4bAAoJEIbPlEyWcf3y6o4QAMOWyes79cq1Gmrh4MFFR07C ASo7dJiKQ6btkJIuvkTxS/72rBvqQhAP9H6S4eNF7I84fKSNXKtRjuNIqW0QqUpD XdwFOOXj91+2bjJFae0ixBWJVLi6Q1Dn1cG5S37mmKqoRTuoQ7amS7BblGQF4S5p z6gleXfNvDsSOlpqI0TfRXwq//8Nx6C7WiBIrPl8WfvDz4Yh+Ub1gn8hozZKvXso lkF1coTlfy2e45LsSo9MRZESC03mD42EduIIiNkt89nVFMt3Xfh3z/aDeA+UnFpG N4QpH7Sv1t2PRPf6iBGgkvZCo8XIFnotcYMTB8b3JXA0/XZ/HpWeEQhMwwGn+5Vb zRFaPwCO+IbdDrEvzFGxlyOtGyO/gfgVdrGrBnN+L+bgJKCaB0hTlWrnHgRFGWWa zBuirkHRw46jjY3dIjZ63+Od0ki2rV3slSCH2TLgMg4QNBX4KswqkZCyl324KEcp /mFouCgIvCJIDG9d+6law+hOuzvyFgYK/52vkQOPjqMsmY9k6vTx8aMaWIG0dk0f h6ffg3Ns0KKe1qW8YB863KOUaBFkKTs/+s0CAO8qh0TSHW9maZ1p8Fsz5mIuLD6n tMsI2+/I1e8qDFFu4Vwbg54e9p+wylm1FczsF8HS7x8398v0eYcsU2Bx47rNIt7t h8ClmMdgY/8ZXJ6zEtK6
=VTeN
-----END PGP SIGNATURE-----
PATCH 1/1 docs: Further enhance the documentation related to SWEET32
In reply to David SommersethThe git master/2.4 code lacked some useful information about the changes to --reneg-bytes, SWEET32 and weak ciphers (less than 128-bits cipher blocks)
--- Changes.rst | 6 ++++++ doc/openvpn.8 | 13 ++++++++++--- 2 files changed, 16 insertions(+), 3 deletions(-)
Changes.rst +6 -0
@@ -182,6 +182,12 @@ Deprecated features User-visible Changes -------------------- +- When using ciphers with cipher blocks less than 128-bits + OpenVPN will complain loudly if the configuration uses ciphers considered + weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by + default do a renegotiation for each 64MB of transported data (``--reneg-bytes``). + This can renegotiation can be disabled, but is HIGHLY DISCOURAGED. + - For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields are now exported to the environment, where each second and later occurrence of a field get _$N appended to it's field name, starting at N=1. For the
doc/openvpn.8 +10 -3
@@ -4876,11 +4876,18 @@ such as TCP expect this role to be left to them. .B \-\-reneg\-bytes n Renegotiate data channel key after .B n -bytes sent or received (disabled by default). +bytes sent or received (disabled by default with an exception, see below). OpenVPN allows the lifetime of a key -to be expressed as a number of bytes encrypted/decrypted, a number of packets, or -a number of seconds. A key renegotiation will be forced +to be expressed as a number of bytes encrypted/decrypted, a number of packets, +or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer. + +If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0,but this is +.B HIGHLY DISCOURAGED +as this is designed to add some protection against the SWEET32 attack vector. +For more information see the \-\-cipher option. .\"********************************************************* .TP .B \-\-reneg\-pkts n
Signature · 1 line
1.8.3.1
Re: [Openvpn-devel] [PATCH master+v2.4] docs: Further enhance the documentation related to SWEET32
Hi,
Changes.rst Deprecated features · line 189
Quoted 7 lines · David Sommerseth
User-visible Changes
--------------------
+- When using ciphers with cipher blocks less than 128-bitsChanges.rst +4
-0+ OpenVPN will complain loudly if the configuration uses ciphers considered + weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by + default do a renegotiation for each 64MB of transported data (``--reneg-bytes``). + This can renegotiation can be disabled, but is HIGHLY DISCOURAGED.
There's a can too much here.
doc/openvpn.8 such as TCP expect this role to be left to them. · line 4887
Quoted 3 lines
doc/openvpn.8 +3
-0+If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0,but this is
Missing a space behind the ,
doc/openvpn.8 such as TCP expect this role to be left to them. · line 4890
Quoted 3 lines
+.B HIGHLY DISCOURAGED
doc/openvpn.8 +2
-0+as this is designed to add some protection against the SWEET32 attack vector. +For more information see the \-\-cipher option.
-Steffan
PATCH v2 1/1 docs: Further enhance the documentation related to SWEET32
In reply to David SommersethThe git master/2.4 code lacked some useful information about the changes to --reneg-bytes, SWEET32 and weak ciphers (less than 128-bits cipher blocks)
v2 - Fixed a couple of grammar/typo issues
--- Changes.rst | 6 ++++++ doc/openvpn.8 | 13 ++++++++++--- 2 files changed, 16 insertions(+), 3 deletions(-)
Changes.rst +6 -0
@@ -182,6 +182,12 @@ Deprecated features User-visible Changes -------------------- +- When using ciphers with cipher blocks less than 128-bits + OpenVPN will complain loudly if the configuration uses ciphers considered + weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by + default do a renegotiation for each 64MB of transported data (``--reneg-bytes``). + This renegotiation can be disabled, but is HIGHLY DISCOURAGED. + - For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields are now exported to the environment, where each second and later occurrence of a field get _$N appended to it's field name, starting at N=1. For the
doc/openvpn.8 +10 -3
@@ -4876,11 +4876,18 @@ such as TCP expect this role to be left to them. .B \-\-reneg\-bytes n Renegotiate data channel key after .B n -bytes sent or received (disabled by default). +bytes sent or received (disabled by default with an exception, see below). OpenVPN allows the lifetime of a key -to be expressed as a number of bytes encrypted/decrypted, a number of packets, or -a number of seconds. A key renegotiation will be forced +to be expressed as a number of bytes encrypted/decrypted, a number of packets, +or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer. + +If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0, but this is +.B HIGHLY DISCOURAGED +as this is designed to add some protection against the SWEET32 attack vector. +For more information see the \-\-cipher option. .\"********************************************************* .TP .B \-\-reneg\-pkts n
Signature · 1 line
1.8.3.1
Re: [Openvpn-devel] [PATCH master+v2.4 v2] docs: Further enhance the documentation related to SWEET32
Hi,
Quoted 46 lines · David Sommerseth
The git master/2.4 code lacked some useful information about the changes to --reneg-bytes, SWEET32 and weak ciphers (less than 128-bits cipher blocks)
v2 - Fixed a couple of grammar/typo issues
Signed-off-by David Sommerseth <[email protected]...>--- Changes.rst | 6 ++++++ doc/openvpn.8 | 13 ++++++++++--- 2 files changed, 16 insertions(+), 3 deletions(-)Changes.rst +6
-0@@ -182,6 +182,12 @@ Deprecated features User-visible Changes -------------------- +- When using ciphers with cipher blocks less than 128-bits + OpenVPN will complain loudly if the configuration uses ciphers considered + weak, such as the SWEET32 attack vector. In such scenarios, OpenVPN will by + default do a renegotiation for each 64MB of transported data (``--reneg-bytes``). + This renegotiation can be disabled, but is HIGHLY DISCOURAGED. + - For certificate DNs with duplicate fields, e.g. "OU=one,OU=two", both fields are now exported to the environment, where each second and later occurrence of a field get _$N appended to it's field name, starting at N=1. For thedoc/openvpn.8 +3
-3@@ -4876,11 +4876,18 @@ such as TCP expect this role to be left to them. .B \-\-reneg\-bytes n Renegotiate data channel key after .B n -bytes sent or received (disabled by default). +bytes sent or received (disabled by default with an exception, see below). OpenVPN allows the lifetime of a key -to be expressed as a number of bytes encrypted/decrypted, a number of packets, or -a number of seconds. A key renegotiation will be forced +to be expressed as a number of bytes encrypted/decrypted, a number of packets, +or a number of seconds. A key renegotiation will be forced if any of these three criteria are met by either peer.
doc/openvpn.8 such as TCP expect this role to be left to them. · line 4893
Quoted 10 lines
doc/openvpn.8 +7
-0+ +If using ciphers with cipher block sizes less than 128-bits, \-\-reneg\-bytes is +set to 64MB by default, unless it is explicitly disabled by setting the value to +0, but this is +.B HIGHLY DISCOURAGED +as this is designed to add some protection against the SWEET32 attack vector. +For more information see the \-\-cipher option. .\"********************************************************* .TP .B \-\-reneg\-pkts n
ACK
-Steffan
Re: [Openvpn-devel] [PATCH applied] docs: Further enhance the documentation related to SWEET32
In reply to David Sommerseth-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Your patch has been applied to the following branches
commit a256aee8e70ceb7059b9da69bc3e7cccbd094916 (master) commit 203d7c8b1fdab065aa0b2a522abe00dc39fa433a (release/2.4)
Author: David Sommerseth Date: Fri Dec 23 17:07:44 2016 +0100
docs: Further enhance the documentation related to SWEET32
Signed-off-by: David Sommerseth <[email protected]...>
Acked-by: Steffan Karger <[email protected]...>
Message-Id: <[email protected]...>
URL: https://www.mail-archive.com/[email protected]/msg13682.html- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYXmKAAAoJEIbPlEyWcf3yLuEP/0dhBpaqRi07Uw26CJ3dEoF/ B4/Xe9wAxth+/NQDh5x+XUAQEr5aOH8bDi7NMn+ZZ+oA180CudK4nJm9xZOA7jCS Po/BeQf6zeEgfNxOtrKELMrJpquM5sH4+RV33Do4RJjbdA9e9TEt/mMa049C+N88 IRZ7z4Fx+F40do9Zp7Kw6SYJixfZHiPi0hutKaXb9NQ8KLvHAz5GApeuXILCy7Js N1DiSgzccS3eTLuzviLQRj1iUvNipgHkU0Wy7FtJ6x8oY9XuWiorQn8q+wuDwWqr IR8BHRDqklJNLYe1nP0WebPBRIcCKUqDW3NXsSY2eqRoXZWSUTMO/KPQ4Z2BLfJc 2S3Ttl+9L9PMN/KL7/a0yeX/Qbj3+i0yzSQx9I3Tk7M0bQPsf4avnyfpBtrbEK5D +KWZI+UR+YOuYUvnjCzfuogiJCcxS4UX5P6ags3xQ7rnzZY5ns5SeDAlach0sGKZ EpnLbOLr5FTVsMGHL2iuTvDX3cdYFzrK6q/q1vPY7De9313UgciPT6afNslPLNKR 3Ilvx7EBrCv4IzVONHouRkoQ13kJ3+m6ULk/riH+YYmGHZqfXhfoTRrax/XGOmCl DamG2Dz46E5osu1ZDRQlt9vqdANH2Xs26ygNmz7W1d/90GqMSxSIGaRnMJKvgyyN 5d6xi5m6svD91twiFL0i
=8kEi
-----END PGP SIGNATURE-----