From mboxrd@z Thu Jan 1 00:00:00 1970 From: IT Superhack To: development@lists.ipfire.org Subject: Re: OpenVPN/IPsec - Sweet32: Birthday attacks Date: Wed, 14 Sep 2016 19:04:00 +0000 Message-ID: <73fc341d-16ed-9a02-681c-94ad7bb3a588@web.de> In-Reply-To: <1473778820.2757.160.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5035009876606317456==" List-Id: --===============5035009876606317456== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, Michael Tremer: > Hey, >=20 > apologies for jumping in on this so late, but time is rare for me at the mo= ment. >=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 proba= bly > the majority of IPsec tunnels and OpenVPN connections would not work any mo= re > 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 ba= ck > 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 ap= plies to the AVM Fritz!Boxes, too). >=20 > That's not convincing to me, but in those businesses out there, they need > throughput and prioritize that over security. >=20 > Then there is the big lack of a migration path for OpenVPN. If you change t= he > cipher on the server side, no client would be able to connect any more unle= ss > 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. >=20 > Hence I am with Rod. People will only touch that if they have to and that is > very often when the hardware dies. >=20 > 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 thir= d of the security incidents the customers of my company encounter can be tracked d= own to this behavior.) >=20 > So could someone work on a patch to mark these as "weak". We had this discu= ssion > 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 > BF-CBC > ... >=20 > The tag can be used for that: > http://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 you 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 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 >=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. >> >> 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 >> >: >>> >>>> >>>> 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=20 >>> conjunction with an update of the OpenSSL library to version 1.1=20 >>> cause as you could read in the OpenSSL announcement, if the=20 >>> 'enable-weak-cipher" option won=C2=B4t be set DES (and his variations)=20 >>> won=C2=B4t work anymore ? But i=C2=B4am not sure about that may there are= =20 >>> 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=20 >>>> 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,=20 >>>> as my basic philosophy is to use equipment until it won't boot.=20 >>>> One of the advantages to FOSS. But, in this case, we're looking=20 >>>> at the possibility of having to force outdated options in=20 >>>> multiple packages which would be a fairly good sized effort. >>>> >>> >>> There are configuration possibilities between "throw old systems=20 >>> away" or "disable this ciphers", but in would in anyways needs=20 >>> knowledge and activities from the user side in that case. >>> >>>> >>>> >>>> Whatever happens, it needs to be documented, and I'd like to get=20 >>>> it out there as soon as possible. And very visible even to users=20 >>>> 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=20 >>>> used in one of my connections and it was removed, I'm assuming=20 >>>> that connection would no longer work. Correct? It sounds like we=20 >>>> have the option of removing it from the list of available=20 >>>> options, but also removing support completely from OpenVPN. Am I=20 >>>> 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=20 >>> '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.=20 >>>> 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=20 >>>>>> running these ciphers have to rebuild their certificates? Or=20 >>>>>> would their system continue to run as is, but new=20 >>>>>> configurations would only have the better options available. >>>>> >>>>> the systems would run further with these ciphers but it won=C2=B4t=20 >>>>> be possible to add new clients via WUI without changing the=20 >>>>> cipher and regarding to OpenVPN this means to change all=20 >>>>> configurations cause a OpenVPN instance have no variability=20 >>>>> 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,=20 >>>>>> especially if it can cause their system to not work after an=20 >>>>>> upgrade. I prefer to warn them, and let them make informed=20 >>>>>> decisions. >>>>> >>>>> >>>>> I think this is also a good idea but as far as i can see=20 >>>>> OpenSSL for example will treat DES (triple-des) with version=20 >>>>> 1.1 like RC4 (haven=C2=B4t seen a similar note with e.g. Blowfish=20 >>>>> ?) --> https://www.openssl.org/blog/blog/2016/08/24/sweet32/ .=20 >>>>> So it won=C2=B4t be compiled by default but you need to activate=20 >>>>> "enable-weak-ssl-ciphers in config options in the new OpenSSL=20 >>>>> version. Whereby OpenSSLs new version might fill another=20 >>>>> discussion round i think cause it seems pretty problematic=20 >>>>> without patching a lot of other software which are linked=20 >>>>> against OpenSSL (e.g. failed builds with OpenSSL-1.1 on Debian=20 >>>>> -->=20 >>>>> 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 >>>>> >>>>>> >>>>>> >>>>>> In my release 104, I see 128 bit as the lowest option. This=20 >>>>>> vulnerability specifically shows that for 64 bit blocks, the >>>>>> problem exists. To successfully attack a 64 bit block, you=20 >>>>>> would only need to generate 32 gig of traffic; definitely=20 >>>>>> reasonable. However, to successfully attack 128 bit blocks=20 >>>>>> 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=C2=B4t 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. -->=20 >>>>> https://en.wikipedia.org/wiki/Blowfish_(cipher) under 'Cipher=20 >>>>> detail' . >>>>> >>>>>> >>>>>> >>>>>> Finally, OpenVPN 2.4 (still very much in alpha) will support >>>>>> cipher negotiation, where the client and server will=20 >>>>>> dynamically negotiate which cipher to use. Within a short=20 >>>>>> time of its release, the problem will no longer exist since=20 >>>>>> 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=20 >>>>> some other things (ECDH support, =E2=80=A6) but who knows when they=20 >>>>> 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=20 >>>>>> 3DES was the only "safe" cipher suite they are able to use.=20 >>>>>> Others (RC4, DES) went down the drain a long time ago. >>>>>> >>>>>> With Sweet32, it became impossible to use such a system for=20 >>>>>> _any_ secure connection, no matter if its HTTPS, VPN or=20 >>>>>> something else. >>>>> >>>>> Not sure about this cause a lot of software ships their own=20 >>>>> 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) -->=20 >>>>> http://forum.ipfire.org/viewtopic.php?f=3D17&t=3D10008&start=3D90#p69221 >>>> >>>>> >>>>> >>>>> >>> . >>>> >>>>> >>>>> >>>>>> >>>>>> Back to the VPN: It seems like there is a similar problem=20 >>>>>> here, because the (at least in Germany) very popular=20 >>>>>> Fritz!Box by AVM cannot handle IPSec VPNs with AES ciphers=20 >>>>>> (source:=20 >>>>>> http://wiki.ipfire.org/en/configuration/services/ipsec/avm-fritzbox >> ). >>> >>>> >>>> >>>>> >>>>>> >>>>>> >>>>>> >>> >>>> >>>>> >>>>>> >>>>>> >>>>> Indeed, this is a problem and there are for sure more other=20 >>>>> problematic constellations out there=E2=80=A6 >>>>> >>>>>> >>>>>> In my humble opinion, removing the 3DES cipher is better.=20 >>>>>> First because it improves the transport security situation,=20 >>>>>> 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=20 >>>>> remind me a little on the RC4, MD5, SHA1 discussions. In fact=20 >>>>> this problem is known since long time but anyways this ciphers=20 >>>>> are nowadays nevertheless widely used=E2=80=A6 >>>>> >>>>> 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 >>>> >>>> >>> --===============5035009876606317456== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRRWNCQUVCQ2dBR0JRSlgyWjlpQUFvSkVP eUxhMUM1RWF6cnovY0gvaUYzK3NJYlMyekJiL3NrOE9mZUp0dFoKSVpjbmRkb2xjbFZzQXpiZE1Z Y3I3RkFFSCtsbEs0R0VuYU85OHhtZXFxalhLa3BlWnV5cytrVWhXdXEzb1QwcgpzaTBWMFZDL2Zt MWVZdXZHRFdrL2ovK0V3bW9WM0Fzci83dTRlVVoxUzVyTUZhL00zU0JEOUJ0MlhCL0JURURWCmRD TkVsTllUaFdqZU5XS1AvWjZoODQzSS9PazVlWk1yWXF2eXZLRTVqTld0dVFMQUE2QlY4blVpZGU3 Q1lmNXEKNG9LTE9DNXN3Qnl0bjZRYm1GbkFWZktNc0xMUkovUzNDaTVXUWZQc2FzV3VDem5uZWho Wno4b0JYUXhDOVBISgpuTGphaHBnVDZEM0IvSXMzTjVjSW9nWk81aytNVXo5QUNFVXUzcndFMEVH SGlUNTJwYjQxQStnUy9DL3A1Nms9Cj1rTXhPCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============5035009876606317456==--