From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] vpnmain.cgi: Mark MODP-1536 as broken, phase out MODP-2048 Date: Thu, 11 Aug 2022 18:27:23 +0000 Message-ID: <26027da8-d524-51be-39b7-dbc7a0826ad3@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3433860171038502951==" List-Id: --===============3433860171038502951== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > Hello Peter, >=20 >> On 11 Aug 2022, at 13:51, Peter M=C3=BCller w= rote: >> >> Hello Michael, >> >> apologies for my late reply. >> >>> Hello, >>> >>>> On 6 Aug 2022, at 15:13, Peter M=C3=BCller = wrote: >>>> >>>> Hello Michael, >>>> >>>> thanks for your quick reply. >>>> >>>>> Hello Peter, >>>>> >>>>>> On 6 Aug 2022, at 08:17, Peter M=C3=BCller wrote: >>>>>> >>>>>> 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/Do= wnloads/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. >>>>>> >>>>>> 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. >>>>> >>>>> I generally agree with that statement. >>>>> >>>>> In my personal opinion, I believe that we should not be using any of th= e 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 b= its - depending on your hardware. Very often, IPFire is not talking to anothe= r IPFire instance, and that is where it gets really interesting. >>>>> >>>>> However, having said that there are lots of bad devices out there, plen= ty 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 - = but many of them barely manage. >>>>> >>>>> The reason why MODP-2048 is enabled is, because it makes IPFire more co= mpatible with other devices out there. The intention is that a tunnel comes u= p without the user visiting the =E2=80=9CAdvanced Settings=E2=80=9D. We do no= t show any indication in the web UI at all if there is a cipher mismatch. So = how else is the user supposed to find out? >>>> >>>> As so often, I agree with your intention, but not with the outcome of it= . :-) >>>> >>>> True, if a tunnel cannot be established for whatever reason, the web int= erfaces >>>> leaves the user with a non-green colour indicator of the respective IPse= c connection. >>>> >>>> However, I would argue that since debugging already requires shell acces= s 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 princi= ples. >>> >>> I do not think that it is generally okay for standard functionality to se= nd people to the shell. That defeats the entire purpose of why IPFire exists. >> >> ACK, but for IPsec, we do not really have a robust approach for avoiding t= his. >=20 > Not yet :) >=20 >> >>>> Another argument I would back my proposal by is the "secure defaults" on= e. >>> >>> 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. >>> >>> However, what is it good for if IPFire practically becomes =E2=80=9Cincom= patible=E2=80=9D with an =E2=80=9Cindustry standard=E2=80=9D? >>> >>>> People trust IPFire to do reasonably the right thing without having to l= ook at >>>> every single detail. IPsec users having sufficiently up-to-date peers to= day >>>> (hence not relying on MODP-2048) are probably not comfortable with the i= dea >>>> that the default selection features a DH group a nation-state threat act= or can >>>> likely break in the foreseeable future. >>>> >>>> I think users should implicitly acknowledge their level of insecurity by= ticking >>>> weak algorithms explicitly, should they need them for new IPsec connecti= ons. >>> >>> But what should be the default then? >>> >>> MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random select= ion to me. >> >> Since we made this choice based on facts, I do not see why it is random (t= hough >> I agree it might look so to the layman). >=20 > Because it suggests that the options that we did not select are not good wh= en 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 >> >>> >>>> >>>>> >>>>>> 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 = bits >>>>>> in 2022 and later. >>>>> >>>>> I agree with the recommendation, although MODP-3072 is probably a bit p= ointless. It feels too odd to me, and I am sure that devices that support any= thing better than 2048 would support 4096 as well. >>>> >>>> True, but in case the remote peer in question does not support anything = aside >>>> DH, I thought going for 3k instead of 4k DH group still leaves us with _= some_ >>>> performance benefit. :-) >>>> >>>>> I agree with 2048 being marked as weak, but I do not agree with taking = it out of the default list. It shouldn=E2=80=99t be on there, but we would ma= ke the setup process a lot more complicated for users. >>>> >>>> I would have agreed with your concern a couple of years ago, when MODP-2= 048 >>>> was still looking fine. However, sine this patch won't affect any IPsec = connection >>>> already configured (and such configurations tend to last for long times), >>>> still including MODP-2048 in the defaults does not seem to be a reasonab= le >>>> decision. The BSI probably has good reasons why they recommend against i= t for >>>> anything that lasts beyond 2022, and ideally shifting away from MODP-204= 8 sooner. >>> >>> Obviously we cannot touch any existing connections. >> >> Full ACK. >> >>> >>> I know of enough users still being on 3DES, MD5, SHA1 and what not. Argua= bly this is all wasted CPU times, but sadly that is the reality out there. Pe= ople have to connect to business partners or other peers that are running on = very outdated hardware and have nobody who understands what they are doing th= ere or who would care to change anything about that. >>> >>> Well, if the BSI has any reasons, it is sad that those are not transparen= t. A random decision that is just being announced without being explained is = not going to convince those people running all that outdated shit that they n= eed to act now. >>> >>>> What do you think about adding a note to the correspondent wiki page to = stress >>>> this change, should it land in IPFire? That way, we at least don't let u= sers >>>> standing completely in the rain, with no idea where to look. >>> >>> I generally like the idea that we explain more about our decisions. I sup= pose sometimes they appear random and coming out of the blue for users. >>> >>> 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. >>> >>>> Also, it would read kind of ugly if our default selection includes a DH = group >>>> that is explicitly tagged as "weak". :-) >>> >>> Yes, I wouldn=E2=80=99t like that look either. This is however the only w= ay to achieve some compatibility. >>> >>> Looking at the competition we have things like this: >>> >>> Cisco ASA-5500: https://www.cisco.com/c/en/us/td/docs/security/asa/asa72/= configuration/guide/conf_gd/ike.html >>> >>> Defaults are: 3DES, SHA1, MODP-1024 >> >> Okay, our defaults are incompatible to that anyway. >=20 > Well great. That makes things very easy then. We can simply go ahead with t= his patch as it is then. >=20 > Acked-by: Michael Tremer >=20 > But I would like to add at least ECP-384 as well then. I do not see that we= do not offer that when it is pretty much the next best option after RSA. >=20 >>> =E2=80=9CNext Generation=E2=80=9D Ecryption is as follows (https://tools.= cisco.com/security/center/resources/next_generation_cryptography): >> >> Unfortunately, this page won't load here, no matter what I try. Had to go = back to the archive... :-/ >> >>> 3DES/SHA1/HMAC-MD5 are considered =E2=80=9Clegacy=E2=80=9D. >>> >>> DES (no I did not miss the 3)/MODP<=3D1024/MD5 are considered to be avoid= ed (I consider this wording as 3DES is okay, but maybe shouldn=E2=80=99t be u= sed for new setups any more). >>> >>> That leaves us with the minimum =E2=80=9Crecommended=E2=80=9D configurati= on as: AES-CBC/GCM-256/MODP-2048/SHA-256/HMAC-SHA1/ECDH-256. >> >> Well, they explicitly recommend 3k DH groups as an alternative for 1k coun= terparts, so this reads like >> they are slowly phasing out 2k as well. >> >> 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) >> >> This kind of contradicts 2k DH still being listed as "acceptable" in table= 1, though. >=20 > Err yes. >=20 >> >>> Assuming that this is what the default configuration on Cisco stuff (it m= ight be that they don=E2=80=99t have any defaults because you would have to c= reate a crypto map first), we could go the route of ECDH-256. That would allo= w us to move RSA to MODP-4096. >> >> I would like to avoid the ECC curves from NIST and Brainpool for obvious r= easons. >=20 > What are those obvious reasons? >=20 > Do you consider them backdoored? With recent stories in the news, I underst= and that that possibility is there and chances are higher than zero. However,= we do not know whether RSA is backdoored either. Until we have proof, we can= not really make assumptions here. >=20 > No algorithm can really be proven unbreakable. But we can proof that someth= ing is broken after we broke it. So that only leaves us with gut feeling and = hope for the best. >=20 >> What do you think about me handing in a second version of the patch just m= arking the groups, but >> leaving the defaults unchanged? That way, we can express the sentiment in = the release announcement, >> and give people more time to prepare for an eventual sunset of MODP-2048 i= n our IPsec defaults. >=20 > No, I would like to make changes to these things all in one go and not very= often. Spreading it out over many releases is going to be confusing to us an= d our users. >=20 > So, please wait for me submitting a patch for ECP-384 and then merge them b= oth together once the other one is reviewed and approved, too. excellent, thank you very much. > This might potentially be something for c171. Since these changes are not space-consuming, I would take the liberty to ship= them with Core Update 170. :-) All the best, Peter M=C3=BCller >=20 > -Michael >=20 >> Does this sound reasonable to you? >> >> Thanks, and best regards, >> Peter M=C3=BCller >> >>> >>> I would also assume that the industry is generally following this. >>> >>> =E2=80=94 >>> >>> I want to add that I have the following plan for the new networking: >>> >>> https://git.ipfire.org/?p=3Dnetwork.git;a=3Dtree;f=3Dconfig/vpn/security-= policies;h=3Df14dab80cf8a3102d236b9b41ee91866ea8334f7;hb=3DHEAD >>> >>> Instead of creating cryptographic parameters per connection, there should= be good defaults. Those can be created as a so called =E2=80=9Csecurity poli= cy=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. >>> >>> System is practically everything the system supports. It is mainly useful= for debugging or when you literally don=E2=80=99t care at all. >>> >>> Then there is performance which is a selection of ciphers that are consid= ered secure, but faster. For example AES-GCM-128 over AES-GCM-256 or ChaCha20= -Poly1305. >>> >>> Ultimately, we would need to add the actual default policy users should b= e on. I would like to call them =E2=80=9Cdefault-2022=E2=80=9D where =E2=80= =9Cdefault=E2=80=9D is explaining what it is followed by the year. That allow= s us that people can stay on a current configuration that was recommended at = some point and keep working connections. For new connections, we can update t= his regularly and it would be easily visible that the security policy is more= =E2=80=9Cmodern=E2=80=9D because of the year. >>> >>> It would still be able to select one of the older ones if you want to be = compatible to something else. Maybe we need to create a =E2=80=9Cdefault-1984= =E2=80=9D policy for all those Cisco users out there. >>> >>> 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 ha= s changed or go back to old behaviour. >>> >>> How do you like this? >>> >>> -Michael >>> >>>> >>>> Thanks, and best regards, >>>> Peter M=C3=BCller >>>> >>>>> >>>>> -Michael >>>>> >>>>>> Signed-off-by: Peter M=C3=BCller >>>>>> --- >>>>>> html/cgi-bin/vpnmain.cgi | 14 +++++++------- >>>>>> 1 file changed, 7 insertions(+), 7 deletions(-) >>>>>> >>>>>> 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|aes25= 6gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128g= cm128|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'; #[2= 0]; >>>>>> $cgiparams{'IKE_LIFETIME'} =3D '3'; #[16]; >>>>>> $cgiparams{'ESP_ENCRYPTION'} =3D 'chacha20poly1305|aes256gcm128|aes25= 6gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128g= cm128|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'; #[2= 3]; >>>>>> $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 >=20 --===============3433860171038502951==--