Summary: | <net-misc/openvpn-2.3.12: Birthday attack against 64 bit block ciphers including Blowfish (BF-CBC) used by default (SWEET32) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | jer, mrueg |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sweet32.info | ||
See Also: | https://bugzilla.redhat.com/show_bug.cgi?id=1369386 | ||
Whiteboard: | B3 [glsa cve] | ||
Package list: | Runtime testing required: | --- |
Description
Agostino Sarubbo
2016-08-25 09:16:19 UTC
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). |