-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
You say "disable in the list." Would systems currently running these ciphers have to rebuild their certificates? Or would their system continue to run as is, but new configurations would only have the better options available.
If it would break any existing systems, I would prefer to not disable it. If there was a way to change the tags in OpenVPN to add a DANGER to the label, that would be sufficent. Maybe even a link between Encyption: and the dropdown pointing to the articles describing the issu e.
I never like to disallow someone from doing something, especially if it can cause their system to not work after an upgrade. I prefer to warn them, and let them make informed decisions.
In my release 104, I see 128 bit as the lowest option. This vulnerability specifically shows that for 64 bit blocks, the problem exists. To successfully attack a 64 bit block, you would only need to generate 32 gig of traffic; definitely reasonable. However, to successfully attack 128 bit blocks requires reading 256 Exobytes, which is unreasonable to worry about at this time. I'm assuming I'm reading this correctly and BF-CBS (128 bit) actually means it is using 128 bit blocks.
Also, there are other work-arounds as umeege mentioned, documented at https://community.openvpn.net/openvpn/wiki/SWEET32 which can secure even the smaller block sizes such as increasing renegotiation frequency.
Finally, OpenVPN 2.4 (still very much in alpha) will support cipher negotiation, where the client and server will dynamically negotiate which cipher to use. Within a short time of its release, the problem will no longer exist since both servers and clients will be able to do behind the scenes negotiation.
So, as I said, I would prefer not to disable them outright. Making modifications that will disable functionality of IPFire on upgrade would cause a reputation hit if many people were affected by it.
Rod
On 08/29/2016 10:50 AM, ummeegge wrote:
Hi all, i wanted to report a cross-site scripting vulnerability problem for OpenVPN and possibly also IPSec via the "SWEET32: Birthday attacks on 64-bit block ciphers which concerns the DES cipher incl. the 3DES variants but also the Blowfish cipher. The only way to fix it which i have currently recognized is to use other ciphers then those and another way for a faster implementation for OpenVPN is to renegotiate new keys more often. An example can be to use '--reneg-bytes 64000' in the configuration.
So my question is should we delete those ciphers from the OpenVPN/IPsec cipher lists and announce this problem to the community may via the Planet (have announced it already in the IPFire forum for OpenVPN) ?
Some deeper insides causing this problem can be found in here:
https://community.openvpn.net/openvpn/wiki/SWEET32
Greetings,
Erik
- -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 214.827.2170 http://www.dailydata.net