From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: OpenVPN/IPsec - Sweet32: Birthday attacks Date: Thu, 15 Sep 2016 12:13:31 +0100 Message-ID: <1473938011.2757.196.camel@ipfire.org> In-Reply-To: <79F11CDE-1805-4EE3-8CF2-44A37BA39AE4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2552830748650192942==" List-Id: --===============2552830748650192942== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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: =C2=A0=C2=A0http://lists.ipfire.org/pipermail/development/2015-December/00123= 6.html What if something suddenly becomes "weak"? But generally I think this is better than what we have now. > Ciphers: >=20 > Strong algorithms >=20 > With=C2=A0256 bit (keylenght) <--> 128 Bit block ciphers > With 192 bit (keylenght) <-->=C2=A0 " >=20 > Medium algorithms >=20 > With=C2=A0128 bit (keylenght) <--> 128 bit block ciphers >=20 > Weak algorithms > =09 > With 192 bit (keylenght) <--> 64 bit block ciphers > With 128 bit (keylenght) <--> 64 bit block ciphers >=20 >=20 > HMACs: >=20 > Strong algorithms >=20 > 512 bit Whirlpool, SHA2 > 384 bit SHA2 >=20 > Medium algorithms >=20 > 256 bit SHA2 >=20 > Weak algorithms >=20 > 160 bit SHA1 and md5 >=20 >=20 > Diffie-Hellman parameter: >=20 > Strong algorithms >=20 > 4096, 3072 >=20 > Medium algorithms >=20 > 2048 >=20 > Weak algorithm >=20 > 1024 >=20 > 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=C2=B4ve ad= ded the > the selection of the auth algorithm, a lot of configurations have used alre= ady > '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=C2=B4t 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 entr= opy > a lot of time so an security/usability question comes up again. >=20 > 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/serv= er) > and may too much/complicated to configure over the WUI, even if 2.4.x deliv= ers > it per default ? Can we assume that we have a reasonably recent version on the clients? >=20 > Some ideas from here. >=20 > Greetings, >=20 > Erik >=20 >=20 >=20 > Am 14.09.2016 um 21:04 schrieb IT Superhack : >=20 > > Hello Michael, > >=20 > > Michael Tremer: > > > Hey, > > >=20 > > > apologies for jumping in on this so late, but time is rare for me at the > > > moment. > > >=20 > > > 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? > > >=20 > > > 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. :-( > > >=20 > > > 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). > > >=20 > > > That's not convincing to me, but in those businesses out there, they ne= ed > > > throughput and prioritize that over security. > > >=20 > > > Then there is the big lack of a migration path for OpenVPN. If you chan= ge > > > 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 d= oes > > > there > > > would be a good chance. Unfortunately it does not and is not even very > > > user- > > > friendly when you have a configuration mismatch. > > >=20 > > > Hence I am with Rod. People will only touch that if they have to and th= at > > > is > > > very often when the hardware dies. > > >=20 > > > So I think there is no chance that we just remove all the "broken" ciph= ers > > > 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 track= ed > > down > > to this behavior.) > > >=20 > > > 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. > > >=20 > > > We could just modify the dropdown on the OpenVPN page like this: > > >=20 > > > CAMELLIA-CBC (256 bit) > > > CAMELLIA-CBC (192 bit) > > > ... > > > Weak Ciphers > > > =C2=A0BF-CBC > > > =C2=A0... > > >=20 > > > The tag can be used for that: > > > =C2=A0http://www.w3schools.com/tags/tag_optgroup.asp > > >=20 > > > 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 y= ou > > don't touch the VPN configuration sites if everything works. > > >=20 > > > The IPsec dropdown can be modified in just the same way. > > Yep. > > >=20 > > > So we will keep supporting those ciphers, but we make it crystal clear > > > that it > > > is not recommended to use them. > > >=20 > > > Would that be okay with you? Did I get everything discussed here baked > > > into the > > > proposed solution? > > I'm happy with this. > > >=20 > > > 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 > >=20 > > I am not sure about the "Grouptype" options in IPSec, since I would disab= le > > anything weaker than 2048 Bits (RSA/MODP) or 256 Bits (ECDSA/ECP). > >=20 > > 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. > >=20 > > 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). > >=20 > > Best regards, > > Timmothy Wilson > > >=20 > > > Best, > > > -Michael > > >=20 > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > Rod > > > >=20 > > > > On 09/05/2016 03:30 AM, ummeegge wrote: > > > > >=20 > > > > > Hi, > > > > >=20 > > > > > Am 01.09.2016 um 21:29 schrieb R. W. Rodolico > > > > >: > > > > >=20 > > > > > >=20 > > > > > > 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 > > > > > >=20 > > > > > the decision needs to made by the core developers, may also in=C2=A0 > > > > > conjunction with an update of the OpenSSL library to version 1.1=C2= =A0 > > > > > cause as you could read in the OpenSSL announcement, if the=C2=A0 > > > > > 'enable-weak-cipher" option won=C2=B4t be set DES (and his variatio= ns)=C2=A0 > > > > > won=C2=B4t work anymore ? But i=C2=B4am not sure about that may the= re are=C2=A0 > > > > > 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). > > > > >=20 > > > > > >=20 > > > > > > the article. > > > > > >=20 > > > > > > 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= =C2=A0 > > > > > > looked at the code, so it may not be). > > > > > >=20 > > > > > 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. > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > I disagree with "the sooner people throw old systems away" idea,= =C2=A0 > > > > > > as my basic philosophy is to use equipment until it won't boot.= =C2=A0 > > > > > > One of the advantages to FOSS. But, in this case, we're looking= =C2=A0 > > > > > > at the possibility of having to force outdated options in=C2=A0 > > > > > > multiple packages which would be a fairly good sized effort. > > > > > >=20 > > > > > There are configuration possibilities between "throw old systems=C2= =A0 > > > > > away" or "disable this ciphers", but in would in anyways needs=C2=A0 > > > > > knowledge and activities from the user side in that case. > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Whatever happens, it needs to be documented, and I'd like to get= =C2=A0 > > > > > > it out there as soon as possible. And very visible even to users= =C2=A0 > > > > > > who don't read mailing lists or even visit the Planet. > > > > > >=20 > > > > > I did some announcements also in the IPFire forum, may i should > > > > > pin it to the top... > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > I'm still not clear on one thing. If Blowfish (for example) is=C2= =A0 > > > > > > used in one of my connections and it was removed, I'm assuming=C2= =A0 > > > > > > that connection would no longer work. Correct? It sounds like we= =C2=A0 > > > > > > have the option of removing it from the list of available=C2=A0 > > > > > > options, but also removing support completely from OpenVPN. Am I= =C2=A0 > > > > > > missing something. > > > > > >=20 > > > > > 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=C2= =A0 > > > > > '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. > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Rod > > > > > >=20 > > > > > > P.S. Sorry about the misunderstanding. Blowfish is fixed at 64.= =C2=A0 > > > > > > It is only the key length that is variable. My bad. > > > > > >=20 > > > > > No problem good that we clear things like that. > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Rod > > > > > >=20 > > > > > > On 08/31/2016 06:01 AM, ummeegge wrote: > > > > > > >=20 > > > > > > > Hi all, > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > You say "disable in the list." Would systems currently=C2=A0 > > > > > > > > running these ciphers have to rebuild their certificates? Or= =C2=A0 > > > > > > > > would their system continue to run as is, but new=C2=A0 > > > > > > > > configurations would only have the better options available. > > > > > > > the systems would run further with these ciphers but it won=C2= =B4t=C2=A0 > > > > > > > be possible to add new clients via WUI without changing the=C2= =A0 > > > > > > > cipher and regarding to OpenVPN this means to change all=C2=A0 > > > > > > > configurations cause a OpenVPN instance have no variability=C2= =A0 > > > > > > > with ciphers per client. > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > 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. > > > > > > > >=20 > > > > > > > > I never like to disallow someone from doing something,=C2=A0 > > > > > > > > especially if it can cause their system to not work after an= =C2=A0 > > > > > > > > upgrade. I prefer to warn them, and let them make informed=C2= =A0 > > > > > > > > decisions. > > > > > > >=20 > > > > > > > I think this is also a good idea but as far as i can see=C2=A0 > > > > > > > OpenSSL for example will treat DES (triple-des) with version=C2= =A0 > > > > > > > 1.1 =C2=A0like RC4 (haven=C2=B4t seen a similar note with e.g. = Blowfish=C2=A0 > > > > > > > ?) --> https://www.openssl.org/blog/blog/2016/08/24/sweet32/ .= =C2=A0 > > > > > > > So it won=C2=B4t be compiled by default but you need to activat= e=C2=A0 > > > > > > > "enable-weak-ssl-ciphers in config options in the new OpenSSL= =C2=A0 > > > > > > > version. Whereby OpenSSLs new version might fill another=C2=A0 > > > > > > > discussion round i think cause it seems pretty problematic=C2=A0 > > > > > > > without patching a lot of other software which are linked=C2=A0 > > > > > > > against OpenSSL (e.g. failed builds with OpenSSL-1.1 on Debian= =C2=A0 > > > > > > > -->=C2=A0 > > > > > > > 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=E2=80=A6 > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > In my release 104, I see 128 bit as the lowest option. This= =C2=A0 > > > > > > > > vulnerability specifically shows that for 64 bit blocks, the > > > > > > > > problem exists. To successfully attack a 64 bit block, you=C2= =A0 > > > > > > > > would only need to generate 32 gig of traffic; definitely=C2= =A0 > > > > > > > > reasonable. However, to successfully attack 128 bit blocks=C2= =A0 > > > > > > > > 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. > > > > > > >=20 > > > > > > > I don=C2=B4t think so, this problem addresses not the key lengh= t, it > > > > > > > means the fixed-lenght group of bits in the 'block' for these > > > > > > > ciphers e.g. -->=C2=A0 > > > > > > > https://en.wikipedia.org/wiki/Blowfish_(cipher) under 'Cipher= =C2=A0 > > > > > > > detail' . > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Finally, OpenVPN 2.4 (still very much in alpha) will support > > > > > > > > cipher negotiation, where the client and server will=C2=A0 > > > > > > > > dynamically negotiate which cipher to use. Within a short=C2= =A0 > > > > > > > > time of its release, the problem will no longer exist since= =C2=A0 > > > > > > > > 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= =C2=A0 > > > > > > > some other things (ECDH support, =E2=80=A6) but who knows when = they=C2=A0 > > > > > > > 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. > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > In this case, mainly Windows XP-systems are affected since=C2= =A0 > > > > > > > > 3DES was the only "safe" cipher suite they are able to use.= =C2=A0 > > > > > > > > Others (RC4, DES) went down the drain a long time ago. > > > > > > > >=20 > > > > > > > > With Sweet32, it became impossible to use such a system for= =C2=A0 > > > > > > > > _any_ secure connection, no matter if its HTTPS, VPN or=C2=A0 > > > > > > > > something else. > > > > > > > Not sure about this cause a lot of software ships their own=C2= =A0 > > > > > > > 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) -->=C2=A0 > > > > > > > http://forum.ipfire.org/viewtopic.php?f=3D17&t=3D10008&start=3D= 90#p69221 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > . > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Back to the VPN: It seems like there is a similar problem=C2= =A0 > > > > > > > > here, because the (at least in Germany) very popular=C2=A0 > > > > > > > > Fritz!Box by AVM cannot handle IPSec VPNs with AES ciphers=C2= =A0 > > > > > > > > (source:=C2=A0 > > > > > > > > http://wiki.ipfire.org/en/configuration/services/ipsec/avm-fr= itz > > > > > > > > box > > > > ). > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > Indeed, this is a problem and there are for sure more other=C2= =A0 > > > > > > > problematic constellations out there=E2=80=A6 > > > > > > >=20 > > > > > > > >=20 > > > > > > > > In my humble opinion, removing the 3DES cipher is better.=C2= =A0 > > > > > > > > First because it improves the transport security situation,= =C2=A0 > > > > > > > > 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=C2= =A0 > > > > > > > remind me a little on the RC4, MD5, SHA1 discussions. In fact= =C2=A0 > > > > > > > this problem is known since long time but anyways this ciphers= =C2=A0 > > > > > > > are nowadays nevertheless widely used=E2=80=A6 > > > > > > >=20 > > > > > > > Another good overview causing this topic can be found also > > > > > > > here --> https://sweet32.info/SWEET32_CCS16.pdf . > > > > > > >=20 > > > > > > > Some thoughts from here. > > > > > > >=20 > > > > > > > Greetings, > > > > > > >=20 > > > > > > > Erik > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > -- Rod Rodolico Daily Data, Inc. POB 140465 Dallas TX 75214-0465 > > > > > > 214.827.2170 http://www.dailydata.net > > > > > >=20 > > > > > >=20 > >=20 >=20 --===============2552830748650192942== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlgyb0piQUFvSkVJQjU4UDl2a0FrSHhuNFAvMkpkNjVJc1RScnZWeWkvZDhOSnYrL2kK MURuZTIwU25uM0huTlNTZjlTb0ttZUp6a1liMmIzZ09GdC9FM2xySXFMbU9nV3UxWUhHZTVpRmdz cFpEeWdnVQp6STgySlYzQkh0SEV3WFBKMWVKeC9KeWlJWmh4K1JxdHhnUDBoaTAwd01rTEEvNGVP VzdMVktTbGZBRjBmTDVGCngvb2xaNm9rMnJ0VThGcExUZ2NxTFBzMjZ4WGVNOEpPRFp4dFNMb0ZW NThBNlp1RVVmZFhQakx6a2Y3cDhML0YKMUFoeHZxMHVCYzliTXgvWmx1ZWhxQkVSTldteXQ2N1BF OHBTV2FING1COHJhTUd6V0NxMHpRdDIxVjNFSFd0bgp0VmRabGpIdXlIVE9PZEMrcjFvR1MxS29I Q1ZNTUwwdFphcXRPSHNlMGo4S25kTlJPUkJuSHhsdnRDUGlTZzFDCnQzWDE1bHQ2T2daT3NuTnZu OWo5aEoyRmxjTGVGYWFMY25FNURNdkZsYUJGN004ZnVHbjBvUHZTZVltT1owaDUKTDJVbk9pNUZj bVFLY0tXMlY2aGR4cTRqSTNxNnhXT3c4TzV2d0pVQkR5ekh4ZkNwdGJPbmNKNlpndmk3dlJZQwo4 VFQ2QlQ3b3E5YXFtMlFETlpJaXBoU25pdUlKaXVhVFlFc01OSFhuRTN2MEJpdkVuRFFOR2M3ZVNN L1FVdUlUCmxEa2E0RTM4YytTeEQzQURORkd2OXBuM1BydlJQQmw0VFJyUjRTM2VFRlBwTDJialUr d2V2OXRRNUFTYWRvbmQKbnI4ZTFmOGhlTWorR3F3ZkJmRWVHcE1SaTJmZWQwTkpZQ2VpOWxnbGR2 ZHF3K2MxbFcrNWxVNmM3YmxPNDdxLwpoM0dDakd5VVlhc1Avcm1DbzBVRQo9cFV4WQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============2552830748650192942==--