From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] vpnmain.cgi: Mark MODP-1536 as broken, phase out MODP-2048 Date: Thu, 11 Aug 2022 17:06:11 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3553529484944303858==" List-Id: --===============3553529484944303858== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Peter, > On 11 Aug 2022, at 13:51, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, >=20 > apologies for my late reply. >=20 >> Hello, >>=20 >>> On 6 Aug 2022, at 15:13, Peter M=C3=BCller w= rote: >>>=20 >>> Hello Michael, >>>=20 >>> thanks for your quick reply. >>>=20 >>>> Hello Peter, >>>>=20 >>>>> On 6 Aug 2022, at 08:17, Peter M=C3=BCller = wrote: >>>>>=20 >>>>> https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf (released in >>>>> 2015) recommends "to use primes of 2048 bits or larger", to which BSI's >>>>> techical guideline BSI-TR-02102 (https://www.bsi.bund.de/SharedDocs/Dow= nloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__= blob=3DpublicationFile&v=3D5) >>>>> concurs. The latter also recommends not to use DH groups comprising of >>>>> less than 2000 bits after 2022, and shift to 3000 bit DH groups earlier >>>>> as a precaution. >>>>>=20 >>>>> According to RFC 3526, section 8, MODP-1536 provides an estimated >>>>> security between 90 and 120 bits, a value that can be reasonably >>>>> considered broken today, as it has been so for other types of >>>>> cryptographic algorithms already, and per section 2.4 in the >>>>> aforementioned paper, breaking 1024-bit DH is considered feasible for >>>>> the NSA in 2015, which does not inspire confidence for MODP-1536 in >>>>> 2022. >>>>=20 >>>> I generally agree with that statement. >>>>=20 >>>> In my personal opinion, I believe that we should not be using any of the= MODP options any more. Not because they are inherently broken, but we would = need longer key lengths which are incredibly hard to generate for >=3D4096 bi= ts - depending on your hardware. Very often, IPFire is not talking to another= IPFire instance, and that is where it gets really interesting. >>>>=20 >>>> However, having said that there are lots of bad devices out there, plent= y don=E2=80=99t support any ECC - not even speaking of Curve25519. They have = no HWRNGs and slow CPUs which are unable to even produce a 2048 bit prime - b= ut many of them barely manage. >>>>=20 >>>> The reason why MODP-2048 is enabled is, because it makes IPFire more com= patible with other devices out there. The intention is that a tunnel comes up= without the user visiting the =E2=80=9CAdvanced Settings=E2=80=9D. We do not= show any indication in the web UI at all if there is a cipher mismatch. So h= ow else is the user supposed to find out? >>>=20 >>> As so often, I agree with your intention, but not with the outcome of it.= :-) >>>=20 >>> True, if a tunnel cannot be established for whatever reason, the web inte= rfaces >>> leaves the user with a non-green colour indicator of the respective IPsec= connection. >>>=20 >>> However, I would argue that since debugging already requires shell access= and >>> IPsec/strongSwan internals knowledge today, adding another reason to the = list >>> of cases where user need to SSH into their IPFire is not breaking princip= les. >>=20 >> I do not think that it is generally okay for standard functionality to sen= d people to the shell. That defeats the entire purpose of why IPFire exists. >=20 > ACK, but for IPsec, we do not really have a robust approach for avoiding th= is. Not yet :) >=20 >>> Another argument I would back my proposal by is the "secure defaults" one. >>=20 >> I agree with that - and it would be great if we could put security to the = top of the list of priorities and that is it then. >>=20 >> However, what is it good for if IPFire practically becomes =E2=80=9Cincomp= atible=E2=80=9D with an =E2=80=9Cindustry standard=E2=80=9D? >>=20 >>> People trust IPFire to do reasonably the right thing without having to lo= ok at >>> every single detail. IPsec users having sufficiently up-to-date peers tod= ay >>> (hence not relying on MODP-2048) are probably not comfortable with the id= ea >>> that the default selection features a DH group a nation-state threat acto= r can >>> likely break in the foreseeable future. >>>=20 >>> I think users should implicitly acknowledge their level of insecurity by = ticking >>> weak algorithms explicitly, should they need them for new IPsec connectio= ns. >>=20 >> But what should be the default then? >>=20 >> MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selecti= on to me. >=20 > Since we made this choice based on facts, I do not see why it is random (th= ough > I agree it might look so to the layman). Because it suggests that the options that we did not select are not good when= they are not being considered weak either. Are there =E2=80=9Cstrong=E2=80= =9D and =E2=80=9Cstronger=E2=80=9D options? That isn=E2=80=99t obvious to a u= ser. >=20 >>=20 >>>=20 >>>>=20 >>>>> Therefore, this patch suggests to mark MODP-1536 as broken, since it >>>>> de facto is, and tag MODP-2048 as weak. The latter is also removed from >>>>> the default selection, so newly created VPN connections won't use it >>>>> anymore, to follow BSI's recommendations of using DH groups >=3D 3000 b= its >>>>> in 2022 and later. >>>>=20 >>>> I agree with the recommendation, although MODP-3072 is probably a bit po= intless. It feels too odd to me, and I am sure that devices that support anyt= hing better than 2048 would support 4096 as well. >>>=20 >>> True, but in case the remote peer in question does not support anything a= side >>> DH, I thought going for 3k instead of 4k DH group still leaves us with _s= ome_ >>> performance benefit. :-) >>>=20 >>>> I agree with 2048 being marked as weak, but I do not agree with taking i= t out of the default list. It shouldn=E2=80=99t be on there, but we would mak= e the setup process a lot more complicated for users. >>>=20 >>> I would have agreed with your concern a couple of years ago, when MODP-20= 48 >>> was still looking fine. However, sine this patch won't affect any IPsec c= onnection >>> already configured (and such configurations tend to last for long times), >>> still including MODP-2048 in the defaults does not seem to be a reasonable >>> decision. The BSI probably has good reasons why they recommend against it= for >>> anything that lasts beyond 2022, and ideally shifting away from MODP-2048= sooner. >>=20 >> Obviously we cannot touch any existing connections. >=20 > Full ACK. >=20 >>=20 >> I know of enough users still being on 3DES, MD5, SHA1 and what not. Arguab= ly this is all wasted CPU times, but sadly that is the reality out there. Peo= ple have to connect to business partners or other peers that are running on v= ery outdated hardware and have nobody who understands what they are doing the= re or who would care to change anything about that. >>=20 >> Well, if the BSI has any reasons, it is sad that those are not transparent= . A random decision that is just being announced without being explained is n= ot going to convince those people running all that outdated shit that they ne= ed to act now. >>=20 >>> What do you think about adding a note to the correspondent wiki page to s= tress >>> this change, should it land in IPFire? That way, we at least don't let us= ers >>> standing completely in the rain, with no idea where to look. >>=20 >> I generally like the idea that we explain more about our decisions. I supp= ose sometimes they appear random and coming out of the blue for users. >>=20 >> But I am also very much aware that people don=E2=80=99t read those things.= Doesn=E2=80=99t necessarily mean that they shouldn=E2=80=99t be there. >>=20 >>> Also, it would read kind of ugly if our default selection includes a DH g= roup >>> that is explicitly tagged as "weak". :-) >>=20 >> Yes, I wouldn=E2=80=99t like that look either. This is however the only wa= y to achieve some compatibility. >>=20 >> Looking at the competition we have things like this: >>=20 >> Cisco ASA-5500: https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/c= onfiguration/guide/conf_gd/ike.html >>=20 >> Defaults are: 3DES, SHA1, MODP-1024 >=20 > Okay, our defaults are incompatible to that anyway. Well great. That makes things very easy then. We can simply go ahead with thi= s patch as it is then. Acked-by: Michael Tremer But I would like to add at least ECP-384 as well then. I do not see that we d= o not offer that when it is pretty much the next best option after RSA. >> =E2=80=9CNext Generation=E2=80=9D Ecryption is as follows (https://tools.c= isco.com/security/center/resources/next_generation_cryptography): >=20 > Unfortunately, this page won't load here, no matter what I try. Had to go b= ack to the archive... :-/ >=20 >> 3DES/SHA1/HMAC-MD5 are considered =E2=80=9Clegacy=E2=80=9D. >>=20 >> DES (no I did not miss the 3)/MODP<=3D1024/MD5 are considered to be avoide= d (I consider this wording as 3DES is okay, but maybe shouldn=E2=80=99t be us= ed for new setups any more). >>=20 >> That leaves us with the minimum =E2=80=9Crecommended=E2=80=9D configuratio= n as: AES-CBC/GCM-256/MODP-2048/SHA-256/HMAC-SHA1/ECDH-256. >=20 > Well, they explicitly recommend 3k DH groups as an alternative for 1k count= erparts, so this reads like > they are slowly phasing out 2k as well. >=20 > At the end of the page, there is also a table elaborating the "Recommended = Minimum Security Algorithms": > - Encryption: AES-128-GCM mode > - Authentication: RSA-3072, DSA-3072 > - Integrity: SHA-256 > - Key exchange: DH Group 15 (3072-bit) >=20 > This kind of contradicts 2k DH still being listed as "acceptable" in table = 1, though. Err yes. >=20 >> Assuming that this is what the default configuration on Cisco stuff (it mi= ght be that they don=E2=80=99t have any defaults because you would have to cr= eate a crypto map first), we could go the route of ECDH-256. That would allow= us to move RSA to MODP-4096. >=20 > I would like to avoid the ECC curves from NIST and Brainpool for obvious re= asons. What are those obvious reasons? Do you consider them backdoored? With recent stories in the news, I understan= d that that possibility is there and chances are higher than zero. However, w= e do not know whether RSA is backdoored either. Until we have proof, we canno= t really make assumptions here. No algorithm can really be proven unbreakable. But we can proof that somethin= g is broken after we broke it. So that only leaves us with gut feeling and ho= pe for the best. > What do you think about me handing in a second version of the patch just ma= rking the groups, but > leaving the defaults unchanged? That way, we can express the sentiment in t= he release announcement, > and give people more time to prepare for an eventual sunset of MODP-2048 in= our IPsec defaults. No, I would like to make changes to these things all in one go and not very o= ften. Spreading it out over many releases is going to be confusing to us and = our users. So, please wait for me submitting a patch for ECP-384 and then merge them bot= h together once the other one is reviewed and approved, too. This might potentially be something for c171. -Michael > Does this sound reasonable to you? >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >>=20 >> I would also assume that the industry is generally following this. >>=20 >> =E2=80=94 >>=20 >> I want to add that I have the following plan for the new networking: >>=20 >> https://git.ipfire.org/?p=3Dnetwork.git;a=3Dtree;f=3Dconfig/vpn/security-p= olicies;h=3Df14dab80cf8a3102d236b9b41ee91866ea8334f7;hb=3DHEAD >>=20 >> Instead of creating cryptographic parameters per connection, there should = be good defaults. Those can be created as a so called =E2=80=9Csecurity polic= y=E2=80=9D by the user, or by us. Currently there are two: =E2=80=9Csystem=E2= =80=9D and =E2=80=9Cperformance=E2=80=9D. >>=20 >> System is practically everything the system supports. It is mainly useful = for debugging or when you literally don=E2=80=99t care at all. >>=20 >> Then there is performance which is a selection of ciphers that are conside= red secure, but faster. For example AES-GCM-128 over AES-GCM-256 or ChaCha20-= Poly1305. >>=20 >> Ultimately, we would need to add the actual default policy users should be= on. I would like to call them =E2=80=9Cdefault-2022=E2=80=9D where =E2=80=9C= default=E2=80=9D is explaining what it is followed by the year. That allows u= s that people can stay on a current configuration that was recommended at som= e point and keep working connections. For new connections, we can update this= regularly and it would be easily visible that the security policy is more = =E2=80=9Cmodern=E2=80=9D because of the year. >>=20 >> It would still be able to select one of the older ones if you want to be c= ompatible to something else. Maybe we need to create a =E2=80=9Cdefault-1984= =E2=80=9D policy for all those Cisco users out there. >>=20 >> I think this might help us though to not be in this situation again where = we make complicated changes and the user have problems to understand what has= changed or go back to old behaviour. >>=20 >> How do you like this? >>=20 >> -Michael >>=20 >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller >>>=20 >>>>=20 >>>> -Michael >>>>=20 >>>>> Signed-off-by: Peter M=C3=BCller >>>>> --- >>>>> html/cgi-bin/vpnmain.cgi | 14 +++++++------- >>>>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>>>=20 >>>>> diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi >>>>> index 3652627e9..9828b2f9e 100644 >>>>> --- a/html/cgi-bin/vpnmain.cgi >>>>> +++ b/html/cgi-bin/vpnmain.cgi >>>>> @@ -2,7 +2,7 @@ >>>>> #######################################################################= ######## >>>>> # # >>>>> # IPFire.org - A linux based firewall # >>>>> -# Copyright (C) 2007-2020 IPFire Team # >>>>> +# Copyright (C) 2007-2022 IPFire Team # >>>>> # # >>>>> # This program is free software: you can redistribute it and/or modify # >>>>> # it under the terms of the GNU General Public License as published by # >>>>> @@ -2360,11 +2360,11 @@ END >>>>> #use default advanced value >>>>> $cgiparams{'IKE_ENCRYPTION'} =3D 'chacha20poly1305|aes256gcm128|aes256= gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gc= m128|aes128gcm96|aes128gcm64|aes128'; #[18]; >>>>> $cgiparams{'IKE_INTEGRITY'} =3D 'sha2_512|sha2_256'; #[19]; >>>>> - $cgiparams{'IKE_GROUPTYPE'} =3D 'curve448|curve25519|4096|3072|2048';= #[20]; >>>>> + $cgiparams{'IKE_GROUPTYPE'} =3D 'curve448|curve25519|4096|3072'; #[20= ]; >>>>> $cgiparams{'IKE_LIFETIME'} =3D '3'; #[16]; >>>>> $cgiparams{'ESP_ENCRYPTION'} =3D 'chacha20poly1305|aes256gcm128|aes256= gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gc= m128|aes128gcm96|aes128gcm64|aes128'; #[21]; >>>>> $cgiparams{'ESP_INTEGRITY'} =3D 'sha2_512|sha2_256'; #[22]; >>>>> - $cgiparams{'ESP_GROUPTYPE'} =3D 'curve448|curve25519|4096|3072|2048';= #[23]; >>>>> + $cgiparams{'ESP_GROUPTYPE'} =3D 'curve448|curve25519|4096|3072'; #[23= ]; >>>>> $cgiparams{'ESP_KEYLIFE'} =3D '1'; #[17]; >>>>> $cgiparams{'COMPRESSION'} =3D 'off'; #[13]; >>>>> $cgiparams{'ONLY_PROPOSED'} =3D 'on'; #[24]; >>>>> @@ -3146,8 +3146,8 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}= ) || >>>>> >>>>> >>>>> >>>>> - >>>>> - >>>>> + >>>>> + >>>>> >>>>> >>>>> >>>>> @@ -3169,8 +3169,8 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}= ) || >>>>> >>>>> >>>>> >>>>> - >>>>> - >>>>> + >>>>> + >>>>> >>>>> >>>>> >>>>> --=20 >>>>> 2.35.3 --===============3553529484944303858==--