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: Sat, 06 Aug 2022 16:56:02 +0100 Message-ID: <5BA28B62-E5F0-4F5F-B046-F90FAF32E840@ipfire.org> In-Reply-To: <4ab01a7b-6e6c-1049-d5dd-703c99529be4@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9145044568031463389==" List-Id: --===============9145044568031463389== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 6 Aug 2022, at 15:13, Peter M=C3=BCller wro= te: >=20 > Hello Michael, >=20 > thanks for your quick reply. >=20 >> Hello Peter, >>=20 >>> On 6 Aug 2022, at 08:17, Peter M=C3=BCller w= rote: >>>=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/Downl= oads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__bl= ob=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 M= ODP options any more. Not because they are inherently broken, but we would ne= ed longer key lengths which are incredibly hard to generate for >=3D4096 bits= - depending on your hardware. Very often, IPFire is not talking to another I= PFire instance, and that is where it gets really interesting. >>=20 >> 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 no= HWRNGs and slow CPUs which are unable to even produce a 2048 bit prime - but= many of them barely manage. >>=20 >> The reason why MODP-2048 is enabled is, because it makes IPFire more compa= tible with other devices out there. The intention is that a tunnel comes up w= ithout the user visiting the =E2=80=9CAdvanced Settings=E2=80=9D. We do not s= how any indication in the web UI at all if there is a cipher mismatch. So how= 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 interf= aces > leaves the user with a non-green colour indicator of the respective IPsec c= onnection. >=20 > However, I would argue that since debugging already requires shell access a= nd > IPsec/strongSwan internals knowledge today, adding another reason to the li= st > of cases where user need to SSH into their IPFire is not breaking principle= s. I do not think that it is generally okay for standard functionality to send p= eople to the shell. That defeats the entire purpose of why IPFire exists. > Another argument I would back my proposal by is the "secure defaults" one. 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=9Cincompati= ble=E2=80=9D with an =E2=80=9Cindustry standard=E2=80=9D? > People trust IPFire to do reasonably the right thing without having to look= 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. >=20 > I think users should implicitly acknowledge their level of insecurity by ti= cking > weak algorithms explicitly, should they need them for new IPsec connections. But what should be the default then? MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection = to me. >=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 bits >>> in 2022 and later. >>=20 >> I agree with the recommendation, although MODP-3072 is probably a bit poin= tless. It feels too odd to me, and I am sure that devices that support anythi= ng better than 2048 would support 4096 as well. >=20 > True, but in case the remote peer in question does not support anything asi= de > DH, I thought going for 3k instead of 4k DH group still leaves us with _som= e_ > performance benefit. :-) >=20 >> 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. >=20 > 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 con= nection > 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 f= or > anything that lasts beyond 2022, and ideally shifting away from MODP-2048 s= ooner. Obviously we cannot touch any existing connections. I know of enough users still being on 3DES, MD5, SHA1 and what not. Arguably = this is all wasted CPU times, but sadly that is the reality out there. People= 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 there = or who would care to change anything about that. 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 not = going to convince those people running all that outdated shit that they need = to act now. > What do you think about adding a note to the correspondent wiki page to str= ess > this change, should it land in IPFire? That way, we at least don't let users > standing completely in the rain, with no idea where to look. I generally like the idea that we explain more about our decisions. I suppose= 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. Do= esn=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 gro= up > that is explicitly tagged as "weak". :-) Yes, I wouldn=E2=80=99t like that look either. This is however the only way t= o 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/conf= iguration/guide/conf_gd/ike.html Defaults are: 3DES, SHA1, MODP-1024 =E2=80=9CNext Generation=E2=80=9D Ecryption is as follows (https://tools.cisc= o.com/security/center/resources/next_generation_cryptography): 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 avoided (= I consider this wording as 3DES is okay, but maybe shouldn=E2=80=99t be used = for new setups any more). That leaves us with the minimum =E2=80=9Crecommended=E2=80=9D configuration a= s: AES-CBC/GCM-256/MODP-2048/SHA-256/HMAC-SHA1/ECDH-256. Assuming that this is what the default configuration on Cisco stuff (it might= be that they don=E2=80=99t have any defaults because you would have to creat= e a crypto map first), we could go the route of ECDH-256. That would allow us= to move RSA to MODP-4096. 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-poli= cies;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 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. 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 considered= secure, but faster. For example AES-GCM-128 over AES-GCM-256 or ChaCha20-Pol= y1305. 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=9Cdef= ault=E2=80=9D is explaining what it is followed by the year. That allows us t= hat people can stay on a current configuration that was recommended at some p= oint and keep working connections. For new connections, we can update this re= gularly 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 comp= atible 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 has ch= anged or go back to old behaviour. How do you like this? -Michael >=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|aes256gc= m96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm1= 28|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|aes256gc= m96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm1= 28|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 --===============9145044568031463389==--