OpenVPN: Fix for '--ns-cert-type server is deprecated' .

Message ID 1507295688-7140-1-git-send-email-erik.kapfer@ipfire.org
State Staged
Commit b66b02ab73863bcb9130300d8ef0eecdc51efde3
Headers show
Series
  • OpenVPN: Fix for '--ns-cert-type server is deprecated' .
Related show

Commit Message

Erik Kapfer Oct. 7, 2017, 12:14 a.m. UTC
- 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(-)

Comments

ummeegge Oct. 7, 2017, 12:19 a.m. UTC | #1
Hi all,
reference and testings can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=18852 .

Greetings,

Erik
Michael Tremer Oct. 11, 2017, 9:58 p.m. UTC | #2
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
ummeegge Oct. 14, 2017, 1:41 a.m. UTC | #3
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
Michael Tremer Oct. 17, 2017, 6:40 a.m. UTC | #4
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
> 
>
ummeegge Oct. 18, 2017, 2:52 a.m. UTC | #5
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-Embedded-Systems-WhitePaper.pdf 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
ummeegge Oct. 20, 2017, 2:37 a.m. UTC | #6
Have found an interesting report causing key lengths and their possible counter value --> https://www.heise.de/security/meldung/Hunderttausende-Infineon-Sicherheits-Chips-weisen-RSA-Schwachstelle-auf-3864691.html?wt_mc=rss.security.beitrag.atom .

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

Patch

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";