From mboxrd@z Thu Jan 1 00:00:00 1970 From: ue To: development@lists.ipfire.org Subject: Re: Selection menu for OpenVPN CA keylenght Date: Tue, 05 Jan 2016 17:25:27 +0100 Message-ID: <22EE983C-2D36-4E38-B2B9-87C52FF7B609@ipfire.org> In-Reply-To: <3120307A-D4AF-4A71-9C83-6B100B8BB00A@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8511592724899501251==" List-Id: --===============8511592724899501251== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable EDIT: The language files for DE and EN looks like this, de.pl: --- de.pl.orig 2015-12-29 07:36:00.703878690 +0100 +++ de.pl 2016-01-05 17:17:56.097055275 +0100 @@ -1753,6 +1753,8 @@ 'ovpn generating the root and host certificates' =3D> 'Die Erzeugung der Roo= t- und Host-Zertifikate kann lange Zeit dauern.', 'ovpn ha' =3D> 'Hash-Algorithmus', 'ovpn hmac' =3D> 'HMAC-Optionen', +'ovpn keylenghthost' =3D> 'Host CA Schl=C3=BCssell=C3=A4nge', +'ovpn keylenghtroot' =3D> 'Root CA Schl=C3=BCssell=C3=A4nge', 'ovpn log' =3D> 'OVPN-Log', 'ovpn mgmt in root range' =3D> 'Ein Port von 1024 oder h=C3=B6her ist erford= erlich.', 'ovpn mtu-disc' =3D> 'Path MTU Discovery', en.pl like this: --- en.pl.orig 2015-12-29 07:36:07.546247973 +0100 +++ en.pl 2016-01-05 17:18:28.312516302 +0100 @@ -1786,6 +1786,8 @@ 'ovpn ha' =3D> 'Hash algorithm', 'ovpn hmac' =3D> 'HMAC options', 'ovpn log' =3D> 'OVPN-Log', +'ovpn keylenghthost' =3D> 'Host CA keylenght', +'ovpn keylenghtroot' =3D> 'Root CA keylenght', 'ovpn mgmt in root range' =3D> 'A port number of 1024 or higher is required.= ', 'ovpn mtu-disc' =3D> 'Path MTU Discovery', 'ovpn mtu-disc and mtu not 1500' =3D> 'Path MTU Discovery requires a MTU of = 1500.', Please do not forget to execute a=20 perl -e "require '/var/ipfire/lang.pl'; &Lang::BuildCacheLang" or similar ;-) Greetings, Erik Am 05.01.2016 um 16:49 schrieb ue: > Hi Michael, > have changed now the topic cause "Mark recommended ciphers/algorithms" do n= ot match fully this topic.=20 >=20 > Am 04.01.2016 um 17:36 schrieb Michael Tremer: >=20 >> Hi, >>=20 >> On Sat, 2016-01-02 at 14:03 +0100, ue wrote: >>> Hi all, >>> and for the first a good new year to you all. >>>>=20 >>>> 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? >>>>=20 >>>> I would like to read some justification for the values that are >>>> picked. >>>>=20 >>>> Furthermore, I think that we the upper bound should be something >>>> that >>>> the average IPFire box is able to handle. >>>=20 >>>=20 >>> 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=C2=B4t 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. >>=20 >> Is it even possible to use arbitrary key lengths with OpenVPN? >=20 > 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 an= d 8192 --> https://wiki.strongswan.org/projects/1/wiki/PublicKeySpeed but the= re is shurley more. >=20 >>=20 >> 16k is really really long. >=20 > Yes it=C2=B4s a lot, nevertheless i tried currently to find out the thresho= lds of RSA generation to get some more knowledge behind the whole X509 genera= tion over IPFires web interface. By searching a little around, i discovered t= hat 32768 bit supposed to be the RSA max. keylenght (shurley too much for IPF= ire). I try that currently (just for interessting purposes). > 16k keylenght is a kind of big but i think in conjunction with a 8192 bit h= ost CA keylenght (control channel encryption) but also an 1024 bit DH prime (= the upload check for 4096 + can also be modified without problems), the measu= red time of ~ 45 minutes are not that much as i expected. >=20 >>=20 >>> 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. >>=20 >> This sounds increadible fast to me. We had devices on which that took >> way longer. >=20 > I think so. One time waiting while the first generation of the whole PKI bu= t all measured values after that (client PKCS#12 generation, connection build= up, keyexchange) are barley recognizable related to IPFires current setup wh= ich aren=C2=B4t in proportion to the security purposes in my opinion. >=20 >>=20 >> I have recently seen a talk about using /dev/urandom instead. This is >> probably worth a watch: https://www.youtube.com/watch?v=3DQ8JAlZ-HJQI >=20 > Nice talk. I think OpenSSL uses in any case /dev/urandom, only exception wh= ich uses /dev/random i have currently in mind is GPG, but may my picture is w= rongregarding that topic ? >=20 >>=20 >>>=20 >>> All tests was made with a JNC9C --> http://fireinfo.ipfire.org/profil >>> e/72d11e77621ec66ea75d39e3c9b10025e746e5af and without HWRNG or PRNG >>> . >>>=20 >>> If someone is interested in a ovpnmain.cgi diff and/or more testing >>> results let it me know. >>=20 >> 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. >=20 >=20 > All right, >=20 > This patch is for testing purposes/results only, please do not merge that. = May there are new ideas and corrections for that? >=20 > It includes two new menus for configuring the keysize of the root CA and th= e host CA. The configured keylenght for the host CA will automatically invest= igated 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 tes= ting 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 fro= m script. Bad header=3DWrapper for OpenVPN ipfire-2.2: ovpnmain.cgi,' appears= with a 'internal server error' subsequently where a reload of the page bring= s back the ovpnmain.cgi. > Have added also the '-rand' option which is possibly redundant since OpenSS= L uses anyway /dev/urandom (tests can be made with an unpatched cgi with stra= ce and the appropriate OpenSSL commands) . >=20 > I wanted also to suggest that OpenVPN-2.4.x will deliver EC crypto which mi= ght be also interessting to configure it via the WUI ?! >=20 > It may also be possible to deliver a flip menu for the Hashes but this shou= ld be for a first test o.k. i think. >=20 >=20 > --- 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', > '-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 < > +   > + $Lang::tr{'ovpn keylenghtroot'}: > + > + > + > +   > + > + $Lang::tr{'ovpn keylenghthost'}: > + > + > + > + > +   > $Lang::tr{'ovpn dh'}: > >   =20 > > @@ -4202,6 +4234,10 @@ > (my $ou =3D $cgiparams{'CERT_OU'}) =3D~ s/^\s*$/\./; > (my $city =3D $cgiparams{'CERT_CITY'}) =3D~ s/^\s*$/\./; > (my $state =3D $cgiparams{'CERT_STATE'}) =3D~ s/^\s*$/\./; > + # Investigate host serverkey lenght > + my $keylenght =3D `/usr/bin/openssl rsa -text -noout -in "${General::= swroot}/ovpn/certs/serverkey.pem"`; > + $keylenght =3D~ m/(\d+)/; > + $keylenght =3D $1; > =20 > # Create the Host certificate request client > my $pid =3D open(OPENSSL, "|-"); > @@ -4219,13 +4255,14 @@ > close (OPENSSL); > if ($?) { > $errormessage =3D "$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")) { >=20 >=20 >=20 > Greetings, >=20 > Erik >=20 >=20 --===============8511592724899501251==--