Selection menu for OpenVPN CA keylenght

  Hi Michael,
have changed now the topic cause "Mark recommended ciphers/algorithms" do not match fully this topic. 

Am 04.01.2016 um 17:36 schrieb Michael Tremer:

> Hi,
> 
> On Sat, 2016-01-02 at 14:03 +0100, ue wrote:
>> Hi all,
>> and for the first a good new year to you all.
>>> 
>>> I agree, that it is desirable to use longer keys. However, I am not
>>> sure if it is a good idea to go all the way for 4096 bit and not
>>> only
>>> for e.g. 2048 bit. Why not 8192 even?
>>> 
>>> I would like to read some justification for the values that are
>>> picked.
>>> 
>>> Furthermore, I think that we the upper bound should be something
>>> that
>>> the average IPFire box is able to handle.
>> 
>> 
>> tried that now with OpenVPN whereby i added a flip menu in the
>> 'Generate Root/Host Certificate' section as it is for the Diffie
>> -Hellman parameter so the keylengths aren´t hardcoded anymore and can
>> be configured by the user. Added for the root CA 4096, 8192 and 16348
>> tit lengths selection possibilities and for the host CA 2048, 4096,
>> 8192 and also 16348 bit. The configured keylength for the host CA was
>> also used for the control channel.
> 
> Is it even possible to use arbitrary key lengths with OpenVPN?

Yes i have added some more keylenghts which should be in a current spectrum of a possible  min. max. usage. Little example for between values of 4096 and 8192 --> https://wiki.strongswan.org/projects/1/wiki/PublicKeySpeed but there is shurley more.

> 
> 16k is really really long.

Yes it´s a lot, nevertheless i tried currently to find out the thresholds of RSA generation to get some more knowledge behind the whole X509 generation over IPFires web interface. By searching a little around, i discovered that 32768 bit supposed to be the RSA max. keylenght (shurley too much for IPFire). I try that currently (just for interessting purposes).
16k keylenght is a kind of big but i think in conjunction with a 8192 bit host CA keylenght (control channel encryption) but also an 1024 bit DH prime (the upload check for 4096 + can also be modified without problems), the measured time of ~ 45 minutes are not that much as i expected.

> 
>> The Root CA generation took 31 minutes for a 16348 bit keylength, the
>> Host CA 12 minutes for 8192 bit and a 1024 bit DH-parameter needed 2
>> minutes which is in summary ~ 45 minutes. The generation time differs
>> also on every generation.
>> The creation of a new client PKCS#12 package for 8192 bit needed  3
>> minutes.
>> The key exchange with a Control Channel: TLSv1.2, cipher TLSv1/SSLv3
>> DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA needed 10 sec.
> 
> This sounds increadible fast to me. We had devices on which that took
> way longer.

