From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Selection menu for OpenVPN CA keylenght Date: Wed, 06 Jan 2016 19:55:25 +0000 Message-ID: <1452110125.31655.309.camel@ipfire.org> In-Reply-To: <3120307A-D4AF-4A71-9C83-6B100B8BB00A@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1166555530075591529==" List-Id: --===============1166555530075591529== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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(a)ipfire ~]# openssl version OpenSSL 1.0.2d 9 Jul 2015 [root(a)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 < > +   > + $Lang::tr{'ovpn keylenghtroot'}: > + > + > + > +   > + > + $Lang::tr{'ovpn keylenghthost'}: > + > + > + > + > +   > $Lang::tr{'ovpn dh'}: > value='$Lang::tr{'generate root/host certificates'}' /> >    > > @@ -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 > --===============1166555530075591529== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEKCmlRSWNCQUFC Q2dBR0JRSldqWEV0QUFvSkVJQjU4UDl2a0FrSFhXWVAvMlJZbXdRT2dFM3B6QWhxR1dhTXdad2YK bnQ5eUdrOFBxYVdmV21mOGtiRkRGS1lNTGdOZFRjNGVGV2I0SU45VEQ2WCtXRFh5MWRXOERpRkZi dTB5NjRHeQpIak9FTTJnTDBjTEc4WVN5NjVRemRHSFE4d0xnamt5M0V4Y0dtZTJpNm9iSnZMbHpj Y0ZJUWZmeGI2UGk1cTZQClpOcTR3NG1YdWtwaGlkRE1xWHZ1ZUdFdVh5NWNpYlZTdDREK3RJM1ZG WWlaWnhQUHhSMzJLNFAvMFQ5U1N3TEkKUDRtMFphMHFNUVRVYlUreGpkeFU5eEJENmJ4eEFWSEVC VkZja2NjOWFlWVVTWlhvTnNjUGpPR21YNnEvT2hCSgoyVlVPT1kvM2hEVmI2QW8wVGxZbC9mL216 VHpnOG9wMGZnK2J1Tk1CMmZGbU0rMUhOL0MyWDJ2YkhuVmk1TEtUCmJPdk5OS0RBdkZ4b3ZYYXJo NmE4SHYvMUwwTFQ5d3VVQVgreG1GNVR3YmlCc3NNQUkzdi9SQ0NyR2hpOVA1eWkKUFo0QW44dkRE R2gvYnJNbElCcHAyOU1OWnk0NFFPU2RqWDlWanllVTYxSmszWSttSm1hcmhVcVp4U05VUWljQgpJ S2lmYUNxQWRYS0xOYi9BQzNYMlZzeGVvcGgwUDdCbVEwcThHemg2dlhlU0hoOWRnYjg0eUxSNmhY MGhiZUttCnlBclA3eGhIRkVZRnd3QWJRdzVodjlOdUx1aTRoeTIzTVpxbm5DN3pZd1BUUnhSSTlS aW5GTWhpanhZeWI4WWQKbUdRUjJLVU5sVkhuSEZvYTQ1WjkzR1krNmVnQ0tzbG5LcXRDNm11TWFM VTFiTjVqQ0FPNnMzb3oyd1VRTmRKcgoyYmpMOCtlRjlVdEVZSlppVTI5Nwo9MmNJQwotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============1166555530075591529==--