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.
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.
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>
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?
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.
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.
-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
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
Hello,
On 6 Aug 2022, at 15:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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.
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 “incompatible” with an “industry standard”?
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.
But what should be the default then?
MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection to me.
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.
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 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.
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’t read those things. Doesn’t necessarily mean that they shouldn’t 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’t like that look either. This is however the only way 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...
Defaults are: 3DES, SHA1, MODP-1024
“Next Generation” Ecryption is as follows (https://tools.cisco.com/security/center/resources/next_generation_cryptograp...):
3DES/SHA1/HMAC-MD5 are considered “legacy”.
DES (no I did not miss the 3)/MODP<=1024/MD5 are considered to be avoided (I consider this wording as 3DES is okay, but maybe shouldn’t be used for new setups any more).
That leaves us with the minimum “recommended” configuration as: 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’t have any defaults because you would have to create 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.
—
I want to add that I have the following plan for the new networking:
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
Instead of creating cryptographic parameters per connection, there should be good defaults. Those can be created as a so called “security policy” by the user, or by us. Currently there are two: “system” and “performance”.
System is practically everything the system supports. It is mainly useful for debugging or when you literally don’t 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-Poly1305.
Ultimately, we would need to add the actual default policy users should be on. I would like to call them “default-2022” where “default” 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 “modern” 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 “default-1984” 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 changed or go back to old behaviour.
How do you like this?
-Michael
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
Hello,
On 6 Aug 2022, at 15:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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.
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 “incompatible” with an “industry standard”?
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.
But what should be the default then?
MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection to me.
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.
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 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.
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’t read those things. Doesn’t necessarily mean that they shouldn’t 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’t like that look either. This is however the only way 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...
Defaults are: 3DES, SHA1, MODP-1024
“Next Generation” Ecryption is as follows (https://tools.cisco.com/security/center/resources/next_generation_cryptograp...):
3DES/SHA1/HMAC-MD5 are considered “legacy”.
DES (no I did not miss the 3)/MODP<=1024/MD5 are considered to be avoided (I consider this wording as 3DES is okay, but maybe shouldn’t be used for new setups any more).
That leaves us with the minimum “recommended” configuration as: 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’t have any defaults because you would have to create 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.
—
I want to add that I have the following plan for the new networking:
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
Instead of creating cryptographic parameters per connection, there should be good defaults. Those can be created as a so called “security policy” by the user, or by us. Currently there are two: “system” and “performance”.
System is practically everything the system supports. It is mainly useful for debugging or when you literally don’t 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-Poly1305.
Ultimately, we would need to add the actual default policy users should be on. I would like to call them “default-2022” where “default” 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 “modern” 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 “default-1984” 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 changed or go back to old behaviour.
How do you like this?
-Michael
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
Hello Michael,
apologies for my late reply.
Hello,
On 6 Aug 2022, at 15:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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.
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 “incompatible” with an “industry standard”?
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.
But what should be the default then?
MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection to me.
Since we made this choice based on facts, I do not see why it is random (though I agree it might look so to the layman).
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.
Obviously we cannot touch any existing connections.
Full ACK.
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 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.
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’t read those things. Doesn’t necessarily mean that they shouldn’t 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’t like that look either. This is however the only way 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...
Defaults are: 3DES, SHA1, MODP-1024
Okay, our defaults are incompatible to that anyway.
“Next Generation” Ecryption is as follows (https://tools.cisco.com/security/center/resources/next_generation_cryptograp...):
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 “legacy”.
DES (no I did not miss the 3)/MODP<=1024/MD5 are considered to be avoided (I consider this wording as 3DES is okay, but maybe shouldn’t be used for new setups any more).
That leaves us with the minimum “recommended” 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 counterparts, 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.
Assuming that this is what the default configuration on Cisco stuff (it might be that they don’t have any defaults because you would have to create 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 reasons.
What do you think about me handing in a second version of the patch just marking 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 our IPsec defaults.
Does this sound reasonable to you?
Thanks, and best regards, Peter Müller
I would also assume that the industry is generally following this.
—
I want to add that I have the following plan for the new networking:
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
Instead of creating cryptographic parameters per connection, there should be good defaults. Those can be created as a so called “security policy” by the user, or by us. Currently there are two: “system” and “performance”.
System is practically everything the system supports. It is mainly useful for debugging or when you literally don’t 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-Poly1305.
Ultimately, we would need to add the actual default policy users should be on. I would like to call them “default-2022” where “default” 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 “modern” 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 “default-1984” 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 changed or go back to old behaviour.
How do you like this?
-Michael
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
Hello Peter,
On 11 Aug 2022, at 13:51, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
apologies for my late reply.
Hello,
On 6 Aug 2022, at 15:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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.
Not yet :)
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 “incompatible” with an “industry standard”?
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.
But what should be the default then?
MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection to me.
Since we made this choice based on facts, I do not see why it is random (though 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 “strong” and “stronger” options? That isn’t obvious to a user.
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.
Obviously we cannot touch any existing connections.
Full ACK.
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 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.
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’t read those things. Doesn’t necessarily mean that they shouldn’t 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’t like that look either. This is however the only way 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...
Defaults are: 3DES, SHA1, MODP-1024
Okay, our defaults are incompatible to that anyway.
Well great. That makes things very easy then. We can simply go ahead with this patch as it is then.
Acked-by: Michael Tremer michael.tremer@ipfire.org
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.
“Next Generation” Ecryption is as follows (https://tools.cisco.com/security/center/resources/next_generation_cryptograp...):
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 “legacy”.
DES (no I did not miss the 3)/MODP<=1024/MD5 are considered to be avoided (I consider this wording as 3DES is okay, but maybe shouldn’t be used for new setups any more).
That leaves us with the minimum “recommended” 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 counterparts, 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.
Err yes.
Assuming that this is what the default configuration on Cisco stuff (it might be that they don’t have any defaults because you would have to create 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 reasons.
What are those obvious reasons?
Do you consider them backdoored? With recent stories in the news, I understand 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 cannot really make assumptions here.
No algorithm can really be proven unbreakable. But we can proof that something is broken after we broke it. So that only leaves us with gut feeling and hope for the best.
What do you think about me handing in a second version of the patch just marking 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 our IPsec defaults.
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 and our users.
So, please wait for me submitting a patch for ECP-384 and then merge them both together once the other one is reviewed and approved, too.
This might potentially be something for c171.
-Michael
Does this sound reasonable to you?
Thanks, and best regards, Peter Müller
I would also assume that the industry is generally following this.
—
I want to add that I have the following plan for the new networking:
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
Instead of creating cryptographic parameters per connection, there should be good defaults. Those can be created as a so called “security policy” by the user, or by us. Currently there are two: “system” and “performance”.
System is practically everything the system supports. It is mainly useful for debugging or when you literally don’t 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-Poly1305.
Ultimately, we would need to add the actual default policy users should be on. I would like to call them “default-2022” where “default” 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 “modern” 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 “default-1984” 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 changed or go back to old behaviour.
How do you like this?
-Michael
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
https://lists.ipfire.org/pipermail/development/2022-August/014129.html
Signed-off-by: Michael Tremer michael.tremer@ipfire.org --- html/cgi-bin/vpnmain.cgi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi index 3652627e9..5f5e9833c 100644 --- a/html/cgi-bin/vpnmain.cgi +++ b/html/cgi-bin/vpnmain.cgi @@ -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|e521|e384|4096|3072|2048'; #[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|e521|e384|4096|3072|2048'; #[23]; $cgiparams{'ESP_KEYLIFE'} = '1'; #[17]; $cgiparams{'COMPRESSION'} = 'off'; #[13]; $cgiparams{'ONLY_PROPOSED'} = 'on'; #[24];
Acked-by: Peter Müller peter.mueller@ipfire.org
https://lists.ipfire.org/pipermail/development/2022-August/014129.html
Signed-off-by: Michael Tremer michael.tremer@ipfire.org
html/cgi-bin/vpnmain.cgi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/html/cgi-bin/vpnmain.cgi b/html/cgi-bin/vpnmain.cgi index 3652627e9..5f5e9833c 100644 --- a/html/cgi-bin/vpnmain.cgi +++ b/html/cgi-bin/vpnmain.cgi @@ -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|e521|e384|4096|3072|2048'; #[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|e521|e384|4096|3072|2048'; #[23]; $cgiparams{'ESP_KEYLIFE'} = '1'; #[17]; $cgiparams{'COMPRESSION'} = 'off'; #[13]; $cgiparams{'ONLY_PROPOSED'} = 'on'; #[24];
Hello Michael,
Hello Peter,
On 11 Aug 2022, at 13:51, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
apologies for my late reply.
Hello,
On 6 Aug 2022, at 15:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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.
Not yet :)
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 “incompatible” with an “industry standard”?
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.
But what should be the default then?
MODP-4096/3075 + Curve448 + Curve25519 seems to be a rather random selection to me.
Since we made this choice based on facts, I do not see why it is random (though 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 “strong” and “stronger” options? That isn’t obvious to a user.
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.
Obviously we cannot touch any existing connections.
Full ACK.
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 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.
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’t read those things. Doesn’t necessarily mean that they shouldn’t 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’t like that look either. This is however the only way 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...
Defaults are: 3DES, SHA1, MODP-1024
Okay, our defaults are incompatible to that anyway.
Well great. That makes things very easy then. We can simply go ahead with this patch as it is then.
Acked-by: Michael Tremer michael.tremer@ipfire.org
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.
“Next Generation” Ecryption is as follows (https://tools.cisco.com/security/center/resources/next_generation_cryptograp...):
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 “legacy”.
DES (no I did not miss the 3)/MODP<=1024/MD5 are considered to be avoided (I consider this wording as 3DES is okay, but maybe shouldn’t be used for new setups any more).
That leaves us with the minimum “recommended” 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 counterparts, 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.
Err yes.
Assuming that this is what the default configuration on Cisco stuff (it might be that they don’t have any defaults because you would have to create 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 reasons.
What are those obvious reasons?
Do you consider them backdoored? With recent stories in the news, I understand 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 cannot really make assumptions here.
No algorithm can really be proven unbreakable. But we can proof that something is broken after we broke it. So that only leaves us with gut feeling and hope for the best.
What do you think about me handing in a second version of the patch just marking 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 our IPsec defaults.
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 and our users.
So, please wait for me submitting a patch for ECP-384 and then merge them both 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üller
-Michael
Does this sound reasonable to you?
Thanks, and best regards, Peter Müller
I would also assume that the industry is generally following this.
—
I want to add that I have the following plan for the new networking:
https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;...
Instead of creating cryptographic parameters per connection, there should be good defaults. Those can be created as a so called “security policy” by the user, or by us. Currently there are two: “system” and “performance”.
System is practically everything the system supports. It is mainly useful for debugging or when you literally don’t 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-Poly1305.
Ultimately, we would need to add the actual default policy users should be on. I would like to call them “default-2022” where “default” 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 “modern” 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 “default-1984” 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 changed or go back to old behaviour.
How do you like this?
-Michael
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
-
Michael Tremer -
Peter Müller