Re: OpenVPN/IPsec - Sweet32: Birthday attacks

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 20989 bytes --]

Hi,

On Thu, 2016-09-15 at 12:23 +0200, ummeegge wrote:
> Hi all,
> what are you thinking then to arrange the optgroup (thanks Michael for
> pointing this formatting possibility out) with the following assignments and
> in e.g. 3 different sections named for example

We had a similar discussion over here if it was a good idea to mark something as
"strong" over here:

  http://lists.ipfire.org/pipermail/development/2015-December/001236.html

What if something suddenly becomes "weak"?

But generally I think this is better than what we have now.

> Ciphers:
> 
> Strong algorithms
> 
> 	With 256 bit (keylenght) <--> 128 Bit block ciphers
> 	With 192 bit (keylenght) <--> 		"
> 
> Medium algorithms
> 
> 	With 128 bit (keylenght) <--> 128 bit block ciphers
> 
> Weak algorithms
> 	
> 	With 192 bit (keylenght) <--> 64 bit block ciphers
> 	With 128 bit (keylenght) <--> 64 bit block ciphers
> 
> 
> HMACs:
> 
> Strong algorithms
> 
> 	512 bit Whirlpool, SHA2
> 	384 bit SHA2
> 
> Medium algorithms
> 
> 	256 bit SHA2
> 
> Weak algorithms
> 
> 	160 bit SHA1 and md5
> 
> 
> Diffie-Hellman parameter:
> 
> Strong algorithms
> 
> 	4096, 3072
> 
> Medium algorithms
> 
> 	2048
> 
> Weak algorithm
> 
> 	1024
> 
> May too much but as an first idea for the naming and structure of the
> optgroups in OpenVPN.

Let's start with that one then and do IPsec later.

> Causing the defaults for the HMAC:
> SHA1 is really no good choice in OpenVPN but in the time when we´ve added the
> the selection of the auth algorithm, a lot of configurations have used already
> 'auth SHA1' in their configs so the problems comes up if the server
> configuration will be stored again via the WUI or new clients are generated
> with new parameters all existing clients with the old defaults (SHA1 in that
> case) won´t work anymore until they have been changed appropriately.

Changing the default to SHA256 has some implications that may cause major
difficulties later. See my other email for this.

> The Diffie-Hellman parameter needs, on weak boards or boards with less entropy
> a lot of time so an security/usability question comes up again.
> 
> OpenVPN delivers also the possibility for 'reneg-sec' or 'reneg-bytes' but
> this needs to be configured as far as i remember on both sides (client/server)
> and may too much/complicated to configure over the WUI, even if 2.4.x delivers
> it per default ?

Can we assume that we have a reasonably recent version on the clients?

