From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Upgrading to OpenSSL 1.1.0 Date: Sun, 14 Jan 2018 11:59:01 +0100 Message-ID: <6BE3D5D6-CC5A-4B2A-A329-E2300B8DCCE6@ipfire.org> In-Reply-To: <1515845877.3647.61.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4291760749162359750==" List-Id: --===============4291760749162359750== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, > Hmm, okay. I have no idea how I forgot about all these things. >=20 > Please pull the branch again and everything except openvpn will build now. have pulled it again and all packages also OpenVPN has been build successfull= y except Bacula=C2=B4s ROOTFILE had some problems while packaging but the ins= tallation process of the .iso via VM do not works and stops like before with = a "Unable to install language cache." and ends up in a "Setup has failed. Pre= ss OK to reboot." . So i could make only rudimentary checks with OpenVPN the = new OpenSSL in chroot (have listed them at the bottom). I have had no problems building OpenVPN-2.4.4 --> https://swupdate.openvpn.or= g/community/releases/openvpn-2.4.4.tar.xz without any further modifications o= f the LFS (except the md5 and version number), there was also no need for the= LZ4 lib ? What problems appears for you ? >> I think an update of Asterisk and his components should work also with the= new >> OpenSSL.=20 >> At least in my environment Asterisk has build with OpenSSL-1.1.0g, but the= re >> was one more dependency (jansson) needed. Changes can be found in here --> >> https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire- >> 2.x.git;a=3Dcommit;h=3D2d940ba2187a53cf52d2191a36c3897636b9600c . >=20 > I actually updated that myself before you sent your email, but please revie= w my > changes. Looks here good either but since i do not use Asterisk it is problematic to g= ive it some testings and appropriate feedback. >> OpenVPN-2.4.4 has build with OpenSSL-1.1.0g have included also the LZ4 >> compression lib but otherwise it builds out of the box but OpenVPN won=C2= =B4t start >> without some changes in ovpnmain.cgi. In here --> >> https://github.com/ummeegge/OpenVPN_30.08.2017/commit/7460cead169ea919f66a= d706 >> 8e764fef37bf8f8b#diff-2011d5d928fd214cacb83844729c65cc a little more then >> needed has been done but it describes very closely the needed changes. >=20 > Hmm, I am not sure if we will have a lot of client support. But it should b= e a > small library so that it wouldn't hurt too much to include it as well. To my current knowledge MySQL (possibly only an updated one) can also use LZ4= may there are more candidates in IPFire which can participate from this comp= ression lib... >=20 >> The most important are: >> 1) The script-security flag 'system' can not be used anymore the server wo= n=C2=B4t >> start if this isn=C2=B4t fixed. >=20 > Where do we use that? It can not be used over the WUI only since there is the need to add additiona= l directives over the server.conf which calls external programs or scripts, b= ut it can be consistently used via the "Additional configuration" (client{ser= ver}.conf.local under /var/ipfire/ovpn/scripts/ ). OpenVPN have dropped the '= system' flag due to the security implications with shell expansions when exec= uting scripts via the system() call . Another point in here is IPFire uses currently the level 3 of --script-securi= ty for the RW " 3 -- Allow passwords to be passed to scripts via environmenta= l variables (potentially unsafe)" which is important for some kinds of authen= tication methods but which has also been marked as unsafe and have also be ag= ain pointed out while the QuarkLabs and Cryptography Engineering LCC audit --= > https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineer= Audits --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3= " you can find there also OpenVPNs statements causing this topic. >=20 >> 2) OpenVPN have added an automatic cipher negotiation with 2.4.x which sho= uld >> be manageable in my opinion. If someone needs to have other ciphers then t= he >> strongest defaults e.g. for the usage of HWRNG this option should be >> switchable with an OFF/ON checkbox.=20 >=20 > Who would want to switch off a HWRNG? OpenVPN should only use entropy from = the > kernel and nothing else. Never directly read from any HWRNGs. The ON/OFF switch should be there to deactivate the automatic cipher negotiat= ion not the HWRNG. As far as i remember some crypto accelerators can only be = used with certain types of encryption e.g. --> https://doc.pfsense.org/index= .php/Are_cryptographic_accelerators_supported . So in my understanding if Ope= nVPN negotiates for example AES-256-GCM with the client cause the appropriate= OpenSSL lib do supports it some potential existing accelerators like e.g. th= e "AMD Geode LX Security Block" won=C2=B4t be used. If i get that right this = might be one case where the automatic cipher negotiation should be deactivate= d ? Another one might be setups with vast amounts of clients where possible l= ess computing power with smaller key lengths is wanted. That=C2=B4s why i disabled the cipher negotiation per default and if wanted o= ne click via checkbox can be used to enable it for all clients whereby the CC= D option can be used to deactivate the cipher negotiation for specific client= s.=20 Not sure if this is the best practice and it might be great if someone can gi= ve me feedback for this since this has not been debated since now !!! >=20 > And about the negotiation, that would be nice, but does that work with older > clients? The negotiation does not work with clients before 2.4.0 but in that case Open= VPN uses the already configured and in server and client configuration define= d--cipher and --auth directive as a fall back. Have tested this with an older= Tunnelblick client which used OpenVPN-2.3.18 on an old OS X version --> Tunn= elblick: OS X 10.7.5; Tunnelblick 3.5.17 (build 4270.4900) where OpenVPN used= an "peer info" function to investigate the client version -->=20 Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info= : IV_VER=3D2.3.18 Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info= : IV_PLAT=3Dmac Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info= : IV_PROTO=3D2 Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Outgoing = Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Outgoing = Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Incoming = Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Incoming = Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 Control C= hannel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA but the server.conf serves --ncp-ciphers but also --cipher and --auth --> #OpenVPN Server conf daemon openvpnserver writepid /var/run/openvpn.pid #DAN prepare OpenVPN for listening on blue and orange ;local ue.*.org dev tun proto udp port 1194 script-security 3 ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600 client-config-dir /var/ipfire/ovpn/ccd tls-server ca /var/ipfire/ovpn/ca/cacert.pem cert /var/ipfire/ovpn/certs/servercert.pem key /var/ipfire/ovpn/certs/serverkey.pem dh /var/ipfire/ovpn/ca/dh1024.pem server 10.2.17.0 255.255.255.0 tun-mtu 1400 mssfix 0 route 10.1.4.0 255.255.255.252 keepalive 10 60 status-version 1 status /var/run/ovpnserver.log 30 ncp-ciphers AES-256-GCM:AES-256-CBC:CAMELLIA-256-CBC cipher AES-256-CBC auth SHA512 tls-auth /var/ipfire/ovpn/certs/ta.key max-clients 100 tls-verify /usr/lib/openvpn/verify crl-verify /var/ipfire/ovpn/crls/cacrl.pem user nobody group nobody persist-key persist-tun verb 3 so i think this should be no problem. >> I can do this but it might be great if i can make before some tests with t= he >> new OpenSSL lib. Would it be OK for you if i push the first part as in the >> Github example ? Have already changed the language file description and le= ft >> Camellia out the --ncp-ciphers list (which is equal to OpenVPN manpage). >=20 > Please send any proposed changes as patches to the list. Shouldn=C2=B4t i test OpenVPN with the new OpenSSL before pushing this, if th= e iso is working i can make an installation in my testing environment to brea= k down the most important steps ? I forgot also one important point to mention which we discovered really late.= OpenVPN-2.4.x refactors the CRL handling --> https://github.com/OpenVPN/open= vpn/commit/160504a2955c4478cd2c0323452929e07016a336 which is a problem cause = the CRL will now be checked in the "validBefore" and "validAfter" fields. Sin= ce "default_crl_days" are set to 30 days we can run into a problem if the CRL= has been expired. Error message looks like this: Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 VERIFY ERROR:= depth=3D0, error=3DCRL has expired: C=3DUS, O=3DTatoine, CN=3DLGG3 Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 OpenSSL: erro= r:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS_ERROR: BI= O read tls_read_plaintext error Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: TL= S object -> incoming plaintext read error Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: TL= S handshake failed Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 Fatal TLS err= or (check_tls_errors_co), restarting Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 SIGUSR1[soft,= tls-error] received, client-instance restarting A more detailed discussion in the IPFire forum is here --> https://forum.ipfi= re.org/viewtopic.php?f=3D50&t=3D18067&start=3D30#p112529 located, the Debian = discussion --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D849909 and= OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D849909 . An = idea there was to set the "nextUpdate" value in a far future as the CA expiry= date is, we decided in the forum to leave this idea behind and started to de= velop a first idea for an CRL updater, please check this in here --> https://= forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&sid=3De623c9c726b7d0f5fb14b96= 59b4a6625&start=3D45#p112737 . In that case we would need a script which chec= ks periodically when a CRL update needs to be done.=20 If you have better ideas for this or another script it might be really helpfu= l. >> Yes i think so too. Nevertheless i think we should introduce at least the = new >> Galois/Counter Mode (available with 128, 196 and 256 bit) which is somehow= the >> default of the new OpenVPN if possible. Would do this with a second patch >> where it might also be an idea to list all the deprecated ciphers as such >> (via optgroup label) ? >=20 > Certainly GCM and all the other ones that include MAC. OK, will do it like this with a second patch. >=20 > Peter has proposed a patch recently with improved crypto, please work toget= her > with him. We can do this, no problem. @Peter would you write me to ummeegge at ipfire.o= rg ? Am 13.01.2018 um 13:30 schrieb Jeffrey Walton: > On Wed, Jan 10, 2018 at 12:08 PM, Michael Tremer > wrote: >> ... >> So, again for me: What is the status of OpenVPN 2.4 now? I guess that >> should build with OpenSSL 1.1 out of the box. >=20 > I believe OpenSSL 1.1.0 is not supported by a few key packages, like > OpenVPN and OpenSSH. Hi Jeffrey, a fast test in chroot after building process points the following= out. OpenVPN-2.4.4 with OpenSSL-1.1.0g has been build with another: ipfire build chroot (x86_64) root:/$ openvpn --version OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [M= H/PKTINFO] [AEAD] built on Jan 13 2018 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.09 Originally developed by James Yonan Copyright (C) 2002-2017 OpenVPN Technologies, Inc. Compile time defines: enable_async_push=3Dno enable_comp_stub=3Dno enable_cry= pto=3Dyes enable_crypto_ofb_cfb=3Dyes enable_debug=3Dyes enable_def_auth=3Dye= s enable_dlopen=3Dunknown enable_dlopen_self=3Dunknown enable_dlopen_self_sta= tic=3Dunknown enable_fast_install=3Dyes enable_fragment=3Dyes enable_iproute2= =3Dyes enable_libtool_lock=3Dyes enable_lz4=3Dyes enable_lzo=3Dyes enable_man= agement=3Dyes enable_multihome=3Dyes enable_pam_dlopen=3Dno enable_pedantic= =3Dno enable_pf=3Dyes enable_pkcs11=3Dno enable_plugin_auth_pam=3Dyes enable_= plugin_down_root=3Dyes enable_plugins=3Dyes enable_port_share=3Dyes enable_se= linux=3Dno enable_server=3Dyes enable_shared=3Dyes enable_shared_with_static_= runtimes=3Dno enable_small=3Dno enable_static=3Dyes enable_strict=3Dno enable= _strict_options=3Dno enable_systemd=3Dno enable_werror=3Dno enable_win32_dll= =3Dyes enable_x509_alt_username=3Dno with_crypto_library=3Dopenssl with_gnu_l= d=3Dyes with_mem_check=3Dno with_sysroot=3Dno OpenVPN rudimentary crypto test: ipfire build chroot (x86_64) root:/$ openvpn --genkey --secret /tmp/key ipfire build chroot (x86_64) root:/$ ls /tmp secret ipfire build chroot (x86_64) root:/$ time openvpn --test-crypto --secret /tmp= /key --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Sun Jan 14 08:15:35 2018 disabling NCP mode (--ncp-disable) because not in P2= MP client or server mode real 0m11.459s user 0m11.452s sys 0m0.000s ipfire build chroot (x86_64) root:/tmp$ openvpn --test-crypto --secret key --= cipher AES-256-CBC Sun Jan 14 08:18:15 2018 disabling NCP mode (--ncp-disable) because not in P2= MP client or server mode Sun Jan 14 08:18:15 2018 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL= )] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 13 2018 Sun Jan 14 08:18:15 2018 library versions: OpenSSL 1.1.0g 2 Nov 2017, LZO 2.= 09 Sun Jan 14 08:18:15 2018 OpenVPN 2.4.4 x86_64-unknown-linux-gnu [SSL (OpenSSL= )] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 13 2018 Sun Jan 14 08:18:15 2018 Entering OpenVPN crypto self-test mode. Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1 Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D2 ... Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1499 Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=3D1500 Sun Jan 14 08:18:15 2018 OpenVPN crypto self-test mode SUCCEEDED. OpenSSH_7.6p1 with OpenSSL-1.1.0g RSA key generation: ipfire build chroot (x86_64) root:/tmp$ ssh -V OpenSSH_7.6p1, OpenSSL 1.1.0g 2 Nov 2017 ipfire build chroot (x86_64) root:/tmp$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): /tmp/id_rsa Enter passphrase (empty for no passphrase):=20 Enter same passphrase again:=20 Your identification has been saved in /tmp/id_rsa. Your public key has been saved in /tmp/id_rsa.pub. The key fingerprint is: SHA256:jUS0782RoSmu7YQGcKJZh+yhEVP90XpMIN4NQaLJohQ root(a)ummeegge The key's randomart image is: +---[RSA 2048]----+ |oE..o.=3D=3Do | | =3D.=3D.+.+o. | |o.@ +..=3D+ . | |oO * o.o+ o o | |=3D . . .S =3D o | | . o o o . | | o o . o | | . + | | ..o | +----[SHA256]-----+ ipfire build chroot (x86_64) root:/tmp$ cat id_rsa -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,3C054B16BD28E8EA0E4B332AC5097309 jfnNwOglRHJR7sSXmU+7JtxDiuf2N4+B/oaexzXmlE+rTpKPocW1Tj8mxo9Y5mOc UtS24qF3PojMO4u6W7YAK+27RuIUa48bwXLODUk5+DOXblfgnnzgCF3ChT25tZ9x L4yyvvp9Q9JbeaCbEZp4z6bFI7x/Fhb3ISK6bMMg9IjjhjAhd6pQScCl+4bifjF2 I3LO97Me9kQ02rBOSXZqdVXFDbZzQU0mtIvcv2SxwfiijhWolrTp769LDpj0uOc+ BHr3sAEDoxzq2BRUagUXy9yFHRZZl3xwPnm4akQWZnL6buye3H4IcPKEVk+pFY8e hWMXhiVBAGkwSfV7bC2Nr2eAuWdiAM+ai8zXFz8lEBtw0XJDk0mHwadD9u4qUmf6 6TQv1weQkxV4l2OFARM56Aw9IioMP9Q1+UONLM35kPuiQKGHPdRJsTCDEovU5LHK WRLoe3yOKVgM6BrA36YoSefgD8M1DClh4jmNgmx6BRPWwlaW1oDbOZzHi8anGnH+ a03HbL77kIeFxpRkIm7gEC+c/YFTLoIrx8NHbjEid6rhgy0jqSRw2kJhHpzmP7Tj +1a5s/j8l6yQcWbtkndCVMhdp0HVsYx0UMh20ey5z4nB0ZenyxdaAlM8bnBR8tfj Z3E4a+wXVhs+ISwbkdKY6Gny8llimAqCVpJLJgLFNlVTdv6R7cgDFpL8+Y1oCQoz F3TVJLyeuv96hQg5n3C0gab4x0CVv9xaAAhbEW3jwYIY3MXSSsmG8RXVjCaZbotr 3QKkboAV8hoZE3jYkFIt5jeHwFU+BH7FsgK2Chewo5XLehQdFVYGOS2per+/TVap t4/cGfdFOdvMHYcmNk8BqjrSfqnepvFZd8gIgPzJJGkOfa2ni2jI6VCwnXoCrJ3B l3R50NNqNYyjq4q1vacYcJSGsWkGLSBJekKCn+aE17fZfme64InvE3raHdGWI6Og hk3HTBw0JVZBVZjlkrtbqZjeU7VjaBl6KhqjaxIncgQbfgHfNVIk3qQkjuaf1bOQ igiBDdixZrVnWaTR6aQCcfM5YX/fEqLa/EzBlA7j3YoHPgEvvIcRHx/iq5fGiV15 4+nlTklv6Yj+7LCr7P3UwI16Irkp7S6YN3+tpUbnglZbRgxoUV3Q0bRNbVDHAEC2 9Wlu0o7Pw1n9I0suoQxzMrZa/4Ia03Cir0H805/KFksI+YbMem9bkOBWeEAJVJWE qbx9uqNznz/V2sdb32scxXR7IvlJ77jk+BpZub80icxSn+JydLDP4D7gFXkm2aeT bcUR4/KdGImZGeD3SRfIY7TiQ92HIFqGzNpDSCmVOtFhgcLfalzEXtZ59ohUzADR KCCueKsgM5/3LrsLHs6wyBkeUlbEU00mFCobHq7xzjs9dc8WVV5BELw3KlKoYlwX yCEqm82ysukgQaTL1Exo7EJBIz/IOh0IYvN1JfI/Cn0bCz67CqGXflhRENm8JOuo d0lWAIuGcwHId8XcevPrX3crsz90cpAxCEBTzc0sYZloosOeOeoGI+60TWh+ERVV WShv08jUC2LrFoG/UvKW+hz1xkL2k/vjU4pwhZ0ueXQR/WeRbkb/TCCWtZlfKkTd -----END RSA PRIVATE KEY----- which looks not that bad but again this are only really fast overviews and no= t represantative ones. All in all my feeling for this update is also without the new and not tested = OpenSSL currently somehow not good since there are elementary questions (tech= nical and design ones) open and very few people helped out in testing all tha= t which hopefully will change before delivering the code to optimize the desi= gn or a release to check the technical points. Some news from here and a nice sunday to all. Greetings, Erik >=20 --===============4291760749162359750==--