I think so. One time waiting while the first generation of the whole PKI but all measured values after that (client PKCS#12 generation, connection build up, keyexchange) are barley recognizable related to IPFires current setup which aren´t in proportion to the security purposes in my opinion.

> 
> I have recently seen a talk about using /dev/urandom instead. This is
> probably worth a watch: https://www.youtube.com/watch?v=Q8JAlZ-HJQI

Nice talk. I think OpenSSL uses in any case /dev/urandom, only exception which uses /dev/random i have currently in mind is GPG, but may my picture is wrongregarding that topic ?

> 
>> 
>> All tests was made with a JNC9C --> http://fireinfo.ipfire.org/profil
>> e/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or PRNG
>> .
>> 
>> If someone is interested in a ovpnmain.cgi diff and/or more testing
>> results let it me know.
> 
> You can post it as a patch on here and add a note that this is for
> testing only and not (yet?) intended to be merged.


 All right,

This patch is for testing purposes/results only, please do not merge that. May there are new ideas and corrections for that?

It includes two new menus for configuring the keysize of the root CA and the host CA. The configured keylenght for the host CA will automatically investigated from the serverkey.pem and will be set in 'newkey' section while PKCS#12 client generation and will be used for the control channel enrcyption too. Have added also some more keylenghts which should only support some more testing results and a look behind the curtain. Have find also some bugs which i may can fix in the next time. One directly regarding to this topic is --> If a X509 and already generated clients will be removed, a 'malformed header from script. Bad header=Wrapper for OpenVPN ipfire-2.2: ovpnmain.cgi,' appears with a 'internal server error' subsequently where a reload of the page brings back the ovpnmain.cgi.
Have added also the '-rand' option which is possibly redundant since OpenSSL uses anyway /dev/urandom (tests can be made with an unpatched cgi with strace and the appropriate OpenSSL commands) .

I wanted also to suggest that OpenVPN-2.4.x will deliver EC crypto which might be also interessting to configure it via the WUI ?!

It may also be possible to deliver a flip menu for the Hashes but this should be for a first test o.k. i think.





Greetings,

Erik
  

Hello,

On Tue, 2016-01-05 at 16:49 +0100, ue wrote:
> Hi Michael,
> have changed now the topic cause "Mark recommended
> ciphers/algorithms" do not match fully this topic. 
> 
> Am 04.01.2016 um 17:36 schrieb Michael Tremer:
> 
> > Hi,
> > 
> > On Sat, 2016-01-02 at 14:03 +0100, ue wrote:
> > > Hi all,
> > > and for the first a good new year to you all.
> > > > I agree, that it is desirable to use longer keys. However, I am
> > > > not
> > > > sure if it is a good idea to go all the way for 4096 bit and
> > > > not
> > > > only
> > > > for e.g. 2048 bit. Why not 8192 even?
> > > > I would like to read some justification for the values that are
> > > > picked.
> > > > Furthermore, I think that we the upper bound should be
> > > > something
> > > > that
> > > > the average IPFire box is able to handle.
> > > tried that now with OpenVPN whereby i added a flip menu in the
> > > 'Generate Root/Host Certificate' section as it is for the Diffie
> > > -Hellman parameter so the keylengths aren´t hardcoded anymore and
> > > can
> > > be configured by the user. Added for the root CA 4096, 8192 and
> > > 16348
> > > tit lengths selection possibilities and for the host CA 2048,
> > > 4096,
> > > 8192 and also 16348 bit. The configured keylength for the host CA
> > > was
> > > also used for the control channel.
> > Is it even possible to use arbitrary key lengths with OpenVPN?
> Yes i have added some more keylenghts which should be in a current
> spectrum of a possible  min. max. usage. Little example for between
> values of 4096 and 8192 --> 
> https://wiki.strongswan.org/projects/1/wiki/PublicKeySpeed but there
> is shurley more.
> 

I am in favour of accepting such a patch. Maybe Timmothy would like to
add options for ECDSA as well?

> > 
> > 16k is really really long.
> Yes it´s a lot, nevertheless i tried currently to find out the
> thresholds of RSA generation to get some more knowledge behind the
> whole X509 generation over IPFires web interface. By searching a
> little around, i discovered that 32768 bit supposed to be the RSA
> max. keylenght (shurley too much for IPFire). I try that currently
> (just for interessting purposes).
> 16k keylenght is a kind of big but i think in conjunction with a 8192
> bit host CA keylenght (control channel encryption) but also an 1024
> bit DH prime (the upload check for 4096 + can also be modified
> without problems), the measured time of ~ 45 minutes are not that
> much as i expected.

I *think* that these lengths could cause some trouble out there. I do
not have any data to proof this though.

> 
> > 
> > > The Root CA generation took 31 minutes for a 16348 bit keylength,
> > > the
> > > Host CA 12 minutes for 8192 bit and a 1024 bit DH-parameter
> > > needed 2
> > > minutes which is in summary ~ 45 minutes. The generation time
> > > differs
> > > also on every generation.
> > > The creation of a new client PKCS#12 package for 8192 bit needed 
> > >  3
> > > minutes.
> > > The key exchange with a Control Channel: TLSv1.2, cipher
> > > TLSv1/SSLv3
> > > DHE-RSA-AES256-GCM-SHA384, 8192 bit RSA needed 10 sec.
> > This sounds increadible fast to me. We had devices on which that
> > took
> > way longer.
> I think so. One time waiting while the first generation of the whole
> PKI but all measured values after that (client PKCS#12 generation,
> connection build up, keyexchange) are barley recognizable related to
> IPFires current setup which aren´t in proportion to the security
> purposes in my opinion.
> 
> > 
> > I have recently seen a talk about using /dev/urandom instead. This
> > is
> > probably worth a watch: https://www.youtube.com/watch?v=Q8JAlZ-HJQI
> Nice talk. I think OpenSSL uses in any case /dev/urandom, only
> exception which uses /dev/random i have currently in mind is GPG, but
> may my picture is wrongregarding that topic ?

So I just checked and openssl uses /dev/urandom:

[root@ipfire ~]# openssl version
OpenSSL 1.0.2d 9 Jul 2015
[root@ipfire ~]# openssl rand -base64 1024
qJFAmwO1rT44j0xZ155wbeySVBERbK3Wsu6d9cCuv87ZbJNv2MleTmoRxvRyUKdF
pxNSKYcayPhKP3m0cMuxtgY19YsSCR7Hd2Iv0B7sstBPkMRQBawrAL0DrC7sb+E6
WxW4os0WsqkK/d2VHXXEpjKvLoPKn0QXSnjIhG12LlqQL2PbvUrllz87XAPsYum7
2i13JnSdiCbLtaVWEQWqQcaAJha6nFIBk3llyDDGPlyk+6yMk5Q6UbgdfG2gam+F

You can use strace to see that yourself.

> 
> > 
> > > All tests was made with a JNC9C --> 
> > > http://fireinfo.ipfire.org/profil
> > > e/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or
> > > PRNG
> > > .
> > > If someone is interested in a ovpnmain.cgi diff and/or more
> > > testing
> > > results let it me know.
> > You can post it as a patch on here and add a note that this is for
> > testing only and not (yet?) intended to be merged.
> 
>  All right,
> 
> This patch is for testing purposes/results only, please do not merge
> that. May there are new ideas and corrections for that?
> 
> It includes two new menus for configuring the keysize of the root CA
> and the host CA. The configured keylenght for the host CA will
> automatically investigated from the serverkey.pem and will be set in
> 'newkey' section while PKCS#12 client generation and will be used for
> the control channel enrcyption too. Have added also some more
> keylenghts which should only support some more testing results and a
> look behind the curtain. Have find also some bugs which i may can fix
> in the next time. One directly regarding to this topic is --> If a
> X509 and already generated clients will be removed, a 'malformed
> header from script. Bad header=Wrapper for OpenVPN ipfire-2.2:
> ovpnmain.cgi,' appears with a 'internal server error' subsequently
> where a reload of the page brings back the ovpnmain.cgi.
> Have added also the '-rand' option which is possibly redundant since
> OpenSSL uses anyway /dev/urandom (tests can be made with an unpatched
> cgi with strace and the appropriate OpenSSL commands) .
> 
> I wanted also to suggest that OpenVPN-2.4.x will deliver EC crypto
> which might be also interessting to configure it via the WUI ?!

Please make sure to give this a good test. I think it is probably nice
to have this, but it will cause trouble with most clients. Especially
outdated ones.

> It may also be possible to deliver a flip menu for the Hashes but
> this should be for a first test o.k. i think.
> 
> 
> --- ovpnmain.cgi.orig	2015-12-29 14:20:27.008228796 +0100
> +++ ovpnmain.cgi	2016-01-05 12:48:09.014389131 +0100
> @@ -1842,7 +1842,9 @@
>  	    }
>  	} else {	# child
>  	    unless (exec ('/usr/bin/openssl', 'req', '-x509', '
> -nodes',
> -			'-days', '999999', '-newkey', 'rsa:4096', '
> -sha512',
> +			'-days', '999999',
> +			'-newkey', "$cgiparams{'ROOTKEYLENGHT'}", '
> -sha512',
> +			'-rand', '/dev/urandom',

I think the -rand parameter can be removed.

>  			'-keyout',
> "${General::swroot}/ovpn/ca/cakey.pem",
>  			'-out',
> "${General::swroot}/ovpn/ca/cacert.pem",
>  			'
> -config',"${General::swroot}/ovpn/openssl/ovpn.cnf")) {
> @@ -1873,7 +1875,8 @@
>  	    }
>  	} else {	# child
>  	    unless (exec ('/usr/bin/openssl', 'req', '-nodes',
> -			'-newkey', 'rsa:2048',
> +			'-newkey', "$cgiparams{'HOSTKEYLENGHT'}",
> +			'-rand', '/dev/urandom',
>  			'-keyout',
> "${General::swroot}/ovpn/certs/serverkey.pem",
>  			'-out',
> "${General::swroot}/ovpn/certs/serverreq.pem",
>  			'-extensions', 'server',
> @@ -1993,6 +1996,34 @@
>  	}
>  	print <<END;
>  	    </select></td>
> +	<tr><td>&nbsp;</td>
> +	<tr><td class='base'>$Lang::tr{'ovpn keylenghtroot'}:</td>
> +		<td class='base'><select name='ROOTKEYLENGHT'>
> +				<option value='4096'
> $selected{'ROOTKEYLENGHT'}{'rsa:4096'}>4096 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='6144'
> $selected{'ROOTKEYLENGHT'}{'rsa:6144'}>6144 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='8192'
> $selected{'HOSTKEYLENGHT'}{'rsa:8192'}>8192 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='12288'
> $selected{'HOSTKEYLENGHT'}{'rsa:12288'}>12288 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='16384'
> $selected{'ROOTKEYLENGHT'}{'rsa:16384'}>16384 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='32768'
> $selected{'ROOTKEYLENGHT'}{'rsa:32768'}>32768 $Lang::tr{'bit'}
> RSA</option>
> +			</select>
> +	</tr>
> +
> +	<tr><td>&nbsp;</td>
> +
> +	<tr><td class='base'>$Lang::tr{'ovpn keylenghthost'}:</td>
> +		<td class='base'>
> +			<select name='HOSTKEYLENGHT'>
> +				<option value='2048'
> $selected{'HOSTKEYLENGHT'}{'rsa:2048'}>2048 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='4096'
> $selected{'HOSTKEYLENGHT'}{'rsa:4096'}>4096 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='6144'
> $selected{'HOSTKEYLENGHT'}{'rsa:6144'}>6144 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='8192'
> $selected{'HOSTKEYLENGHT'}{'rsa:8192'}>8192 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='12288'
> $selected{'HOSTKEYLENGHT'}{'rsa:12288'}>12288 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='16384'
> $selected{'HOSTKEYLENGHT'}{'rsa:16384'}>16384 $Lang::tr{'bit'}
> RSA</option>
> +				<option value='32768'
> $selected{'ROOTKEYLENGHT'}{'rsa:32768'}>32768 $Lang::tr{'bit'}
> RSA</option>
> +			</select>
> +		</td>
> +	</tr>
> +	<tr><td>&nbsp;</td></select></td>
>  	<tr><td class='base'>$Lang::tr{'ovpn dh'}:</td>
>  		<td class='base'><select name='DHLENGHT'>
>  				<option value='1024'
> $selected{'DHLENGHT'}{'1024'}>1024 $Lang::tr{'bit'}</option>
> @@ -2004,6 +2035,7 @@
>  	</tr>
>  
>  	<tr><td>&nbsp;</td>
> +	<tr><td>&nbsp;</td>
>  	    <td><input type='submit' name='ACTION'
> value='$Lang::tr{'generate root/host certificates'}' /></td>
>  	    <td>&nbsp;</td><td>&nbsp;</td></tr> 
>  	<tr><td class='base' colspan='4' align='left'>
> @@ -4202,6 +4234,10 @@
>  	    (my $ou = $cgiparams{'CERT_OU'}) =~ s/^\s*$/\./;
>  	    (my $city = $cgiparams{'CERT_CITY'}) =~ s/^\s*$/\./;
>  	    (my $state = $cgiparams{'CERT_STATE'}) =~ s/^\s*$/\./;
> +	    # Investigate host serverkey lenght
> +	    my $keylenght = `/usr/bin/openssl rsa -text -noout -in
> "${General::swroot}/ovpn/certs/serverkey.pem"`;
> +		$keylenght =~ m/(\d+)/;
> +		$keylenght = $1;

There is a typo in "keylenght".

>  
>  	    # Create the Host certificate request client
>  	    my $pid = open(OPENSSL, "|-");
> @@ -4219,13 +4255,14 @@
>  		close (OPENSSL);
>  		if ($?) {
>  		    $errormessage = "$Lang::tr{'openssl produced an
> error'}: $?";
> -		    unlink
> ("${General::swroot}ovpn/certs/$cgiparams{'NAME'}key.pem");
> -		    unlink
> ("${General::swroot}ovpn/certs/$cgiparams{'NAME'}req.pem");
> +		    unlink
> ("${General::swroot}/ovpn/certs/$cgiparams{'NAME'}key.pem");
> +		    unlink
> ("${General::swroot}/ovpn/certs/$cgiparams{'NAME'}req.pem");
>  		    goto VPNCONF_ERROR;
>  		}
>  	    } else {	# child
>  		unless (exec ('/usr/bin/openssl', 'req', '-nodes',
> -			'-newkey', 'rsa:2048',
> +			'-newkey', "rsa:$keylenght",
> +			'-rand', '/dev/urandom',
>  			'-keyout',
> "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}key.pem",
>  			'-out',
> "${General::swroot}/ovpn/certs/$cgiparams{'NAME'}req.pem",
>  			'
> -config',"${General::swroot}/ovpn/openssl/ovpn.cnf")) {
> 
> 
> 
> Greetings,
> 
> Erik
> 

-Michael
>