RFC 7919 (https://datatracker.ietf.org/doc/html/rfc7919) points out custom generated Diffie Hellman parameters can, under certain circumstances, be abused to weaken strength of traffic encrypted using a PFS cipher. This is backed by various other sources, such as (a) Dutch NCSC (https://english.ncsc.nl/binaries/ncsc-en/documents/publications/2019/juni/01/it-security-guidelines-for-transport-layer-security-tls/IT+Security+Guidelines+for+Transport+Layer+Security+v2.0.pdf, page 27, table 10) (b) OpenSSL (https://wiki.openssl.org/index.php/Diffie-Hellman_parameters#RFC_7919_Groups) Currently, we allow - even require - IPFire users to generate Diffie Hellman parameters on their own if they use OpenVPN. In my understanding of RFC 7919 et al., we should not do this. Instead, we should use one of the audited Diffie Hellman parameters (personally, I use ffdhe4096 for public mail servers), and drop the ability to generate or upload custom ones. Compared to Diffie Hellman key exchanges over elliptic curves (ECDHE), Diffie Hellman itself is remarkably slower. Modern clients do not need it anymore, which is why I would also raise the question if we could stop supporting DH ciphers for OpenVPN at all.
We have tested the '--dh none' in combination with '--ecdh-curve name' option in the old forum relatively extensive also because of the really long generation time while the PKI has been created. The testing results are lost since the forum has been deleted also i thought that we have had a smaller discussion about that topic on the mailinglist which i haven´t found so far. According to a ecdh configuration, here the details From OpenVPN manpage: " --dh file File containing Diffie Hellman parameters in .pem format (required for --tls-server only). Set file=none to disable Diffie Hellman key exchange (and use ECDH only). Note that this requires peers to be using an SSL library that supports ECDH TLS cipher suites (e.g. OpenSSL 1.0.1+, or mbed TLS 2.0+). Use openssl dhparam -out dh2048.pem 2048 to generate 2048-bit DH parameters. Diffie Hellman parameters may be considered public. --ecdh-curve name Specify the curve to use for elliptic curve Diffie Hellman. Available curves can be listed with --show-curves. The specified curve will only be used for ECDH TLS-ciphers. This option is not supported in mbed TLS builds of OpenVPN. " What is your opinion Peter. Deliver a DH-Parameter with the core system and stay on the old algorithm and delete the dh options from the WUI or open up a new algorithm and disable the Diffie Hellman key exchange fully and use ECDH only may with a choice of different curves in the WUI ? Best, Erik
Hi Erik, thanks for your reply. > What is your opinion Peter. Deliver a DH-Parameter with the core system and > stay on the old algorithm and delete the dh options from the WUI or open up a > new algorithm and disable the Diffie Hellman key exchange fully and use ECDH > only may with a choice of different curves in the WUI ? Personally, I would prefer the latter, since this is what we are doing for IPsec as well. However, I have no idea how much collateral damage this would cause to IPFire users - you have a better insight in our OpenVPN community, I guess. :-) If dropping DH entirely is not an option, I would vote for your first suggestion: Deliver a safe DH parameter, and drop related options from the WUI. Thanks, and best regards, Peter Müller
Hello Peter and sorry for the long break. A first step to go here further can be to add a ffdhe4096 from --> https://wiki.openssl.org/index.php/Diffie-Hellman_parameters#RFC_7919_Groups which should be in essence the same then --> https://ssl-config.mozilla.org/ffdhe4096.txt (this format is needed) to the Core system while building OpenVPN like the verify script --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=lfs/openvpn;h=81ccc52bfd24ba05c0f56ba2106111238655021f;hb=refs/heads/core160#l96 and store the DH parameter in /usr/lib/openvpn (safe place which should not be deleted) since /var/ipfire/ovpn will completely wiped out if the PKI get´s renewed for example. The permission of e.g. dh.pem differs to the verify script from the openvpn LFS with -rw-r--r-- 1 root root 769 Oct 27 15:11 /usr/lib/openvpn/dh.pem . Have made a patch (with Core 160) for this which i add to the attachment since i currently do not have access to the development environment, may you can test and deliver this too... Lines in the configuration files (N2N and RW) needs to be changed which should made the commands at the beginning (after commit messages) of the patch. The ECDHE curve topic might be the next/additional step but i wanted to leave this short as possible. Best, Erik
Created attachment 954 [details] Deletes DH parameter sections from CGI and uses static one
According to "dropping DH entirely", have tested it with '--dh none' and commented the old '--dh ..' line entirely which works out of the box and a key exchange on server side looks like this: Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 VERIFY SCRIPT OK: depth=1, C=AF, O=ummeegge, CN=ummeegge CA Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 VERIFY OK: depth=1, C=AF, O=ummeegge, CN=ummeegge CA Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 VERIFY SCRIPT OK: depth=0, C=DE, ST=BW, O=ummeegge, OU=FZeit, CN=testdhnone Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 VERIFY OK: depth=0, C=DE, ST=BW, O=ummeegge, OU=FZeit, CN=testdhnone Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_VER=2.5.4 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_PLAT=linux Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_PROTO=6 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_NCP=2 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_LZ4=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_LZ4v2=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_LZO=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_COMP_STUB=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_COMP_STUBv2=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 peer info: IV_TCPNL=1 Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication Nov 18 11:55:44 ipfire openvpnserver[9895]: testdhnone/192.168.10.5:40991 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256 This requires peers to be using an SSL library that supports ECDH TLS cipher suites (e.g. OpenSSL 1.0.1+, or mbed TLS 2.0+). To get an comparison of the keylength DH vs. ECDH take a look to 'Discrete Logarithm Group' in here --> https://www.keylength.com/en/4/ . Also, to get a ECDHE key exchange, i think a complete ECC PKI might be needed. To use other curves, the '--ecdh-curve name' directive can also be used. An overview of the available ones can be checked via 'openvpn --show-curves' on IPFire console. Just to get more butter to the fish for testings and for other possibilities. Best, Erik P.S.: Manpage 2.5 --> https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html
Hi Peter, have pushed now a possible idea of how to solve this --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=2ccc799f8bd6a12c3edab5f1a89fab4d2cd05ea8 . The main idea is to deliver a standard group of a ffdhe4096.pem parameter via OpenSSL which will be copied while OpenSSL compilation from the ssl directory to /etc/ssl . The complete DH-parameter code in ovpnmain.cgi an the lang files are removed except the "Certificate Authorities and -Keys" chart. As a first step, the second can be to offer also some ECDHE curves via WUI which i am currently working on. What do you think ? Best, Erik
Hello Erik, this time, it is my fault. Apologies for the tardy reply. Thanks for your patch, it looks quite good to me. Just one question: Is it safe to replace the Diffie-Hellman parameter on existing installations? To the best of my understanding, it should be possible to do so without breaking anything already configured, but you are the OpenVPN guru around here, so I just wanted to be sure. :-) All the best, Peter Müller
Sorry, adding you to CC again. Please review my last comment and respond. :-)
Good morning Peter, (In reply to Peter Müller from comment #7) > Thanks for your patch, it looks quite good to me. Just one question: Is it > safe to replace the Diffie-Hellman parameter on existing installations? To > the best of my understanding, it should be possible to do so without > breaking anything already configured, but you are the OpenVPN guru around > here, so I just wanted to be sure. :-) > this should be no problem also for existing installation/running OpenVPN instances. Since we also need to modify the server.conf and all N2N configurations (new path to DH-parameter), we should stop and start all N2Ns and RWs, after that, the new DH-parameter will be in usage for every connection. What do you think of the location where the DH-parameter is placed ? Should we use '/etc/ssl' or may '/etc/pki' ? Also, is it the best way to deliver the 'ffdhe4096.pem' while the build of OpenSSL ? We can surely use the DH-parameter also for other software so i thought this should be the place to distribute it. Best, Erik
Thanks for your reply. Very good to hear that we can migrate existing IPFire installations. > What do you think of the location where the DH-parameter is placed ? Should we use '/etc/ssl' or may '/etc/pki' ? /etc/ssl/ is fine to me. > Also, is it the best way to deliver the 'ffdhe4096.pem' while the build of OpenSSL ? We can surely use the DH-parameter also for other software so i thought this should be the place to distribute it. Well, since we use own Diffie-Hellman parameters in context of OpenVPN only (we shifted away from that for Apache long time ago, and IPsec comes with some DH params built-in), I guess it is more straight-forward to do this in the OpenVPN package rather than OpenSSL. Non-ECC-based Diffie-Hellman is a dying thing anyway... :-) I'll pick up your patch and amend it to Core Update 172.
Ah, sorry, mixed OpenSSL and OpenVPN in my last comment. Sorry for the confusion.
https://patchwork.ipfire.org/project/ipfire/list/?series=3118
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=35494eac83dda575ec4e9998f8295809bf9a280d https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=bc6227963efe10575cdb7aadfc807bd3bd968e9d https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=e044bc2422216610680bf3656d732dcc840de9d1
https://blog.ipfire.org/post/ipfire-2-27-core-update-172-is-available-for-testing
Hello, according to this bug --> https://community.ipfire.org/t/core-172-testing-fails/9002/14 but also another one i have found (N2N related) the the following patch should solve those problems. --- /var/ipfire/langs/de.pl_core172_buggy 2022-12-04 20:34:44.901874457 +0100 +++ /var/ipfire/langs/de.pl 2022-12-04 20:39:54.810759610 +0100 @@ -760,6 +760,7 @@ 'details' => 'Mehr', 'device' => 'Gerät', 'devices on blue' => 'Geräte auf BLAU', +'dh' => 'Diffie-Hellman-Parameter', 'dhcp advopt add' => 'DHCP Option hinzufügen', 'dhcp advopt added' => 'DHCP Option hinzugefügt', 'dhcp advopt blank value' => 'Wert für DHCP Option darf nicht leer sein', @@ -2256,6 +2257,7 @@ 'show ca certificate' => 'CA Zertifikat anzeigen', 'show certificate' => 'Datei anzeigen', 'show crl' => 'Certificate Revocation List anzeigen', +'show dh' => 'Diffie-Hellman-Parameter anzeigen', 'show host certificate' => 'Host-Zertifikat anzeigen', 'show last x lines' => 'die letzten x Zeilen anzeigen', 'show otp qrcode' => 'Zeige OTP QRCode', --- /var/ipfire/langs/en.pl_core172_buggy 2022-12-04 20:06:24.628640598 +0100 +++ /var/ipfire/langs/en.pl 2022-12-04 20:11:56.363993014 +0100 @@ -795,6 +795,7 @@ 'details' => 'Details', 'device' => 'Device', 'devices on blue' => 'Devices on BLUE', +'dh' => 'Diffie-Hellman-Parameter', 'dhcp advopt add' => 'Add a DHCP option', 'dhcp advopt added' => 'DHCP option added', 'dhcp advopt blank value' => 'DHCP Option value cannot be empty.', @@ -2313,6 +2314,7 @@ 'show ca certificate' => 'Show CA certificate', 'show certificate' => 'Show file', 'show crl' => 'Show certificate revocation list', +'show dh' => 'Show Diffie-Hellman parameters', 'show host certificate' => 'Show host certificate', 'show last x lines' => 'Show last x lines', 'show lines' => 'Show lines', --- /srv/web/ipfire/cgi-bin/ovpnmain.cgi_core172_buggy 2022-12-04 19:58:07.719077771 +0100 +++ /srv/web/ipfire/cgi-bin/ovpnmain.cgi 2022-12-04 20:32:13.904384551 +0100 @@ -977,7 +977,7 @@ print SERVERCONF "ca ${General::swroot}/ovpn/ca/cacert.pem\n"; print SERVERCONF "cert ${General::swroot}/ovpn/certs/servercert.pem\n"; print SERVERCONF "key ${General::swroot}/ovpn/certs/serverkey.pem\n"; - print SERVERCONF "dh ${General::swroot}/ovpn/ca/$cgiparams{'DH_NAME'}\n"; + print SERVERCONF "dh $dhparameter\n"; print SERVERCONF "# Cipher\n"; print SERVERCONF "cipher $cgiparams{'DCIPHER'}\n"; @@ -5700,7 +5700,7 @@ print <<END; <tr> - <td class='base' $col3>$Lang::tr{'dh parameter'}</td> + <td class='base' $col3>$Lang::tr{'dh'}</td> <td class='base' $col3>$dhsubject</td> <form method='post' name='frmdhparam'><td width='3%' align='center' $col3> <input type='hidden' name='ACTION' value='$Lang::tr{'show dh'}' /> Best, Erik
Thank you, merged. :-) https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=19a417c2a10df279b2aa0e0644838bf892410a07
https://blog.ipfire.org/post/ipfire-2-27-core-update-172-released