On Nov 30, 2017, at 4:32 AM, dirk.wagner@ipfire.org dirk.wagner@ipfire.org wrote:

I don't understand why the pound addon was dropped without any discussion.

Dirk,

We're having that discussion now. Michael started it by proposing that Pound be dropped, unless someone pitches in to make it build against the updated OpenSSL.

Unfortunately, rather than responding with a helpful link to a potential solution found by Debian, you jumped in with an angry response and followed it up with an announcement that you were no longer supporting an unrelated add on. Maybe they are not, but as a bystander, it sure looked like those two things were related: "Well, if you drop Pound, I'm going to punish you by dropping asterisk."

Let's get back on topic and work together to find a solution that works for everyone.

Tom

Hello,

please try to find another maintainer for asterisk then or send a patch that will drop asterisk, since I am not willing to maintain that package either.

About pound: The patch that you referred to in your email has this line in it:

This will not let the pound as compile against openssl 1.1.

So I have not found anything. The upstream project seems to be very very stale and I could not see any activity there.

In the big picture, I think moving towards OpenSSL 1.1 is more important to have a working Pound. Not just only because we have two more reverse proxies like haproxy and nginx.

I am not against having Pound in the distribution at all. It just is hard to rely on a dead upstream project. If you want to step up as maintainer here, please do so, revert the commit and send an updated version that compiles against OpenSSL 1.1.0.

On top of that I do not think that you have a reason to be angry here.

Best, -Michael

On Thu, 2017-11-30 at 10:39 +0100, dirk.wagner@ipfire.org wrote:

Hi, since several months I don't use the asterisk addon, so I will not maintain the addon anymore .-Dirk

...

Michael Tremer hat am 29. November 2017 um 14:12 geschrieben:

Hello,

I have started working on upgrading the entire distribution to OpenSSL 1.1.0. This is however not the easiest task since many packages are just incompatible with the API changes of OpenSSL.

Therefore, I started this in an own branch, upgraded all sorts of packages that won't build and patched those who could be patched. However, this is still quite chaotic and I need some help of the maintainers of some of the packages to do this for their own packages.

I have already dropped some packages in this process that a) were incompatible with OpenSSL 1.1.0, b) where no patches were available and c) that are not maintained upstream any longer. I also cherry-picked those commits to the current next tree. If someone disagrees, please open a separate discussion.

The packages dropped are: Pound vsftp sslscan

Packages which currently don't build and I could not patch very easily: php asterisk openvpn

I suppose Erik is best to upgrade to openvpn 2.4, Dirk upgrades asterisk and I am quite sure that there is a few people out there who have been working on php. Please raise your hands.

I would like to have the openssl 1.1 branch ready for merge into next at the end of December. Please make sure that any patches have been submitted until then.

Please work on top of this branch:

https://git.ipfire.org/pub/git/people/ms/ipfire-2.x.git openssl-11

https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/o penssl-11

Please also submit improvements of other packages that we can make sure of (i.e. better cipher suites for Apache, etc.)...

Best, -Michael

Hi,

since we have recently had some bigger changes in next, we are now able to pick this up again:

So various addons that are incompatible and not maintained upstream any more have been dropped.

Some other packages that are therefore not needed any more have also been dropped. We are slowly getting a smaller and cleaner distribution.

Erik: I am not sure why those packages won't build for you. I patched a number of them in my branch:

https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/ heads/openssl-11

I will rebase this branch now on where next currently is and build it again. I only expect asterisk to crash then which we need to update. It seems that Dirk has retired as maintainer for asterisk. I can try switching Asterisk to gnutls instead, but generally I would like to keep as much as we can on OpenSSL since that is our primary library.

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.

Would you be able to submit patches so that it builds already? Any changes to the CGI files to add new ciphers can and should be a second patch.

I am not sure if we should expect any problems with changed configuration parameter where we need to migrate configuration files. We are already using the new parameters where possible. So is there any other work left to do?

On Thu, 2017-12-07 at 12:21 +0100, ummeegge wrote:

