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