- Added extended key usage based on RFC3280 TLS rules for OpenVPNs OpenSSL configuration, so '--remote-cert-tls' can be used instead of the old and deprecated '--ns-cert-type' if the host certificate are newely generated with this options. Nevertheless both directives (old and new) will work also with old CAs.
- Automatic detection if the host certificate uses the new options. If it does, '--remote-cert-tls server' will be automatically set into the client configuration files for Net-to-Net and Roadwarriors connections.
If it does NOT, the old '--ns-cert-type server' directive will be set in the client configuration file. --- config/ovpn/openssl/ovpn.cnf | 4 ++++ html/cgi-bin/ovpnmain.cgi | 31 +++++++++++++++++++++++++++---- 2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/config/ovpn/openssl/ovpn.cnf b/config/ovpn/openssl/ovpn.cnf index ab026c1..40daf2a 100644 --- a/config/ovpn/openssl/ovpn.cnf +++ b/config/ovpn/openssl/ovpn.cnf @@ -77,6 +77,8 @@ basicConstraints = CA:FALSE nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always +extendedKeyUsage = clientAuth +keyUsage = digitalSignature
[ server ]
@@ -86,6 +88,8 @@ nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always +extendedKeyUsage = serverAuth +keyUsage = digitalSignature, keyEncipherment
[ v3_req ] basicConstraints = CA:FALSE diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi index d46a14e..ceb88c1 100644 --- a/html/cgi-bin/ovpnmain.cgi +++ b/html/cgi-bin/ovpnmain.cgi @@ -1061,8 +1061,15 @@ unless(-d "${General::swroot}/ovpn/n2nconf/$cgiparams{'NAME'}"){mkdir "${General } } } - - print CLIENTCONF "ns-cert-type server\n"; + # Check host certificate if X509 is RFC3280 compliant. + # If not, old --ns-cert-type directive will be used. + # If appropriate key usage extension exists, new --remote-cert-tls directive will be used. + my $hostcert = `/usr/bin/openssl x509 -text -in ${General::swroot}/ovpn/certs/servercert.pem`; + if ($hostcert !~ /TLS Web Server Authentication/) { + print CLIENTCONF "ns-cert-type server\n"; + } else { + print CLIENTCONF "remote-cert-tls server\n"; + } print CLIENTCONF "# Auth. Client\n"; print CLIENTCONF "tls-client\n"; print CLIENTCONF "# Cipher\n"; @@ -2173,7 +2180,15 @@ if ($confighash{$cgiparams{'KEY'}}[3] eq 'net'){ } } } - print CLIENTCONF "ns-cert-type server\n"; + # Check host certificate if X509 is RFC3280 compliant. + # If not, old --ns-cert-type directive will be used. + # If appropriate key usage extension exists, new --remote-cert-tls directive will be used. + my $hostcert = `/usr/bin/openssl x509 -text -in ${General::swroot}/ovpn/certs/servercert.pem`; + if ($hostcert !~ /TLS Web Server Authentication/) { + print CLIENTCONF "ns-cert-type server\n"; + } else { + print CLIENTCONF "remote-cert-tls server\n"; + } print CLIENTCONF "# Auth. Client\n"; print CLIENTCONF "tls-client\n"; print CLIENTCONF "# Cipher\n"; @@ -2332,7 +2347,15 @@ else print CLIENTCONF "comp-lzo\r\n"; } print CLIENTCONF "verb 3\r\n"; - print CLIENTCONF "ns-cert-type server\r\n"; + # Check host certificate if X509 is RFC3280 compliant. + # If not, old --ns-cert-type directive will be used. + # If appropriate key usage extension exists, new --remote-cert-tls directive will be used. + my $hostcert = `/usr/bin/openssl x509 -text -in ${General::swroot}/ovpn/certs/servercert.pem`; + if ($hostcert !~ /TLS Web Server Authentication/) { + print CLIENTCONF "ns-cert-type server\r\n"; + } else { + print CLIENTCONF "remote-cert-tls server\r\n"; + } print CLIENTCONF "verify-x509-name $vpnsettings{ROOTCERT_HOSTNAME} name\r\n"; if ($vpnsettings{MSSFIX} eq 'on') { print CLIENTCONF "mssfix\r\n";
Hi all, reference and testings can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852 .
Greetings,
Erik
Thank you very much. Merged.
On Fri, 2017-10-06 at 15:19 +0200, ummeegge wrote:
Hi all, reference and testings can be found in here --> https://forum.ipfire.org/viewt opic.php?f=50&t=18852 .
Greetings,
Erik
Hi Michael, thank you too for merging. Have think about to introduce with this patch also a choice (flip menus) for ROOT and HOST CA key lengths if a new PKI is generated. To use the new --remote-cert-tls there is anyways the need to generate a new PKI so it might be possibly nice to have then also a possibility to select keylengths of IPFires certificates ? A possible solution can looks like this --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852&start=15#p108795 so the ROOT CA are provided with 4096, 6144, 8192, 12288 and the HOST CA with 2048, 4096, 6144, 8192, 12288 bits . Did some testings with that whereby 12288 are the maximum made also tests with 16384 but this was too much for generating but also for usage.
As an extended idea.
Greetings,
Erik
Thank you very much. Merged.
On Fri, 2017-10-06 at 15:19 +0200, ummeegge wrote:
Hi all, reference and testings can be found in here --> https://forum.ipfire.org/viewt opic.php?f=50&t=18852 .
Greetings,
Erik
Hi,
I generally like the idea. However, I am not sure if anyone will know how to use this. Do all OSes support 12k RSA keys? Or should we rather not make this decision for our users and pick the best that works for everyone?
-Michael
On Fri, 2017-10-13 at 16:41 +0200, ummeegge wrote:
Hi Michael, thank you too for merging. Have think about to introduce with this patch also a choice (flip menus) for ROOT and HOST CA key lengths if a new PKI is generated. To use the new -- remote-cert-tls there is anyways the need to generate a new PKI so it might be possibly nice to have then also a possibility to select keylengths of IPFires certificates ? A possible solution can looks like this --> https://forum.ipfire.org/viewtopic .php?f=50&t=18852&start=15#p108795 so the ROOT CA are provided with 4096, 6144, 8192, 12288 and the HOST CA with 2048, 4096, 6144, 8192, 12288 bits . Did some testings with that whereby 12288 are the maximum made also tests with 16384 but this was too much for generating but also for usage.
As an extended idea.
Greetings,
Erik
Thank you very much. Merged.
On Fri, 2017-10-06 at 15:19 +0200, ummeegge wrote:
Hi all, reference and testings can be found in here --> https://forum.ipfire.org/v iewt opic.php?f=50&t=18852 .
Greetings,
Erik
Hi Michael,
I generally like the idea. However, I am not sure if anyone will know how to use this.
this was also one of my concerns, you are probably right that this settings might not be clear for every one.
Do all OSes support 12k RSA keys?
Have tested it so far on Linux and MAC (also older ones up to 10.7) systems but also in some N2N connections with older boards (JNC9C) where it was no problem. The generation time for the PKI but also for every new generated client grows by the usage of more bits but also the key exchange needs a little longer.
Or should we rather not make this decision for our users and pick the best that works for everyone?
We did that some time ago where we double the bits from 1024 to 2048 (HOST) and 2048 to 4096 (ROOT). The OpenVPN hardening page suggests for a "future system near term use" specified to 10 years, 3072 bit or more --> https://community.openvpn.net/openvpn/wiki/Hardening#X.509keysize . The reference material is from a ENISA report from 2013 which is now also some time ago.
Another interesting topic might be ECC. Since OpenVPN-2.4.x elliptic curve crypto has been introduced whereby the comparison between RSA and ECC seems to be interesting in terms of the different Algorithm-key sizes. Haven´t found the original NSA paper but in here --> http://www.atmel.com/Images/Atmel-8951-CryptoAuth-RSA-ECC-Comparison-Embedde... under table one a security comparison can be found.
To get the whole ECC PKI into ovpnmain.cgi might be not so fast done but i think in a not so far future it might be also a standard.
Greetings,
Erik
Have found an interesting report causing key lengths and their possible counter value --> https://www.heise.de/security/meldung/Hunderttausende-Infineon-Sicherheits-C... .
If RSA 1024 is about 40 - 80 Dollars worth but RSA 2048 belongs from 20k to 40k which seems to be the today disposal values regarding that report, it might be interesting what happens with 4096 or 8192 :-) .
Only as a short beside tweet.
All the best,
Erik