Hi Michael,
Hmm, okay. I have no idea how I forgot about all these things.
Please pull the branch again and everything except openvpn will build now.
have pulled it again and all packages also OpenVPN has been build successfully except Bacula´s ROOTFILE had some problems while packaging but the installation 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. Press 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.org/community/releases/openvpn-2.4.4.tar.xz without any further modifications of 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. At least in my environment Asterisk has build with OpenSSL-1.1.0g, but there was one more dependency (jansson) needed. Changes can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire- 2.x.git;a=commit;h=2d940ba2187a53cf52d2191a36c3897636b9600c .
I actually updated that myself before you sent your email, but please review my changes.
Looks here good either but since i do not use Asterisk it is problematic to give 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´t start without some changes in ovpnmain.cgi. In here --> https://github.com/ummeegge/OpenVPN_30.08.2017/commit/7460cead169ea919f66ad7... 8e764fef37bf8f8b#diff-2011d5d928fd214cacb83844729c65cc a little more then needed has been done but it describes very closely the needed changes.
Hmm, I am not sure if we will have a lot of client support. But it should be 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 compression lib...
The most important are:
- The script-security flag 'system' can not be used anymore the server won´t
start if this isn´t fixed.
Where do we use that?
It can not be used over the WUI only since there is the need to add additional directives over the server.conf which calls external programs or scripts, but it can be consistently used via the "Additional configuration" (client{server}.conf.local under /var/ipfire/ovpn/scripts/ ). OpenVPN have dropped the 'system' flag due to the security implications with shell expansions when executing scripts via the system() call .
Another point in here is IPFire uses currently the level 3 of --script-security for the RW " 3 -- Allow passwords to be passed to scripts via environmental variables (potentially unsafe)" which is important for some kinds of authentication methods but which has also been marked as unsafe and have also be again pointed out while the QuarkLabs and Cryptography Engineering LCC audit --> https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEngineerA... --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3" you can find there also OpenVPNs statements causing this topic.
- OpenVPN have added an automatic cipher negotiation with 2.4.x which should
be manageable in my opinion. If someone needs to have other ciphers then the strongest defaults e.g. for the usage of HWRNG this option should be switchable with an OFF/ON checkbox.
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 negotiation 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 OpenVPN negotiates for example AES-256-GCM with the client cause the appropriate OpenSSL lib do supports it some potential existing accelerators like e.g. the "AMD Geode LX Security Block" won´t be used. If i get that right this might be one case where the automatic cipher negotiation should be deactivated ? Another one might be setups with vast amounts of clients where possible less computing power with smaller key lengths is wanted. That´s why i disabled the cipher negotiation per default and if wanted one click via checkbox can be used to enable it for all clients whereby the CCD option can be used to deactivate the cipher negotiation for specific clients. Not sure if this is the best practice and it might be great if someone can give me feedback for this since this has not been debated since now !!!
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 OpenVPN uses the already configured and in server and client configuration defined--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 --> Tunnelblick: OS X 10.7.5; Tunnelblick 3.5.17 (build 4270.4900) where OpenVPN used an "peer info" function to investigate the client version -->
Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info: IV_VER=2.3.18 Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info: IV_PLAT=mac Nov 30 17:53:30 ipfire-prime openvpnserver[1929]: 192.168.1.2:57884 peer info: IV_PROTO=2 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 Channel: 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 the 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 left Camellia out the --ncp-ciphers list (which is equal to OpenVPN manpage).
Please send any proposed changes as patches to the list.
Shouldn´t i test OpenVPN with the new OpenSSL before pushing this, if the iso is working i can make an installation in my testing environment to break 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/openvpn/commit/160504a2955c4478cd2c0323452929e070... which is a problem cause the CRL will now be checked in the "validBefore" and "validAfter" fields. Since "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=0, error=CRL has expired: C=US, O=Tatoine, CN=LGG3 Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 OpenSSL: error: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: BIO read tls_read_plaintext error Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: TLS object -> incoming plaintext read error Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS Error: TLS handshake failed Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 Fatal TLS error (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.ipfire.org/viewtopic.php?f=50&t=18067&start=30#p112529 located, the Debian discussion --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849909 and OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849909 . 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 develop a first idea for an CRL updater, please check this in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=18067&sid=e623c9c726b7... . In that case we would need a script which checks periodically when a CRL update needs to be done.
If you have better ideas for this or another script it might be really helpful.
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) ?
Certainly GCM and all the other ones that include MAC.
OK, will do it like this with a second patch.
Peter has proposed a patch recently with improved crypto, please work together with him.
We can do this, no problem. @Peter would you write me to ummeegge at ipfire.org ?
Am 13.01.2018 um 13:30 schrieb Jeffrey Walton:
On Wed, Jan 10, 2018 at 12:08 PM, Michael Tremer michael.tremer@ipfire.org 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.
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] [MH/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. sales@openvpn.net Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=no enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=no enable_werror=no enable_win32_dll=yes enable_x509_alt_username=no with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no
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 P2MP 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 P2MP 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=1 Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=2
...
Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=1499 Sun Jan 14 08:18:15 2018 TESTING ENCRYPT/DECRYPT of packet length=1500 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): Enter same passphrase again: 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@ummeegge The key's randomart image is: +---[RSA 2048]----+ |oE..o.==o | | =.=.+.+o. | |o.@ +..=+ . | |oO * o.o+ o o | |= . . .S = 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 not 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 (technical and design ones) open and very few people helped out in testing all that which hopefully will change before delivering the code to optimize the design or a release to check the technical points.
Some news from here and a nice sunday to all.
Greetings,
Erik