From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: Upgrading to OpenSSL 1.1.0 Date: Tue, 16 Jan 2018 12:36:17 +0100 Message-ID: <82DD56CD-6501-49B9-BD2F-A766C9D82AEB@ipfire.org> In-Reply-To: <1516017493.3647.78.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9102031046432121029==" List-Id: --===============9102031046432121029== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, and thanks for the Q&A which is important for me to clear things up, try to m= ake it as short as possible... Am 15.01.2018 um 12:58 schrieb Michael Tremer: > wow, long email=E2=80=A6 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 witho= ut >> 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 ? >=20 > None, I just haven't tried to build it because you are the maintainer of Op= enVPN > :) Oh OK, didn=C2=B4t 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... >=20 > Not sure if people are using MySQL too much on IPFire. Hopefully they don't= do > that for any performance-critical applications. >=20 > 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 a= nd >> 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. >=20 > 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" di= rectives. Since this option is not officially supported, i think their on the= ir 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 c= an >> 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 understand= ing >> 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=C2=B4t be used. If i get t= hat right >> this might be one case where the automatic cipher negotiation should be >> deactivated ? Another one might be setups with vast amounts of clients whe= re >> possible less computing power with smaller key lengths is wanted. >> That=C2=B4s why i disabled the cipher negotiation per default and if wante= d 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 clien= ts.=20 >> 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 !!! >=20 > OpenSSL choses to activate these things automatically when they are availab= le. > There is no need to do anything. Even apache and things like that use them > because they use OpenSSL. >=20 > However, that is not an HWRNG. That is just a random number generator like > RDRAND on Intel processors. >=20 > AESNI is not called a HWRNG. Thanks for clarification on that, wasn=C2=B4t sure causing this topic ! >=20 > 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 shoul= d be > possible system-wide. >=20 > 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 w= ill then use only AES-256-CBC or AES-256GCM if the clients are >=3D2.4.0 (whi= ch mostly are meanwhile i think) ! What are you thinking about to leave the cipher-negotiation checkbox out of t= he global section (in that case is all like before) but i think we should del= iver at least one possibility in CCD section to disable the cipher-negotiatio= n which would then looks like=20 in here --> https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN-2.4_beta= 2/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 m= y 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 bl= ock ciphers). >> but the server.conf serves --ncp-ciphers but also --cipher and --auth --> >>=20 >> #OpenVPN Server conf >>=20 >> 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 >>=20 >> so i think this should be no problem. >=20 > 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 thin= k this could be a security/performance gain for a lot=C2=B4s of people out th= ere especially if they are using the old and deprecated ciphers like Blowfish= (old default) or the whole 3DES collection.=20 >> Shouldn=C2=B4t 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 d= own >> the most important steps ? >=20 > I thought that was tested already. However, the OpenSSL is branch is somewh= at > 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 nee= ds to be something done too. But i=C2=B4am calmed a little down if this changes are not released with the = next Core update. >=20 >> I forgot also one important point to mention which we discovered really la= te. >> 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: >>=20 >> Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 VERIFY ERR= OR: >> depth=3D0, error=3DCRL has expired: C=3DUS, O=3DTatoine, CN=3DLGG3 >> Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 OpenSSL: >> 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 >=20 > The CRL has a valid before and after date? In that case we just need to > regenerate it. >=20 > If the CA or some client certificates have expired, this is what we would > expect, isn't it? Exactly. >=20 >> A more detailed discussion in the IPFire forum is here --> >> https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&start=3D30#p112529= located, >> the Debian discussion --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bu= g=3D84 >> 9909 and OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D8= 49909 >> . An idea there was to set the "nextUpdate" value in a far future as the C= A expiry date is, we decided in the forum to leave this idea behind and start= ed to develop a first idea for an CRL updater, please check this in here --> = https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&sid=3De623c9c726b7d0f= 5fb14b9659b4a6625&start=3D45#p112737 . In that case we would need a script wh= ich checks periodically when a CRL update needs to be done.=20 >=20 > 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. >=20 >> If you have better ideas for this or another script it might be really >> helpful. >=20 > 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 wi= ll 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. >=20 > 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. >>=20 >> We can do this, no problem. @Peter would you write me to ummeegge at >> ipfire.org ? >=20 > It is here https://patchwork.ipfire.org/patch/1594/ Thanks for pointing that out.=20 I did also changes regarding the "vpn weak" warnings but this changes include= s more then the DH-parameter. As above mentioned 6 from 12 the currently available on IPFires OpenVPN are d= eprecated cause there can be attacked via Sweet32. OpenVPN implemented "reneg= -bytes 64000000" with v. 2.3.13 which forces frequent rekeying after 64 MB da= ta transfer, this can lead to a lot more rekeying cycles then the one hour cy= cle which is the regular behavior. All that can somehow be neglected with the cipher-negotiaion and newer client= s since there will then be used anyways AES-256 which is a 128 bit block ciph= er. The SHA512 default setting changes from Peter are for N2N defaults which shou= ld be OK in my opinion since every new connection needs to be created for bot= h sides (TLS-server and TLS-client), this should=C2=B4t crash anything. One more important thing. If we update to OpenVPN-2.4.x there is the need tha= t 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 upd= ated the files i needed to stop the server, hit the save button and only afte= r 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 >=20 --===============9102031046432121029==--