Upgrading to OpenSSL 1.1.0

Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

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/openssl-11

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

Best,
-Michael

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

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

Hi all,
have tried to build IPFire with the new OpenSSL-1.1.0 and have had a couple of other packages (beneath Michaels already announced ones) which did not build properly.

Have had problems with:

1) wget:
openssl.o: In function `ssl_init':
openssl.c:(.text+0x72e): undefined reference to `ENGINE_load_builtin_engines'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:1569: wget] Error 1

there is a patch for OpenSSL-1.1.0 --> https://git.savannah.gnu.org/cgit/wget.git/commit/?h=openssl-1.1 available which do not fixes this problem.

2) openvmtools:
../lib/sslDirect/.libs/libSslDirect.a(libSslDirect_la-sslDirect.o): In function `SSL_Init':
sslDirect.c:(.text+0x25e): undefined reference to `ENGINE_register_all_ciphers'
sslDirect.c:(.text+0x263): undefined reference to `ENGINE_register_all_digests'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:548: libvmtools.la] Error 1
make[2]: Leaving directory '/usr/src/open-vm-tools-10.0.5-3227872/libvmtools'
make[1]: *** [Makefile:505: all-recursive] Error 1
make[1]: Leaving directory '/usr/src/open-vm-tools-10.0.5-3227872'
make: *** [openvmtools:85: /usr/src/log/open-vm-tools-10.0.5-3227872] Error 2

3) Asterisk:
which pointed Michael already out.


4) crda:
Also with the new 3.18 version --> http://drvbp1.linux-foundation.org/~mcgrof/rel-html/crda/ the building process do not work.
make[1]: Entering directory '/usr/src/crda-3.13'
  GEN  keys-gcrypt.c
  Trusted pubkeys: pubkeys/linville.key.pub.pem
ERROR: Failed to import the "M2Crypto" module: No module named _m2crypto
Please install the "M2Crypto" Python module.
On Debian GNU/Linux the package is called "python-m2crypto".
make[1]: *** [Makefile:114: keys-gcrypt.c] Error 1
make[1]: Leaving directory '/usr/src/crda-3.13'
make: *** [crda:75: /usr/src/log/crda-3.13] Error 2

whereby python-m2crypt is presant also a newer M2Crypto version do not solves this.

5) tor:
src/common/crypto.c:3435:3: warning: nested extern declaration of 'ENGINE_cleanup' [-Wnested-externs]
make[2]: *** [Makefile:5213: src/common/crypto.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/usr/src/tor-0.3.1.7'
make[1]: *** [Makefile:3106: all] Error 2
make[1]: Leaving directory '/usr/src/tor-0.3.1.7'
make: *** [tor:81: /usr/src/log/tor-0.3.1.7] Error 2

also updates to 0.3.1.9 but also 0.3.2.6_alpha do not solves this issue.

6) freeradius:
build/objs/src/main/tls.o: In function `tls_global_cleanup':
tls.c:(.text+0x4670): undefined reference to `ENGINE_cleanup'
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/boiler.mk:629: build/bin/local/radiusd] Error 1
make[1]: *** Waiting for unfinished jobs....
build/objs/src/main/tls.o: In function `tls_global_cleanup':
tls.c:(.text+0x4670): undefined reference to `ENGINE_cleanup'
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/boiler.mk:630: build/bin/radiusd] Error 1
make[1]: Leaving directory '/usr/src/freeradius-server-3.0.14'
make: *** [freeradius:81: /usr/src/log/freeradius-server-3.0.14] Error 2

Tried to find all packages which do not build with the new OpenSSL version, since i haven´t found fixes (fast search around) i commented them to get a full picture of what works and what not.

Some ROOTFILES seems to be also problematic.


It was possible to build:

1) php-7.2.0
but haven´t test it yet.

2) OpenVPN-2.4.4

But an installation of the ISO is currently not possible cause a problem with the language cache "der sprachdateizwischenspeicher konnte nicht erstellt werden" . So i currently stuck here (make nevertheless currently again a clean build).


Some news from here.

Greetings,

Erik


Am 29.11.2017 um 14:12 schrieb Michael Tremer:

> 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/openssl-11
> 
> Please also submit improvements of other packages that we can make sure of (i.e.
> better cipher suites for Apache, etc.)...
> 
> Best,
> -Michael

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

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=2d940ba2187a53cf52d2191a36c3897636b9600c 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(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

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.

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#L272 i think.
Some help in there might be great to proceed further with the OpenVPN update.

Best,

Erik

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

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=2d940ba2187a53cf52d2191a36c3897636b9600c 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(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
> 
> 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/cf361ef4b55134254150b5070069f9d25b201bd1/src/installer/po/de.po#L272 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
> 
> 
> 

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

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

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(a)git.ipfire.org/pub/git/people/ms/ipfire-2.x.git
git fetch openssl-11
git checkout openssl-11

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

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

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

> 
> 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/7460cead169ea919f66ad7068e764fef37bf8f8b#diff-2011d5d928fd214cacb83844729c65cc a little more then needed has been done but it describes very closely the needed changes.
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.
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. 
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). 

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

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

> 
>> 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#L272 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 :-) .

Greetings,

Erik


> 

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

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(a)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/7460cead169ea919f66ad706
> 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
> 
> 
> > 
> 
> 

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

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

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/7460cead169ea919f66ad706
>> 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:
>> 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/QuarkslabAndCryptographyEngineerAudits --> under "OVPN-08-1: OpenVPN configuration risks: --script-security 3" you can find there also OpenVPNs statements causing this topic.


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

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=e623c9c726b7d0f5fb14b9659b4a6625&start=45#p112737 . 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(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


> 

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

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.

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

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

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

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 ?

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 ?

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

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


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

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

Exactly.

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

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.

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

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

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 ?


Again thanks for your feedback and help.

Greetings,

Erik

> 

Re: Upgrading to OpenSSL 1.1.0

[Jeffrey Walton]

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

On Tue, Jan 16, 2018 at 6:36 AM, ummeegge <ummeegge(a)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/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?
>
> 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

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

Hello Jeffrey,

that is some good idea, however I do not see how we can realise that easily and
without breaking anything in the current user interface.

In IPFire 3 we have decided to introduce so called "Security Policies":

  https://git.ipfire.org/?p=network.git;a=tree;f=config/vpn/security-policies;h=57c18b7e74d8e108195e829aa0d1816c296cf05a;hb=HEAD

We provide at least two ones that are updated with the system.

One policy is called "system" which is pretty much the most-compatible one and
uses good and string ciphers. If we would ever consider one of them as broken,
we would remove it from that list. Of course the system would always prefer the
strongest option it can negotiate with the other peer.

The performance option uses only strong ciphers but for example with smaller key
sizes like AES128 instead of 256. And only SHA256.

We have considered some compatibility option before but I don't want to tempt
users to always select that.

Of course the CLI allows to create own policies with what ever you would prefer
to use.

On Tue, 2018-01-16 at 07:34 -0500, Jeffrey Walton wrote:
> On Tue, Jan 16, 2018 at 6:36 AM, ummeegge <ummeegge(a)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/QuarkslabAndCryptographyEngin
> > > > eerAud
> > > > 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.

Please keep the feedback coming. The more eyeballs we get on these matters, the
better.

Best,
-Michael

> 
> Jeff

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

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

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

> 

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

Re: Upgrading to OpenSSL 1.1.0

[Horace Michael]

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

Hi,
Two inputs on validation based CRL and performance observed durin tests.

On Tue, 16 Jan 2018 14:56:11 +0200, Development wrote:
> 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.
>

Above topic link also contains example of a full Certificate Autorithy management using standard OpenSSL functionalities - I generated ROOT CA, Intermediary CA and server cerificates for apache. Apache init script uses functions to test all CA elements - ROOT and its CRL, Intermediary CA and its CRL, server certificate.

I tested it in several conditions and up to now the CA related tasks work very fast - at each an every service start.  
> > > 
> > > > 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?
>

N2N tests (using OpenVPN 2.4 vs standard IPFire   OpenVPN) lead to 30% speed decrease using same network and same test file - a big, heavily compressed backup file moved between same file servers over N2N.

I did had lzo activated - and lzo got an upgrade on 2.4, but after reading above change is more likely that speed decrease is due to rekeying cycles.


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

Hope it helps,
-- 
Horace 

Re: Upgrading to OpenSSL 1.1.0

[ummeegge]

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

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#Detailed_Description ). 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.cnf;h=40daf2a0a886dd4957df00c3303d3504f8cb0bc0;hb=b66b02ab73863bcb9130300d8ef0eecdc51efde3 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.

Re: Upgrading to OpenSSL 1.1.0

[Jeffrey Walton]

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

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.

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

Re: Upgrading to OpenSSL 1.1.0

[Michael Tremer]

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

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

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