> 
> Some ideas from here.
> 
> Greetings,
> 
> Erik
> 
> 
> 
> Am 14.09.2016 um 21:04 schrieb IT Superhack <itsuperhack(a)web.de>:
> 
> > Hello Michael,
> > 
> > Michael Tremer:
> > > Hey,
> > > 
> > > apologies for jumping in on this so late, but time is rare for me at the
> > > moment.
> > > 
> > > I agree that we need to do something here, but with crypto we always end
> > > up with
> > > the same problem. That is: How do we offer a good migration path?
> > > 
> > > Some ciphers we support are clearly broken. If we would disable those
> > > probably
> > > the majority of IPsec tunnels and OpenVPN connections would not work any
> > > more
> > > since lots of hardware that you buy today still only does RC4, (3)DES,
> > > SHA1 or
> > > MD5. That's terrible.
> > Indeed, it is. :-(
> > > 
> > > If we would kick out all of those, we would have people ask to get these
> > > back
> > > in. They have some reasons to use those. AFAIK does lots of Cisco stuff
> > > implement 3DES in hardware which is therefore much faster than AES.
> > Yes, some earlier versions of the Cisco ASA series don't even support AES,
> > and
> > in some cases, there is a bug preventing a successful VPN connection (that
> > applies
> > to the AVM Fritz!Boxes, too).
> > > 
> > > That's not convincing to me, but in those businesses out there, they need
> > > throughput and prioritize that over security.
> > > 
> > > Then there is the big lack of a migration path for OpenVPN. If you change
> > > the
> > > cipher on the server side, no client would be able to connect any more
> > > unless
> > > you update the configuration. Completely unfeasible to do with probably
> > > more
> > > than 5 connections. If OpenVPN would negotiate the ciphers like IPsec does
> > > there
> > > would be a good chance. Unfortunately it does not and is not even very
> > > user-
> > > friendly when you have a configuration mismatch.
> > > 
> > > Hence I am with Rod. People will only touch that if they have to and that
> > > is
> > > very often when the hardware dies.
> > > 
> > > So I think there is no chance that we just remove all the "broken" ciphers
> > > here.
> > > That will break too many systems. People would probably avoid updating
> > > then and
> > > get new security issues in other components.
> > I agree with this and it's a very common behavior. (In fact, more than a
> > third of
> > the security incidents the customers of my company encounter can be tracked
> > down
> > to this behavior.)
> > > 
> > > So could someone work on a patch to mark these as "weak". We had this
> > > discussion
> > > earlier on this list but a final solution was never implemented.
> > > 
> > > We could just modify the dropdown on the OpenVPN page like this:
> > > 
> > > CAMELLIA-CBC (256 bit)
> > > CAMELLIA-CBC (192 bit)
> > > ...
> > > Weak Ciphers
> > >  BF-CBC
> > >  ...
> > > 
> > > The <optgroup> tag can be used for that:
> > >  http://www.w3schools.com/tags/tag_optgroup.asp
> > > 
> > > Additionally we can show a flag next to it if a weak cipher is in use.
> > That's a good idea. Maybe we can also display a notification on the main
> > page
> > (similar to the "there is a new update available" notice) since usually you
> > don't touch the VPN configuration sites if everything works.
> > > 
> > > The IPsec dropdown can be modified in just the same way.
> > Yep.
> > > 
> > > So we will keep supporting those ciphers, but we make it crystal clear
> > > that it
> > > is not recommended to use them.
> > > 
> > > Would that be okay with you? Did I get everything discussed here baked
> > > into the
> > > proposed solution?
> > I'm happy with this.
> > > 
> > > Are we proposing any insecure defaults? We should adjust these then.
> > Yes:
> > OpenVPN (advanced server options): SHA1 is set as default
> > IPSec (advanced connection options): SHA1 is enabled by default
> > 
> > I am not sure about the "Grouptype" options in IPSec, since I would disable
> > anything weaker than 2048 Bits (RSA/MODP) or 256 Bits (ECDSA/ECP).
> > 
> > Neither am I sure about the "Diffie-Hellman parameters". 1024 Bits - which
> > is set as default currently, is awfully short; 2048 is the minimum
> > recommended
> > length. Needless to say, this may take ages on slow hardware, so I'm not
> > sure how to deal with this.
> > 
> > Similar problems occur within Apache:
> > * Logjam/Weak DH params, which cannot be fixed easily at the moment
> > * current configuration supports SHA1. But if we'd disable that, clients
> > must
> > use TLS 1.2 which is better, but not always possible (IE6-8 on
> > WinXP/Vista/7).
> > 
> > Best regards,
> > Timmothy Wilson
> > > 
> > > Best,
> > > -Michael
> > > 
> > > On Sat, 2016-09-10 at 01:49 -0500, R. W. Rodolico wrote:
> > > > From what I understand, existing configurations will stay the same and
> > > > still be able to connect. The only effect this will have is to keep
> > > > people from creating new certs with the insecure ciphers. In that
> > > > case, I think they could be killed with no problem.
> > > > 
> > > > If you decide to do this, all we need to do is document it so we don't
> > > > get people asking "where is blowfish; I always use that!" Putting it
> > > > in the forum is cool, but I want to put it in the documentation
> > > > (wiki.ipfire.org), mainly in
> > > > http://wiki.ipfire.org/en/configuration/services/openvpn. Again, I'm
> > > > not coding, so I am happy to document.
> > > > 
> > > > I was concerned you were talking about pulling the ciphers completely
> > > > out of OpenVPN, so the server would not be able to respond when an old
> > > > connection was made using one of the insecure ciphers. Pulling it from
> > > > the list of available ciphers for new connections should not be an
> > > > issue at all.
> > > > 
> > > > Happy to help whatever you need with the wiki. I'm on the
> > > > documentation(a)lists.ipfire.org list. Is that the one you're talking
> > > > about? I use OpenVPN quite a bit, so just let me know what you want me
> > > > to do.
> > > > 
> > > > Rod
> > > > 
> > > > On 09/05/2016 03:30 AM, ummeegge wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > Am 01.09.2016 um 21:29 schrieb R. W. Rodolico <rodo(a)dailydata.net 
> > > > > <mailto:rodo(a)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-fritz
> > > > > > > > box
> > > > ).
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 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
> > > > > > 
> > > > > > 
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]