Hello Michael,
thanks for your quick reply.
Hello Peter,
On 6 Aug 2022, at 08:17, Peter Müller peter.mueller@ipfire.org 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/Downloads/DE/BSI/Publikationen/Technische...) 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 need longer key lengths which are incredibly hard to generate for >=4096 bits - 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’t 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 compatible with other devices out there. The intention is that a tunnel comes up without the user visiting the “Advanced Settings”. We do not 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 interfaces 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 list of cases where user need to SSH into their IPFire is not breaking principles.
Another argument I would back my proposal by is the "secure defaults" one. 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.
I think users should implicitly acknowledge their level of insecurity by ticking weak algorithms explicitly, should they need them for new IPsec connections.
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 >= 3000 bits in 2022 and later.
I agree with the recommendation, although MODP-3072 is probably a bit pointless. It feels too odd to me, and I am sure that devices that support anything 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’t 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 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 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.
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 users standing completely in the rain, with no idea where to look.
Also, it would read kind of ugly if our default selection includes a DH group that is explicitly tagged as "weak". :-)
Thanks, and best regards, Peter Müller
-Michael
Signed-off-by: Peter Müller peter.mueller@ipfire.org
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 info@ipfire.org # +# Copyright (C) 2007-2022 IPFire Team info@ipfire.org # # # # 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'} = 'chacha20poly1305|aes256gcm128|aes256gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm128|aes128gcm96|aes128gcm64|aes128'; #[18]; $cgiparams{'IKE_INTEGRITY'} = 'sha2_512|sha2_256'; #[19];
- $cgiparams{'IKE_GROUPTYPE'} = 'curve448|curve25519|4096|3072|2048'; #[20];
- $cgiparams{'IKE_GROUPTYPE'} = 'curve448|curve25519|4096|3072'; #[20]; $cgiparams{'IKE_LIFETIME'} = '3'; #[16]; $cgiparams{'ESP_ENCRYPTION'} = 'chacha20poly1305|aes256gcm128|aes256gcm96|aes256gcm64|aes256|aes192gcm128|aes192gcm96|aes192gcm64|aes192|aes128gcm128|aes128gcm96|aes128gcm64|aes128'; #[21]; $cgiparams{'ESP_INTEGRITY'} = 'sha2_512|sha2_256'; #[22];
- $cgiparams{'ESP_GROUPTYPE'} = 'curve448|curve25519|4096|3072|2048'; #[23];
- $cgiparams{'ESP_GROUPTYPE'} = 'curve448|curve25519|4096|3072'; #[23]; $cgiparams{'ESP_KEYLIFE'} = '1'; #[17]; $cgiparams{'COMPRESSION'} = 'off'; #[13]; $cgiparams{'ONLY_PROPOSED'} = 'on'; #[24];
@@ -3146,8 +3146,8 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <option value='6144' $checked{'IKE_GROUPTYPE'}{'6144'}>MODP-6144</option> <option value='4096' $checked{'IKE_GROUPTYPE'}{'4096'}>MODP-4096</option> <option value='3072' $checked{'IKE_GROUPTYPE'}{'3072'}>MODP-3072</option>
<option value='2048' $checked{'IKE_GROUPTYPE'}{'2048'}>MODP-2048</option><option value='1536' $checked{'IKE_GROUPTYPE'}{'1536'}>MODP-1536</option>
<option value='2048' $checked{'IKE_GROUPTYPE'}{'2048'}>MODP-2048 ($Lang::tr{'vpn weak'})</option><option value='1536' $checked{'IKE_GROUPTYPE'}{'1536'}>MODP-1536 ($Lang::tr{'vpn broken'})</option> <option value='1024' $checked{'IKE_GROUPTYPE'}{'1024'}>MODP-1024 ($Lang::tr{'vpn broken'})</option> <option value='768' $checked{'IKE_GROUPTYPE'}{'768'}>MODP-768 ($Lang::tr{'vpn broken'})</option> </select>@@ -3169,8 +3169,8 @@ if(($cgiparams{'ACTION'} eq $Lang::tr{'advanced'}) || <option value='6144' $checked{'ESP_GROUPTYPE'}{'6144'}>MODP-6144</option> <option value='4096' $checked{'ESP_GROUPTYPE'}{'4096'}>MODP-4096</option> <option value='3072' $checked{'ESP_GROUPTYPE'}{'3072'}>MODP-3072</option>
<option value='2048' $checked{'ESP_GROUPTYPE'}{'2048'}>MODP-2048</option><option value='1536' $checked{'ESP_GROUPTYPE'}{'1536'}>MODP-1536</option>
<option value='2048' $checked{'ESP_GROUPTYPE'}{'2048'}>MODP-2048 ($Lang::tr{'vpn weak'})</option><option value='1536' $checked{'ESP_GROUPTYPE'}{'1536'}>MODP-1536 ($Lang::tr{'vpn broken'})</option> <option value='1024' $checked{'ESP_GROUPTYPE'}{'1024'}>MODP-1024 ($Lang::tr{'vpn broken'})</option> <option value='768' $checked{'ESP_GROUPTYPE'}{'768'}>MODP-768 ($Lang::tr{'vpn broken'})</option> <option value='none' $checked{'ESP_GROUPTYPE'}{'none'}>- $Lang::tr{'none'} -</option>-- 2.35.3