Hi all, regarding a potential help for building PHP and Asterisk (linked wget to gnutls since it won´t build here with the new OpenSSL) but also to go here a step further to build IPFire with the new OpenSSL-1.1.0g i made a couple of changes --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=2d940ba2... to facilitate this update, hope this is useful for someone.

Have seen that PHP is about to be dropped --> https://wiki.ipfire.org/devel/telco/2017-12-04 in that case please forget the pushed ideas.

I stuck currently to build

• openvmtools
• lcr
• tor

<-- in my humble opinion the problem with those packages seems to be somehow related to another (last log messages before the compilation stops are pointing to a ENGINE problem ?).

• crda

<-- there seems to be some patches out there --> https://patchwork.openembedded.org/patch/136794/ , https://github.com/graugans/meta-udoo/issues/10 where the same problem seems to be addressed.

Regarding the OpenVPN update i was able to build OpenVPN-2.4.4 with OpenSSL-1.1.0g

ipfire build chroot (x86_64) root:/$ openvpn --version OpenVPN 2.4.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 4 2017 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

whereby a lot of things has been changed for OpenVPNs digests, tls and ciphers:

ipfire build chroot (x86_64) root:/$ openvpn --show-digests && openvpn --show-tls && openvpn --show-ciphers The following message digests are available for use with OpenVPN. A message digest is used in conjunction with the HMAC function, to authenticate received packets. You can specify a message digest as parameter to the --auth option.

MD5 128 bit digest size RSA-MD5 128 bit digest size SHA1 160 bit digest size RSA-SHA1 160 bit digest size MD5-SHA1 288 bit digest size RSA-SHA1-2 160 bit digest size RIPEMD160 160 bit digest size RSA-RIPEMD160 160 bit digest size MD4 128 bit digest size RSA-MD4 128 bit digest size RSA-SHA256 256 bit digest size RSA-SHA384 384 bit digest size RSA-SHA512 512 bit digest size RSA-SHA224 224 bit digest size SHA256 256 bit digest size SHA384 384 bit digest size SHA512 512 bit digest size SHA224 224 bit digest size whirlpool 512 bit digest size BLAKE2b512 512 bit digest size BLAKE2s256 256 bit digest size

Available TLS Ciphers, listed in order of preference:

TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384 TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA TLS-DHE-RSA-WITH-AES-256-CBC-SHA TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA TLS-DHE-RSA-WITH-AES-128-CBC-SHA

Be aware that that whether a cipher suite in this list can actually work depends on the specific setup of both peers. See the man page entries of --tls-cipher and --show-tls for more details.

The following ciphers and cipher modes are available for use with OpenVPN. Each cipher shown below may be use as a parameter to the --cipher option. The default key size is shown as well as whether or not it can be changed with the --keysize directive. Using a CBC or GCM mode is recommended. In static key mode only CBC mode is allowed.

