Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 20748 bytes --]

Hi,

wow, long email...

On Sun, 2018-01-14 at 11:59 +0100, ummeegge wrote:
> 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 ?

None, I just haven't tried to build it because you are the maintainer of OpenVPN
:)

If it just builds, please send a patch for just that package.

You can also send an extra patch that adds LZ4.

> > > 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.

I am not using this either, but I can test it. I guess it should be fine.

> > > 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/7460cead169ea919f66a
> > > d706
> > > 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...

Not sure if people are using MySQL too much on IPFire. Hopefully they don't do
that for any performance-critical applications.

I guess the only other useful application for LZ4 would be backups.

> 
> > 
> > > The most important are:
> > > 1) 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/QuarkslabAndCryptographyEngineerAud
> its --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3"
> you can find there also OpenVPNs statements causing this topic.

AFAIK we don't use any of those authentication methods. Or are we?

> > 
> > > 2) 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.or
> g/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 !!!

OpenSSL choses to activate these things automatically when they are available.
There is no need to do anything. Even apache and things like that use them
because they use OpenSSL.

However, that is not an HWRNG. That is just a random number generator like
RDRAND on Intel processors.

AESNI is not called a HWRNG.

I do not see a reason why people would want to disable this. They work and if
someone wants to disable them (because they are malfunctioning), that should be
possible system-wide.

We should not have too many switches. It makes the web UI complicated.

> 
> > 
> > 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

Yes, that is fine and I wouldn't have expected anything else since the client
side needs to support the negotiation, too.

> 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.

So we need to add the ncp-ciphers. If we didn't we would have some sort of
functionality just like OpenVPN 2.3. Which is fine with me for the moment, too.

> > > 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 thought that was tested already. However, the OpenSSL is branch is somewhat
unstable and won't be released with the next core update. So if you send it now,
it wouldn't break anyone's system.

> 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/openvp
> n/commit/160504a2955c4478cd2c0323452929e07016a336 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

The CRL has a valid before and after date? In that case we just need to
regenerate it.

If the CA or some client certificates have expired, this is what we would
expect, isn't it?

> 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=84
> 9909 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=e623c9c726b7d0f5fb14b9659b4a6625&start=45#p112737 . In that case we would need a script which checks periodically when a CRL update needs to be done. 

Not a fan of cron jobs for things like this, but I guess we have no other
choice. This looks good.

> If you have better ideas for this or another script it might be really
> helpful.

No not really. We have to make sure that the CRL is up to date even when the
system is not being rebooted in a while. So it has to be checked regularly which
requires a cron job.

Setting the expiry date to infinity would slightly ruin the idea of a CRL.

> > > 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 ?

It is here https://patchwork.ipfire.org/patch/1594/

-Michael

> 
> 
> Am 13.01.2018 um 13:30 schrieb Jeffrey Walton:
> 
> > On Wed, Jan 10, 2018 at 12:08 PM, Michael Tremer
> > <michael.tremer(a)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(a)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(a)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
> 
> 
> > 
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]