OpenVPN/IPsec - Sweet32: Birthday attacks

ummeegge ummeegge at ipfire.org
Mon Sep 5 10:30:11 CEST 2016


Hi,

Am 01.09.2016 um 21:29 schrieb R. W. Rodolico <rodo at dailydata.net>:

> Signierter PGP-Teil
> No matter which way you decide to go, we need to document as soon as
> possible. Is there any way we could modify release 104 to highlight
> insecure ciphers and insert a link to an article? I volunteer to write

the decision needs to made by the core developers, may also in conjunction with an update of the OpenSSL library to version 1.1 cause as you could read in the OpenSSL announcement, if the 'enable-weak-cipher" option won´t be set DES (and his variations) won´t work anymore ? But i´am not sure about that may there are other ways around.
I wanted only to point this specific problem out and as far as i can see the half of the OpenVPN ciphers are 64 bit block ciphers and are affected. Exception are Camellia, AES and the Seed ciphers.
Have also made some smaller changes in the OpenVPN wiki (it definitely needs some updates/fixes) and i will make some more in the next days and it would be great if you go also for some extensions (may we can meet in the wiki mailinglist for coordination).

> 
> the article.
> 
> What I'm thinking is, in 104 (I'm assuming dropping the insecure
> ciphers would not happen until 105), whey they view the OpenVPN
> screen, if they are using an insecure cipher, the text would show up
> in red or something. It seems a simple fix (but I've not looked at the
> code, so it may not be).

Since Core 104 is currently in testing tree, this could be a chance and as you mentioned it is a simple text formatting patch but as i wrote it before, the core developers needs to decide that.

> 
> 
> I disagree with "the sooner people throw old systems away" idea, as my
> basic philosophy is to use equipment until it won't boot. One of the
> advantages to FOSS. But, in this case, we're looking at the
> possibility of having to force outdated options in multiple packages
> which would be a fairly good sized effort.

There are configuration possibilities between "throw old systems away" or "disable this ciphers", but in would in anyways needs knowledge and activities from the user side in that case.

> 
> 
> Whatever happens, it needs to be documented, and I'd like to get it
> out there as soon as possible. And very visible even to users who
> don't read mailing lists or even visit the Planet.

I did some announcements also in the IPFire forum, may i should pin it to the top...

> 
> 
> I'm still not clear on one thing. If Blowfish (for example) is used in
> one of my connections and it was removed, I'm assuming that connection
> would no longer work. Correct? It sounds like we have the option of
> removing it from the list of available options, but also removing
> support completely from OpenVPN. Am I missing something.

This connection will work further even if Blowfish has been deleted from the WUIs cipher list it will further appear in the server.conf and it is furthermore present in the OpenSSL library but the problem will be to change things in the WUI or even to add more clients cause by pressing the next time 'save' the configuration will be changed (if no other cipher will be set to 'CAMELLIA-256-CBC' will be written to server.conf cause it is first in the list) and all other client configurations needs then to be adjusted accordingly.


> 
> 
> Rod
> 
> P.S. Sorry about the misunderstanding. Blowfish is fixed at 64. It is
> only the key length that is variable. My bad.

No problem good that we clear things like that.


> 
> 
> Rod
> 
> On 08/31/2016 06:01 AM, ummeegge wrote:
> > Hi all,
> >>
> >> 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.
> >
> > the systems would run further with these ciphers but it won´t be
> > possible to add new clients via WUI without changing the cipher and
> > regarding to OpenVPN this means to change all configurations cause
> > a OpenVPN instance have no variability with ciphers per client.
> >
> >>
> >> 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.
> >
> >
> > I think this is also a good idea but as far as i can see OpenSSL
> > for example will treat DES (triple-des) with version 1.1  like RC4
> > (haven´t seen a similar note with e.g. Blowfish ?) -->
> > https://www.openssl.org/blog/blog/2016/08/24/sweet32/ . So it won´t
> > be compiled by default but you need to activate
> > "enable-weak-ssl-ciphers in config options in the new OpenSSL
> > version. Whereby OpenSSLs new version might fill another discussion
> > round i think cause it seems pretty problematic without patching a
> > lot of other software which are linked against OpenSSL (e.g. failed
> > builds with OpenSSL-1.1 on Debian -->
> > https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/failed/ ),
> > there seems also to be some strange changes in the API but this
> > only as a beneath info…
> >
> >>
> >> 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.
> >
> >
> > I don´t think so, this problem addresses not the key lenght, it
> > means the fixed-lenght group of bits in the 'block' for these
> > ciphers e.g. --> https://en.wikipedia.org/wiki/Blowfish_(cipher)
> > under 'Cipher detail' .
> >
> >>
> >> 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.
> >
> > Yes, 2.4. brings some hope per default in that manner beneath some
> > other things (ECDH support, …) but who knows when they will release
> > it. Longer time ago i integrated the '--reneg-sec' directive into
> > the WUI for testing purposes which is pretty similar to
> > '--reneg-bytes' but i left it behind cause IPFire serves also the
> > "Additional configuration" possibility so a individual way to
> > adjust both configurations (client/server) is possible.
> >
> >>
> >> In this case, mainly Windows XP-systems are affected since 3DES
> >> was the only "safe" cipher suite they are able to use. Others
> >> (RC4, DES) went down the drain a long time ago.
> >>
> >> With Sweet32, it became impossible to use such a system for
> >> _any_ secure connection, no matter if its HTTPS, VPN or something
> >> else.
> >
> > Not sure about this cause a lot of software ships their own crypto
> > libs and do not use the system crypto, for example while the
> > OpenVPN development time for Core 79 we tested also Windows XP
> > systems positive with the Camellia cipher (AES too but also
> > SHA2-512 was ok) -->
> > http://forum.ipfire.org/viewtopic.php?f=17&t=10008&start=90#p69221
> > .
> >
> >> Back to the VPN: It seems like there is a similar problem here,
> >> because the (at least in Germany) very popular Fritz!Box by AVM
> >> cannot handle IPSec VPNs with AES ciphers (source:
> >> http://wiki.ipfire.org/en/configuration/services/ipsec/avm-fritzbox).
> >
> >>
> > Indeed, this is a problem and there are for sure more other
> > problematic constellations out there…
> >
> >> In my humble opinion, removing the 3DES cipher is better. First
> >> because it improves the transport security situation, although
> >> it cannot be easily exploited. Second, the more weak techniques
> >> and broken ciphers a legacy system supports are disabled on the
> >> majority of the servers, the sooner people throw the old systems
> >> away.
> >
> > I think this is not completely wide of the mark and it does remind
> > me a little on the RC4, MD5, SHA1 discussions. In fact this problem
> > is known since long time but anyways this ciphers are nowadays
> > nevertheless widely used…
> >
> > Another good overview causing this topic can be found also here -->
> > https://sweet32.info/SWEET32_CCS16.pdf .
> >
> > Some thoughts from here.
> >
> > Greetings,
> >
> > Erik
> >
> >
> >
> >
> 
> --
> Rod Rodolico
> Daily Data, Inc.
> POB 140465
> Dallas TX 75214-0465
> 214.827.2170
> http://www.dailydata.net
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipfire.org/pipermail/development/attachments/20160905/8fdfc4e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ipfire.org/pipermail/development/attachments/20160905/8fdfc4e9/attachment-0001.sig>


More information about the Development mailing list