AES-128-CBC (128 bit key, 128 bit block) AES-128-CFB (128 bit key, 128 bit block, TLS client/server mode only) AES-128-CFB1 (128 bit key, 128 bit block, TLS client/server mode only) AES-128-CFB8 (128 bit key, 128 bit block, TLS client/server mode only) AES-128-GCM (128 bit key, 128 bit block, TLS client/server mode only) AES-128-OFB (128 bit key, 128 bit block, TLS client/server mode only) AES-192-CBC (192 bit key, 128 bit block) AES-192-CFB (192 bit key, 128 bit block, TLS client/server mode only) AES-192-CFB1 (192 bit key, 128 bit block, TLS client/server mode only) AES-192-CFB8 (192 bit key, 128 bit block, TLS client/server mode only) AES-192-GCM (192 bit key, 128 bit block, TLS client/server mode only) AES-192-OFB (192 bit key, 128 bit block, TLS client/server mode only) AES-256-CBC (256 bit key, 128 bit block) AES-256-CFB (256 bit key, 128 bit block, TLS client/server mode only) AES-256-CFB1 (256 bit key, 128 bit block, TLS client/server mode only) AES-256-CFB8 (256 bit key, 128 bit block, TLS client/server mode only) AES-256-GCM (256 bit key, 128 bit block, TLS client/server mode only) AES-256-OFB (256 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-128-CBC (128 bit key, 128 bit block) CAMELLIA-128-CFB (128 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-128-CFB1 (128 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-128-CFB8 (128 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-128-OFB (128 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-192-CBC (192 bit key, 128 bit block) CAMELLIA-192-CFB (192 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-192-CFB1 (192 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-192-CFB8 (192 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-192-OFB (192 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-256-CBC (256 bit key, 128 bit block) CAMELLIA-256-CFB (256 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-256-CFB1 (256 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-256-CFB8 (256 bit key, 128 bit block, TLS client/server mode only) CAMELLIA-256-OFB (256 bit key, 128 bit block, TLS client/server mode only) SEED-CBC (128 bit key, 128 bit block) SEED-CFB (128 bit key, 128 bit block, TLS client/server mode only) SEED-OFB (128 bit key, 128 bit block, TLS client/server mode only)

The following ciphers have a block size of less than 128 bits, and are therefore deprecated. Do not use unless you have to.

BF-CBC (128 bit key by default, 64 bit block) BF-CFB (128 bit key by default, 64 bit block, TLS client/server mode only) BF-OFB (128 bit key by default, 64 bit block, TLS client/server mode only) CAST5-CBC (128 bit key by default, 64 bit block) CAST5-CFB (128 bit key by default, 64 bit block, TLS client/server mode only) CAST5-OFB (128 bit key by default, 64 bit block, TLS client/server mode only) DES-CBC (64 bit key, 64 bit block) DES-CFB (64 bit key, 64 bit block, TLS client/server mode only) DES-CFB1 (64 bit key, 64 bit block, TLS client/server mode only) DES-CFB8 (64 bit key, 64 bit block, TLS client/server mode only) DES-EDE-CBC (128 bit key, 64 bit block) DES-EDE-CFB (128 bit key, 64 bit block, TLS client/server mode only) DES-EDE-OFB (128 bit key, 64 bit block, TLS client/server mode only) DES-EDE3-CBC (192 bit key, 64 bit block) DES-EDE3-CFB (192 bit key, 64 bit block, TLS client/server mode only) DES-EDE3-CFB1 (192 bit key, 64 bit block, TLS client/server mode only) DES-EDE3-CFB8 (192 bit key, 64 bit block, TLS client/server mode only) DES-EDE3-OFB (192 bit key, 64 bit block, TLS client/server mode only) DES-OFB (64 bit key, 64 bit block, TLS client/server mode only) DESX-CBC (192 bit key, 64 bit block) RC2-40-CBC (40 bit key by default, 64 bit block) RC2-64-CBC (64 bit key by default, 64 bit block) RC2-CBC (128 bit key by default, 64 bit block) RC2-CFB (128 bit key by default, 64 bit block, TLS client/server mode only) RC2-OFB (128 bit key by default, 64 bit block, TLS client/server mode only)

also causing the "Sweet32 Birthday attacks" --> https://sweet32.info/ a lot of ciphers which are used in IPFires OpenVPN are marked as deprecated and should. in my opinion, marked in the WUI as such. A potential new digest "BLAKE2b" has also been introduced which i´am not sure if it works properly and if it works, if it should be integrated into the menu of IPFires OpenVPN WUI.

Not sure if we should support something experimental. Might become a headache later...

My main problem currently is that i can not test all that cause the installation process interrupts "Unable to install the language cache" , message comes from here --> https://github.com/ipfire/ipfire-2.x/blob/cf361ef4b55134254150b5070069f9d25b... i think. Some help in there might be great to proceed further with the OpenVPN update.

Are you still stuck at this?

Best, -Michael

Best,

Erik

Good morning,

On Fri, 2018-01-12 at 12:02 +0100, ummeegge wrote:

Hi Michael,

...

Erik: I am not sure why those packages won't build for you. I patched a number of them in my branch:

https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/ heads/openssl-11

Have loaded the current Core 118

I fetched your changes via:

git remote add openssl-11 ssh://ummeegge@git.ipfire.org/pub/git/people/ms/ipfi re-2.x.git git fetch openssl-11 git checkout openssl-11

and have build it with the same issues then mentioned before.

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.

...

I will rebase this branch now on where next currently is and build it again.

Haven´t found it, can you point out how to get it ?

Same branch...

...

I only expect asterisk to crash then which we need to update. It seems that Dirk has retired as maintainer for asterisk. I can try switching Asterisk to gnutls instead, but generally I would like to keep as much as we can on OpenSSL since that is our primary library.

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.

...

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.

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.

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?

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.

And about the negotiation, that would be nice, but does that work with older clients?

This option is also pushable so it can be used individually per client so it can be managed via the global section but also over the CCD section for each client.

...

Would you be able to submit patches so that it builds already? Any changes to the CGI files to add new ciphers can and should be a second patch.

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.

...

I am not sure if we should expect any problems with changed configuration parameter where we need to migrate configuration files. We are already using the new parameters where possible. So is there any other work left to do?

The main work is described above, OpenVPN-2.4.x checks the version of the clients, if they are <= 2.4 OpenVPN uses the already presant --cipher ALG, if the client are >= 2.4 it will negotiate the best cipher which is normally AES- 256-GCM which is also a complete new algorithm for OpenVPN (no cipher block chaining).

Cool.

...

...

also causing the "Sweet32 Birthday attacks" --> https://sweet32.info/ a lot of ciphers which are used in IPFires OpenVPN are marked as deprecated and should. in my opinion, marked in the WUI as such. A potential new digest "BLAKE2b" has also been introduced which i´am not sure if it works properly and if it works, if it should be integrated into the menu of IPFires OpenVPN WUI.

Not sure if we should support something experimental. Might become a headache later…

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.

Peter has proposed a patch recently with improved crypto, please work together with him.

...

...

My main problem currently is that i can not test all that cause the installation process interrupts "Unable to install the language cache" , message comes from here --> https://github.com/ipfire/ipfire- 2.x/blob/cf361ef4b55134254150b5070069f9d25b201bd1/src/installer/po/de.po#L 272 i think. Some help in there might be great to proceed further with the OpenVPN update.

Are you still stuck at this?

Yes as above mentioned have loaded Core118 and fetched your branch but stuck with the exact same problems as described in here --> https://lists.ipfire.org /pipermail/development/2017-December/003831.html . If i get something wrong here it might be great if you can point me to the right direction.

By the way, i wish you all a happy new year and all the best for 2018 :-) .

Happy new year to you, too!

-Michael

Greetings,

Erik

...

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/QuarkslabAndCryptographyEngineerA... 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=e623c9c726b7... . 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@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

...

On Tue, Jan 16, 2018 at 6:36 AM, ummeegge ummeegge@ipfire.org wrote:

...

...

...

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

Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...

Be careful of allowing users to be on their own if your goals are security objectives. The results usually leave a lot to be desired.

From NaCl's "Expert selection of default primitives"

(https://nacl.cr.yp.to/features.html):

Most programmers using cryptographic libraries are not expert cryptographic security evaluators. Often programmers pass the choice along to users—who usually have even less information about the security of cryptographic primitives. There is a long history of these programmers and users making poor choices of cryptographic primitives, such as MD5 and 512-bit RSA, years after cryptographers began issuing warnings about the security of those primitives.

It may be a better idea to support users if that is what they demand.

If you are drop dead opposed to the support, then make it hard for users to do it. Don't make it easy to do the insecure end-around. This is part of the "easy to use correctly, hard to use incorrectly" security design principal.

Sorry about the bikeshedding.

Jeff

Hi,

On Tue, 2018-01-16 at 12:36 +0100, ummeegge wrote:

Hi Michael, and thanks for the Q&A which is important for me to clear things up, try to make it as short as possible...

Am 15.01.2018 um 12:58 schrieb Michael Tremer:

...

wow, long email…

sorry for that ;-) ...

...

...

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

Oh OK, didn´t know that :D .

...

...

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.

Do you have an idea where to place lz4 in make.sh ? Have placed it currently before MySQL.

Put it where the others are as well. Very early in the IPFire stage.

...

...

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/QuarkslabAndCryptographyEnginee rAud 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?

Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...

Well, we don't support this at the moment. And I think we should leave it like this for now since we want to release OpenSSL as early as possible.

We can add this later if we need to.

...

...

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

Thanks for clarification on that, wasn´t sure causing this topic !

...

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.

So should i leave the the switch for '--ncp-disable' option out of the WUI ? In that case we will reduce the ciphers on IPFire significant since OpenVPN will then use only AES-256-CBC or AES-256GCM if the clients are >=2.4.0 (which mostly are meanwhile i think) !

What are you thinking about to leave the cipher-negotiation checkbox out of the global section (in that case is all like before) but i think we should deliver at least one possibility in CCD section to disable the cipher- negotiation which would then looks like in here --> https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN- 2.4_beta2/Disable-NCP-CCD.png and is only located in the "Advanced client options" in the CCD section ?

I am not sure if this negotiation makes any sense for us. It comes a bit too late. The reason is as follows:

If someone has deployed OpenVPN in the past, they had to choose the cipher. Let's say that was AES-256-CBC. It absolutely makes no sense to add any of the weaker ciphers like AES-128-CBC. Neither for security, nor performance or compatibility. Every client must have supported AES-256-CBC in the first place.

This makes only sense in the other direction where I would want to use AES-256- GCM instead of CBC. So I could still support my clients that are on OpenVPN 2.3 and only support AES-256-CBC. But when I choose GCM, I certainly don't want any client to keep using CBC.

AES-256-CBC will probably have to be set with the "cipher" option. Not sure if OpenVPN always prefers that one then.

My point is: This is going to be complicated in the UI and giving the user a decision that they are not always competent enough to make.

So I would say we should add the new ciphers to the list and disable the negotiation for now. We won't have any disadvantages, yet.

And after we have shipped this, we can add something to the advanced page where people can choose additional ciphers similar to the IPsec settings. So people who want to can edit this, but generally we don't give the users too many options.

Does that sound a good idea?

Since the choice of the cipher is an important setting it might be great in my opinion the give the users at least a possibility (in the advanced settings section) to configure this for each client if wanted ?

Yes, see above.

But I would prefer to defer this so that we can ship OpenSSL 1.1.0 really quick now and add that with the next Core Update then. This will also allow us to ship smaller changes that shouldn't break things too easily and we can track bugs easier.

Above all, there are currently only 3 algorithms left on IPFire which are not affected by the Sweet32 problem (AES, Camellia and Seed which are 128 bit block ciphers).

Please mark everything as weak what is considered as such. Please add some reference in the commit message - even if that is just Wikipedia.

...

...

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.

Yes we would need "--ncp-ciphers ALGs" for this new feature. Generally i think this could be a security/performance gain for a lot´s of people out there especially if they are using the old and deprecated ciphers like Blowfish (old default) or the whole 3DES collection.

Actually since you raise performance: I have only considered this for roadwarrior networks, yet.

The ncp-ciphers options makes even less sense with net-to-net connections, because people control both sides of the tunnel. And then you would just want to pick one cipher and use exactly that. You don't want to leave it up to chance which cipher is used. This would also mitigate any downgrading attacks.

...

...

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.

All tests has been done with the old OpenSSL lib. One concern for me with the new lib is if the old ovpn.cnf (OpenVPNs OpenSSL conf) is OK or if there needs to be something done too. But i´am calmed a little down if this changes are not released with the next Core update.

Just test :) We will see what breaks.

OpenVPN has broken many many things in the past that we didn't expect because they care some shit about backwards-compatibility.

...

...

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/op envp 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?

Exactly.

Again, an issue where backwards-compatibility was clearly not important.

...

...

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?bu g=84 9909 and OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849 909 . 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=e623c9c72 6b7d0f5fb14b9659b4a6625&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.

Am also not really happy with this but have found so far no better solutions. Should i place the script to /etc/fcron.daily/ ? Would make sense i think.

Yes.

...

...

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.

This is exactly the point. If clients are deleted via ovpnmain.cgi the CRL will automatically be renewed via ovpnmain.cgi but if the systems runs without some specific interactions, the CRL expires and all connections are over and done until the CRL has been renewed.

Yes.

...

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

Yes this would make no sense at all.

...

...

...

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/

Thanks for pointing that out. I did also changes regarding the "vpn weak" warnings but this changes includes more then the DH-parameter. As above mentioned 6 from 12 the currently available on IPFires OpenVPN are deprecated cause there can be attacked via Sweet32. OpenVPN implemented "reneg-bytes 64000000" with v. 2.3.13 which forces frequent rekeying after 64 MB data transfer, this can lead to a lot more rekeying cycles then the one hour cycle which is the regular behavior.

64MB? That is once a second over a Gigabit link. Or roughly every 5 to 6 seconds over a 100M link.

Is performance not an issue here?

All that can somehow be neglected with the cipher-negotiaion and newer clients since there will then be used anyways AES-256 which is a 128 bit block cipher.

The SHA512 default setting changes from Peter are for N2N defaults which should be OK in my opinion since every new connection needs to be created for both sides (TLS-server and TLS-client), this should´t crash anything.

Okay. So please let's get that patch merged then.

One more important thing. If we update to OpenVPN-2.4.x there is the need that the changes will be written to the server.conf (save button) otherwise the server do not start (causing the script-security entry), after i manually updated the files i needed to stop the server, hit the save button and only after then the server can be started again. openvpnctrl do provides only stop|start but no save option do you know solve this via command line parameter while the update ?

We can stop all OpenVPN instances on the command line.

For RW this is: openvpnctrl -k

And for all N2N connections that is: openvpnctrl -kn2n

Again thanks for your feedback and help.

Greetings,

Erik

...

-Michael

Hi all,

Am 16.01.2018 um 13:56 schrieb Michael Tremer:

...

Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...

Well, we don't support this at the moment. And I think we should leave it like this for now since we want to release OpenSSL as early as possible.

We can add this later if we need to.

Since IPFire do provides openvpn-plugin-auth-pam.so we should be OK with script-security 2 instead of 3 but as you suggested, we can do this also later.

...

So should i leave the the switch for '--ncp-disable' option out of the WUI ? In that case we will reduce the ciphers on IPFire significant since OpenVPN will then use only AES-256-CBC or AES-256GCM if the clients are >=2.4.0 (which mostly are meanwhile i think) !

What are you thinking about to leave the cipher-negotiation checkbox out of the global section (in that case is all like before) but i think we should deliver at least one possibility in CCD section to disable the cipher- negotiation which would then looks like in here --> https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN- 2.4_beta2/Disable-NCP-CCD.png and is only located in the "Advanced client options" in the CCD section ?

I am not sure if this negotiation makes any sense for us. It comes a bit too late. The reason is as follows:

If someone has deployed OpenVPN in the past, they had to choose the cipher. Let's say that was AES-256-CBC. It absolutely makes no sense to add any of the weaker ciphers like AES-128-CBC. Neither for security, nor performance or compatibility. Every client must have supported AES-256-CBC in the first place.

This makes only sense in the other direction where I would want to use AES-256- GCM instead of CBC. So I could still support my clients that are on OpenVPN 2.3 and only support AES-256-CBC. But when I choose GCM, I certainly don't want any client to keep using CBC.

This is exactly what 'ncp-ciphers AES-256-GCM:AES-256-CBC' do (the cipher list is expandable, see for an example how Fedora did this --> https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN#Detaile... ). The negotiation checks if the client is AES-256-GCM ready if not AES-256-CBC will be used <-- but all that only if the client have OpenVPN 2.4.0 and above. If the client is still 2.3.x and below, the old chosen --cipher and --auth directives will be used. To make it a little clearer, all that is managed by the negotiation so i think it would makes a lot of sense.

AES-256-CBC will probably have to be set with the "cipher" option. Not sure if OpenVPN always prefers that one then.

If a 2.4.x client connects, the ncp-cipher list tries from left to right which cipher is available on the other side and uses it (pushable) which is a kind of liberation of the cipher and by the usage of GCM also for the HMAC since different algorithms can be used for specific clients and there is no need anymore the find and use the least common multi of all clients.

My point is: This is going to be complicated in the UI and giving the user a decision that they are not always competent enough to make.

So I would say we should add the new ciphers to the list and disable the negotiation for now. We won't have any disadvantages, yet.

Done. All changes are meanwhile made and ready to push. Nevertheless we need one new directive for this (--ncp-disable) otherwise OpenVPN uses --ncp-ciphers per default. Important for me, also if the time is now kind of short, to point that more clearly out. The negotiation is an advantage (possibly one of the bigger ones in the new version) compared to the old version, if we disable it to get a more clear view of potential bugs it might be a good way for the first but i think we should change this in one of the coming updates.

And after we have shipped this, we can add something to the advanced page where people can choose additional ciphers similar to the IPsec settings. So people who want to can edit this, but generally we don't give the users too many options.

Does that sound a good idea?

OK, let´s doing it.

...

Since the choice of the cipher is an important setting it might be great in my opinion the give the users at least a possibility (in the advanced settings section) to configure this for each client if wanted ?

Yes, see above.

But I would prefer to defer this so that we can ship OpenSSL 1.1.0 really quick now and add that with the next Core Update then. This will also allow us to ship smaller changes that shouldn't break things too easily and we can track bugs easier.

Will push it after this correspondence and an OK from you.

...

Above all, there are currently only 3 algorithms left on IPFire which are not affected by the Sweet32 problem (AES, Camellia and Seed which are 128 bit block ciphers).

Please mark everything as weak what is considered as such. Please add some reference in the commit message - even if that is just Wikipedia.

Will search for some reference to refer to.

...

Yes we would need "--ncp-ciphers ALGs" for this new feature. Generally i think this could be a security/performance gain for a lot´s of people out there especially if they are using the old and deprecated ciphers like Blowfish (old default) or the whole 3DES collection.

Actually since you raise performance: I have only considered this for roadwarrior networks, yet.

The ncp-ciphers options makes even less sense with net-to-net connections, because people control both sides of the tunnel. And then you would just want to pick one cipher and use exactly that. You don't want to leave it up to chance which cipher is used. This would also mitigate any downgrading attacks.

The negotiation do not work for N2N connections since N2N do not operate in P2MP mode. This is also showing up in the logs.

Sun Jan 14 08:15:35 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode

Have nevertheless added GCM for N2N too. May there can also be done some cosmetics since the HMAC menu on N2N is useless if GCM will be used (default SHA256). N2N have currently no --tls-auth where an chosen HMAC are also used but i think this can also be done afterwards. Have integrated also --tls-crypt for N2N while my testings which works nice, --tls-auth might be also an option for N2N but that´s a future sound i think.

...

All tests has been done with the old OpenSSL lib. One concern for me with the new lib is if the old ovpn.cnf (OpenVPNs OpenSSL conf) is OK or if there needs to be something done too. But i´am calmed a little down if this changes are not released with the next Core update.

Just test :) We will see what breaks.

Will do surely do this if the testing is available or the language cache problem has been resolved.

...

...

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

Exactly.

Again, an issue where backwards-compatibility was clearly not important.

Yes but i think we found mostly some good ways around.

...

...

...

...

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/

Thanks for pointing that out. I did also changes regarding the "vpn weak" warnings but this changes includes more then the DH-parameter. As above mentioned 6 from 12 the currently available on IPFires OpenVPN are deprecated cause there can be attacked via Sweet32. OpenVPN implemented "reneg-bytes 64000000" with v. 2.3.13 which forces frequent rekeying after 64 MB data transfer, this can lead to a lot more rekeying cycles then the one hour cycle which is the regular behavior.

64MB? That is once a second over a Gigabit link. Or roughly every 5 to 6 seconds over a 100M link.

Is performance not an issue here?

It is, while rekeying no data can be transferred, if bigger DH-parameter are used the key exchange needs also longer time. If there are lot´s of clients with big throughput it can possibly feel a little like an unstable connection...

...

All that can somehow be neglected with the cipher-negotiaion and newer clients since there will then be used anyways AES-256 which is a 128 bit block cipher.

The SHA512 default setting changes from Peter are for N2N defaults which should be OK in my opinion since every new connection needs to be created for both sides (TLS-server and TLS-client), this should´t crash anything.

Okay. So please let's get that patch merged then.

Have used the way Peter used it with the additional 'weak' entry for the respective algorithms. Did used before the optgroup label but i thought it might be better to stay in the already given style. If wanted this can also be changed later on. As above mentioned, will push the changes after this exchange and an OK from you.

...

One more important thing. If we update to OpenVPN-2.4.x there is the need that the changes will be written to the server.conf (save button) otherwise the server do not start (causing the script-security entry), after i manually updated the files i needed to stop the server, hit the save button and only after then the server can be started again. openvpnctrl do provides only stop|start but no save option do you know solve this via command line parameter while the update ?

We can stop all OpenVPN instances on the command line.

For RW this is: openvpnctrl -k

And for all N2N connections that is: openvpnctrl -kn2n

Michael, this won´t work cause there is also the need to write at least two server.conf parameter (script-security 3 and ncp-disable). If there is no command which writes the changed directives from ovpnmain.cgi to server.conf (equivalent to the save button in the WUI) we would need something like this

# Add OpenVPN-2.4 directives to server.conf

if [ -e /var/ipfire/ovpn/server.conf ]; then if pgrep openvpn >/dev/null; then openvpnctrl -k sed -i -e 's/script-security 3 system/script-security 3/' -e '/status .*/ a ncp-disable' /var/ipfire/ovpn/server.conf openssl ca -gencrl -keyfile /var/ipfire/ovpn/ca/cakey.pem -cert /var/ipfire/ovpn/ca/cacert.pem -out /var/ipfire/ovpn/crls/cacrl.pem -config /var/ipfire/ovpn/openssl/ovpn.cnf openvpnctrl -s else sed -i -e 's/script-security 3 system/script-security 3/' -e '/status .*/ a ncp-disable' /var/ipfire/ovpn/server.conf openssl ca -gencrl -keyfile /var/ipfire/ovpn/ca/cakey.pem -cert /var/ipfire/ovpn/ca/cacert.pem -out /var/ipfire/ovpn/crls/cacrl.pem -config /var/ipfire/ovpn/openssl/ovpn.cnf fi fi

in the core updater (update.sh). There is the need for an active OpenVPN server to stop it, press the save button to get the changes and to start it again. Otherwise we get an

Jan 17 14:54:57 ipfire-server openvpnserver[16583]: Options error: Unrecognized option or missing or extra parameter(s) in /var/ipfire/ovpn/server.conf:10: script-security (2.4.4) Jan 17 14:54:57 ipfire-server openvpnserver[16583]: Use --help for more information.

OpenVPN-2.4.x do not start without the changed script-security directive.

Also i think the CRL should also be renewed while the update cause a lot of machines out there might have an expired CRL (last test on my machine have had that problem), the CRL update script is in fact present but the daily fcron is executed at 1:01 in the morning as far as i remember so there can be a couple of hours with a not working OpenVPN server if the background why that´s happened is not known.

One more thing Michael, possibly a little OT here but nevertheless important for OpenVPN. It seems that the last changes for the "Extended key usage" of ovpn.cnf from Core 115 has only been partly delivered. There is feedback from 3 users in the forum --> https://forum.ipfire.org/viewtopic.php?f=27&t=20180 that the changes in ovpn.cnf is missing, whereby ovpnmain.cgi do serves all changes. Might it be an idea to ship the changed ovpn.cnf --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/ovpn/openssl/ovpn.c... again ? Otherwise this feature is useless.

Some news from here. Have currently a little stress on work so my feedback on the list might come a little later.

Greetings,

Erik

P.S. Thanks to the others for their feedback (Michael Horace thanks again for your testings <-- did you know happens with your --ncp-disable issue) with more time i will respond also to your ideas.

Hi,

On Sat, 2018-01-13 at 07:30 -0500, Jeffrey Walton wrote:

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.

Here is the OpenVPN bug: https://community.openvpn.net/openvpn/ticket/759 . Here is the OpenSSH bug: https://github.com/openssh/openssh-portable/pull/48 .

OpenVPN 2.4 links fine against OpenSSL 1.1.0.

OpenSSH needs to be patched, but a maintained patchset is available and used by all the other major distributions.

OpenVPN and OpenSSH are going to have to shit or get off the pot. TLS 1.3 is in final draft stages, and it will be adopted soon.

Jeff

-Michael