From ${URL} : Ciphers with 64-bit block sizes used in CBC mode were found to be vulnerable to birthday attack when key renegotiation doesn't happen frequently or at all in long running connections. Blowfish cipher as used in OpenVPN by default is vulnerable to this attack, that allows remote attacker to recover partial plaintext information (XOR of two plaintext blocks). External References: https://community.openvpn.net/openvpn/wiki/SWEET32 https://sweet32.info/ @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
I added 2.3.12 which includes this commit https://github.com/OpenVPN/openvpn/commit/610fdbbdb0abf65c1e7620143afccd62cd162a8f @arches please get 2.3.12 stable
Is an upgrade sufficient in this case? The referenced commit changes the list output of --show-ciphers, but as there doesn't seem to be cipher negotiation or transport of such in the data channel, it still use blowfish after upgrade. Seems a change away from this requires config change both on server and clients simultaneously
Stable for HPPA PPC64. (In reply to Kristian Fiskerstrand from comment #2) > Is an upgrade sufficient in this case? The referenced commit changes the > list output of --show-ciphers, but as there doesn't seem to be cipher > negotiation or transport of such in the data channel, it still use blowfish > after upgrade. Seems a change away from this requires config change both on > server and clients simultaneously Correct. I've been having a lovely evening setting up additional openvpn servers with alternative ciphers. The new version would help setting up new servers and clients, though.
Also good writeup at http://blog.cryptographyengineering.com/2016/08/attack-of-week-64-bit-ciphers-in-tls.html
https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible mitigants and confirms that cipher change in stable versions (<2.4) requires both server and client config change. It also mentions; 2. Renegotiate more often: If changing the cipher is not possible, for example because you don't control the server, or can not update all client configs on a short notice, you can renegotiate new keys more often. For example, add --reneg-bytes 64000 to your config to renegatiate after every 64 megabytes. I haven't seen any performance metrics on how this might affect things though.
(In reply to Kristian Fiskerstrand from comment #5) > https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible > mitigants ...and then you quoted a lot of it. > For example, add --reneg-bytes > 64000 to your config to renegatiate after every 64 megabytes. > > I haven't seen any performance metrics on how this might affect things > though. Well, for one thing, it temporarily blocks the connection after every 64 kilobytes of data during renegotiation. Not 64 megabytes as the advice suggests.
(In reply to Jeroen Roovers from comment #6) > (In reply to Kristian Fiskerstrand from comment #5) > > https://community.openvpn.net/openvpn/wiki/SWEET32 mentions some possible > > mitigants .. > > Well, for one thing, it temporarily blocks the connection after every 64 > kilobytes of data during renegotiation. Not 64 megabytes as the advice > suggests. Yeah, that likely won't work too well. So basically only way to solve it properly is setting up a secondary VPN server with changed config and do a rollout of clients to the new cipher whenever possible...
Stable on alpha.
amd64 stable
arm stable
x86 stable
sparc stable
ppc stable
ia64 stable. Maintainer(s), please cleanup. Security, please vote.
Maintainer(s), please drop the vulnerable version(s). Version: 2.3.11 Added to an existing GLSA Request.
This issue was resolved and addressed in GLSA 201611-02 at https://security.gentoo.org/glsa/201611-02 by GLSA coordinator Aaron Bauman (b-man).
