From mboxrd@z Thu Jan 1 00:00:00 1970 From: Horace Michael To: development@lists.ipfire.org Subject: Re: Upgrading to OpenSSL 1.1.0 Date: Tue, 16 Jan 2018 16:28:19 +0200 Message-ID: <0Mdrph-1eCVOF3yph-00Pc53@mail.gmx.com> In-Reply-To: <1516107371.3647.111.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1076992721225012816==" List-Id: --===============1076992721225012816== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Two inputs on validation based CRL and performance observed durin tests. On Tue, 16 Jan 2018 14:56:11 +0200, Development wrote: > Hi, >=20 > 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... > >=20 > > Am 15.01.2018 um 12:58 schrieb Michael Tremer: > >=20 > > > wow, long email=E2=80=A6 > >=20 > > sorry for that ;-) ... > >=20 > > > > 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 numb= er), > > > > there was also no need for the LZ4 lib ? What problems appears for yo= u ? > > >=20 > > > None, I just haven't tried to build it because you are the maintainer of > > > OpenVPN > > > :) > >=20 > > Oh OK, didn=C2=B4t know that :D . > >=20 > > > > 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 th= is > > > > compression lib... > > >=20 > > > Not sure if people are using MySQL too much on IPFire. Hopefully they d= on't > > > do > > > that for any performance-critical applications. > > >=20 > > > I guess the only other useful application for LZ4 would be backups. > >=20 > > Do you have an idea where to place lz4 in make.sh ? Have placed it curren= tly > > before MySQL. >=20 > Put it where the others are as well. Very early in the IPFire stage. >=20 > > > > Another point in here is IPFire uses currently the level 3 of --scrip= t- > > > > 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 uns= afe > > > > and > > > > have also be again pointed out while the QuarkLabs and Cryptography > > > > Engineering LCC audit --> > > > > https://community.openvpn.net/openvpn/wiki/QuarkslabAndCryptographyEn= ginee > > > > rAud > > > > its --> under "OVPN-08-1: OpenVPN configuration risks: --script-secur= ity > > > > 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? > >=20 > > 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... >=20 > Well, we don't support this at the moment. And I think we should leave it l= ike > this for now since we want to release OpenSSL as early as possible. >=20 > We can add this later if we need to. >=20 > >=20 > > > > The ON/OFF switch should be there to deactivate the automatic cipher > > > > negotiation not the HWRNG. As far as i remember some crypto accelerat= ors > > > > can > > > > only be used with certain types of encryption e.g. --> https://doc.p= fsens > > > > 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 t= he > > > > 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 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=C2=B4s 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 t= he > > > > CCD > > > > option can be used to deactivate the cipher negotiation for specific > > > > clients.=20 > > > > Not sure if this is the best practice and it might be great if someon= e 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 > > > available. > > > There is no need to do anything. Even apache and things like that use t= hem > > > because they use OpenSSL. > > >=20 > > > However, that is not an HWRNG. That is just a random number generator l= ike > > > RDRAND on Intel processors. > > >=20 > > > AESNI is not called a HWRNG. > >=20 > > Thanks for clarification on that, wasn=C2=B4t sure causing this topic ! > >=20 > > >=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 s= hould > > > be > > > possible system-wide. > > >=20 > > > We should not have too many switches. It makes the web UI complicated. > >=20 > > So should i leave the the switch for '--ncp-disable' option out of the WU= I ?=20 > > In that case we will reduce the ciphers on IPFire significant since OpenV= PN > > will then use only AES-256-CBC or AES-256GCM if the clients are >=3D2.4.0= (which > > mostly are meanwhile i think) ! > >=20 > > 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=20 > > 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 ? >=20 > I am not sure if this negotiation makes any sense for us. It comes a bit too > late. The reason is as follows: >=20 > 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 pl= ace. >=20 > 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. >=20 > AES-256-CBC will probably have to be set with the "cipher" option. Not sure= if > OpenVPN always prefers that one then. >=20 > 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. >=20 > 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. >=20 > And after we have shipped this, we can add something to the advanced page w= here > people can choose additional ciphers similar to the IPsec settings. So peop= le > who want to can edit this, but generally we don't give the users too many > options. >=20 > Does that sound a good idea? >=20 > > 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 settin= gs > > section) to configure this for each client if wanted ? >=20 > Yes, see above. >=20 > But I would prefer to defer this so that we can ship OpenSSL 1.1.0 really q= uick > 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. >=20 > > 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). >=20 > Please mark everything as weak what is considered as such. Please add some > reference in the commit message - even if that is just Wikipedia. >=20 > > > > 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 mome= nt, > > > too. > >=20 > > Yes we would need "--ncp-ciphers ALGs" for this new feature. Generally i = think > > this could be a security/performance gain for a lot=C2=B4s of people out = there > > especially if they are using the old and deprecated ciphers like Blowfish= (old > > default) or the whole 3DES collection.=20 >=20 > 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 wa= nt to > pick one cipher and use exactly that. You don't want to leave it up to chan= ce > which cipher is used. This would also mitigate any downgrading attacks. >=20 > > > > Shouldn=C2=B4t i test OpenVPN with the new OpenSSL before pushing thi= s, if the > > > > iso > > > > is working i can make an installation in my testing environment to br= eak > > > > down > > > > the most important steps ? > > >=20 > > > 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 sen= d it > > > now, > > > it wouldn't break anyone's system. > >=20 > > 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=C2=B4am calmed a little down if this changes are not released with = the next > > Core update. >=20 > Just test :) We will see what breaks. >=20 > OpenVPN has broken many many things in the past that we didn't expect becau= se > they care some shit about backwards-compatibility. >=20 > > > > I forgot also one important point to mention which we discovered real= ly > > > > late. > > > > OpenVPN-2.4.x refactors the CRL handling --> https://github.com/OpenV= PN/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 th= e 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 > > > > ERROR: > > > > 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 OpenS= SL: > > > > error:14089086:SSL routines:ssl3_get_client_certificate:certificate v= erify > > > > failed > > > > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS_E= RROR: > > > > BIO > > > > read tls_read_plaintext error > > > > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS E= rror: > > > > TLS > > > > object -> incoming plaintext read error > > > > Nov 22 22:56:26 OpenVPN-2-4 openvpnserver[16368]: a.b.c.d:46227 TLS E= rror: > > > > 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 wou= ld > > > expect, isn't it? > >=20 > > Exactly. >=20 > Again, an issue where backwards-compatibility was clearly not important. >=20 > > >=20 > > > > A more detailed discussion in the IPFire forum is here --> > > > > https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D18067&start=3D30#p1= 12529 > > > > located, > > > > the Debian discussion --> https://bugs.debian.org/cgi-bin/bugreport.c= gi?bu > > > > g=3D84 > > > > 9909 and OpenVPN --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bu= g=3D849 > > > > 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=3D50&t=3D18067&sid= =3De623c9c72 > > > > 6b7d0f5fb14b9659b4a6625&start=3D45#p112737 . In that case we would ne= ed a > > > > script which checks periodically when a CRL update needs to be done. = > > >=20 > > > Not a fan of cron jobs for things like this, but I guess we have no oth= er > > > choice. This looks good. > >=20 > > Am also not really happy with this but have found so far no better soluti= ons. > > Should i place the script to /etc/fcron.daily/ ? Would make sense i think. >=20 > Yes. > Above topic link also contains example of a full Certificate Autorithy manage= ment using standard OpenSSL functionalities - I generated ROOT CA, Intermedia= ry 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 ver= y fast - at each an every service start. =20 > > >=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 whe= n the > > > system is not being rebooted in a while. So it has to be checked regula= rly > > > which > > > requires a cron job. > >=20 > > 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 wi= thout > > some specific interactions, the CRL expires and all connections are over = and > > done until the CRL has been renewed. >=20 > Yes. >=20 > >=20 > > >=20 > > > Setting the expiry date to infinity would slightly ruin the idea of a C= RL. > >=20 > > Yes this would make no sense at all. > >=20 > > > > > Peter has proposed a patch recently with improved crypto, please wo= rk > > > > > 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/ > >=20 > > Thanks for pointing that out.=20 > > I did also changes regarding the "vpn weak" warnings but this changes inc= ludes > > more then the DH-parameter. > > As above mentioned 6 from 12 the currently available on IPFires OpenVPN a= re > > deprecated cause there can be attacked via Sweet32. OpenVPN implemented > > "reneg-bytes 64000000" with v. 2.3.13 which forces frequent rekeying afte= r 64 > > MB data transfer, this can lead to a lot more rekeying cycles then the one > > hour cycle which is the regular behavior. >=20 > 64MB? That is once a second over a Gigabit link. Or roughly every 5 to 6 se= conds > over a 100M link. >=20 > 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 ba= ckup file moved between same file servers over N2N. I did had lzo activated - and lzo got an upgrade on 2.4, but after reading ab= ove change is more likely that speed decrease is due to rekeying cycles. > > All that can somehow be neglected with the cipher-negotiaion and newer cl= ients > > since there will then be used anyways AES-256 which is a 128 bit block ci= pher. > >=20 > > 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=C2=B4t crash anything. >=20 > Okay. So please let's get that patch merged then. >=20 > > 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 on= ly > > after then the server can be started again. > > openvpnctrl do provides only stop|start but no save option do you know so= lve > > this via command line parameter while the update ? >=20 > We can stop all OpenVPN instances on the command line. >=20 > For RW this is: openvpnctrl -k >=20 > And for all N2N connections that is: openvpnctrl -kn2n >=20 > >=20 > >=20 > > Again thanks for your feedback and help. > >=20 > > Greetings, > >=20 > > Erik > >=20 > > >=20 > >=20 >=20 > -Michael >=20 > >=20 Hope it helps, --=20 Horace=20 --===============1076992721225012816==--