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 12:51:58 +0000 Message-ID: In-Reply-To: <5BA28B62-E5F0-4F5F-B046-F90FAF32E840@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1102376784833800925==" List-Id: --===============1102376784833800925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, apologies for my late reply. > Hello, >=20 >> On 6 Aug 2022, at 15:13, Peter M=C3=BCller wr= ote: >> >> 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/Down= loads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__b= lob=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 the = MODP options any more. Not because they are inherently broken, but we would n= eed longer key lengths which are incredibly hard to generate for >=3D4096 bit= s - depending on your hardware. Very often, IPFire is not talking to another = IPFire instance, and that is where it gets really interesting. >>> >>> However, having said that there are lots of bad devices out there, plenty= don=E2=80=99t support any ECC - not even speaking of Curve25519. They have n= o HWRNGs and slow CPUs which are unable to even produce a 2048 bit prime - bu= t many of them barely manage. >>> >>> The reason why MODP-2048 is enabled is, because it makes IPFire more comp= atible 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 ho= w 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 inter= faces >> leaves the user with a non-green colour indicator of the respective IPsec = connection. >> >> However, I would argue that since debugging already requires shell access = and >> IPsec/strongSwan internals knowledge today, adding another reason to the l= ist >> of cases where user need to SSH into their IPFire is not breaking principl= es. >=20 > I do not think that it is generally okay for standard functionality to send= 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 this. >> 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 t= op of the list of priorities and that is it then. >=20 > However, what is it good for if IPFire practically becomes =E2=80=9Cincompa= tible=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 loo= k at >> every single detail. IPsec users having sufficiently up-to-date peers today >> (hence not relying on MODP-2048) are probably not comfortable with the idea >> that the default selection features a DH group a nation-state threat actor= can >> likely break in the foreseeable future. >> >> I think users should implicitly acknowledge their level of insecurity by t= icking >> weak algorithms explicitly, should they need them for new IPsec connection= s. >=20 > But what should be the default then? >=20 > MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selectio= n to me. Since we made this choice based on facts, I do not see why it is random (thou= gh I agree it might look so to the layman). >=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 bi= ts >>>> in 2022 and later. >>> >>> I agree with the recommendation, although MODP-3072 is probably a bit poi= ntless. It feels too odd to me, and I am sure that devices that support anyth= ing better than 2048 would support 4096 as well. >> >> True, but in case the remote peer in question does not support anything as= ide >> DH, I thought going for 3k instead of 4k DH group still leaves us with _so= me_ >> 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 make= the setup process a lot more complicated for users. >> >> I would have agreed with your concern a couple of years ago, when MODP-2048 >> was still looking fine. However, sine this patch won't affect any IPsec co= nnection >> 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. Full ACK. >=20 > I know of enough users still being on 3DES, MD5, SHA1 and what not. Arguabl= y this is all wasted CPU times, but sadly that is the reality out there. Peop= le have to connect to business partners or other peers that are running on ve= ry outdated hardware and have nobody who understands what they are doing ther= e 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 no= t going to convince those people running all that outdated shit that they nee= d to act now. >=20 >> What do you think about adding a note to the correspondent wiki page to st= ress >> this change, should it land in IPFire? That way, we at least don't let use= rs >> 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 suppo= se 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 gr= oup >> that is explicitly tagged as "weak". :-) >=20 > Yes, I wouldn=E2=80=99t like that look either. This is however the only way= 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/co= nfiguration/guide/conf_gd/ike.html >=20 > Defaults are: 3DES, SHA1, MODP-1024 Okay, our defaults are incompatible to that anyway. >=20 > =E2=80=9CNext Generation=E2=80=9D Ecryption is as follows (https://tools.ci= sco.com/security/center/resources/next_generation_cryptography): Unfortunately, this page won't load here, no matter what I try. Had to go bac= k to the archive... :-/ > 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 avoided= (I consider this wording as 3DES is okay, but maybe shouldn=E2=80=99t be use= d for new setups any more). >=20 > That leaves us with the minimum =E2=80=9Crecommended=E2=80=9D configuration= 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 counter= parts, 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 Mi= nimum 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. > Assuming that this is what the default configuration on Cisco stuff (it mig= ht be that they don=E2=80=99t have any defaults because you would have to cre= ate a crypto map first), we could go the route of ECDH-256. That would allow = us to move RSA to MODP-4096. I would like to avoid the ECC curves from NIST and Brainpool for obvious reas= ons. What do you think about me handing in a second version of the patch just mark= ing 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 in o= ur IPsec defaults. Does this sound reasonable to you? Thanks, and best regards, Peter M=C3=BCller >=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-po= licies;h=3Df14dab80cf8a3102d236b9b41ee91866ea8334f7;hb=3DHEAD >=20 > Instead of creating cryptographic parameters per connection, there should b= e good defaults. Those can be created as a so called =E2=80=9Csecurity policy= =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 f= or 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 consider= ed secure, but faster. For example AES-GCM-128 over AES-GCM-256 or ChaCha20-P= oly1305. >=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=9Cd= efault=E2=80=9D is explaining what it is followed by the year. That allows 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 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 co= mpatible 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 w= e 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 >> >> 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|aes256g= cm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm= 128|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|aes256g= cm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm= 128|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 >=20 --===============1102376784833800925==--