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: Thu, 18 Jan 2018 11:07:27 +0100 Message-ID: <4D586AC4-D78A-4120-B753-575E38BD4500@ipfire.org> In-Reply-To: <1516107371.3647.111.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2040100836396142396==" List-Id: --===============2040100836396142396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 t= his >> 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. Since IPFire do provides openvpn-plugin-auth-pam.so we should be OK with scri= pt-security 2 instead of 3 but as you suggested, we can do this also later.=20 >> So should i leave the the switch for '--ncp-disable' option out of the WUI= ?=20 >> 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 >=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. This is exactly what 'ncp-ciphers AES-256-GCM:AES-256-CBC' do (the cipher lis= t is expandable, see for an example how Fedora did this --> https://fedorapro= ject.org/wiki/Changes/New_default_cipher_in_OpenVPN#Detailed_Description ). T= he negotiation checks if the client is AES-256-GCM ready if not AES-256-CBC w= ill 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 di= rectives will be used. To make it a little clearer, all that is managed by th= e negotiation so i think it would makes a lot of sense. >=20 > 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 whic= h cipher is available on the other side and uses it (pushable) which is a kin= d 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 a= nymore the find and use the least common multi of all clients. >=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. Done. All changes are meanwhile made and ready to push. Nevertheless we need = one new directive for this (--ncp-disable) otherwise OpenVPN uses --ncp-ciphe= rs per default. Important for me, also if the time is now kind of short, to point that more c= learly 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 mo= re clear view of potential bugs it might be a good way for the first but i th= ink we should change this in one of the coming updates.=20 >=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? OK, let=C2=B4s doing it. >=20 >> Since the choice of the cipher is an important setting it might be great i= n my >> opinion the give the users at least a possibility (in the advanced settings >> 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. Will push it after this correspondence and an OK from you. >=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. Will search for some reference to refer to. >> Yes we would need "--ncp-ciphers ALGs" for this new feature. Generally i t= hink >> this could be a security/performance gain for a lot=C2=B4s of people out t= here >> 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. >=20 > 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. The negotiation do not work for N2N connections since N2N do not operate in P= 2MP mode. This is also showing up in the logs. Sun Jan 14 08:15:35 2018 disabling NCP mode (--ncp-disable) because not in P2= MP client or server mode Have nevertheless added GCM for N2N too. May there can also be done some cosm= etics since the HMAC menu on N2N is useless if GCM will be used (default SHA2= 56). 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=C2=B4s a future sound i t= hink. >> 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 n= eeds >> to be something done too. >> But i=C2=B4am calmed a little down if this changes are not released with t= he next >> Core update. >=20 > Just test :) We will see what breaks. Will do surely do this if the testing is available or the language cache prob= lem has been resolved. >>> If the CA or some client certificates have expired, this is what we would >>> expect, isn't it? >>=20 >> Exactly. >=20 > 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. >>>>=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 incl= udes >> 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. >=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? 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=C2=B4s of clie= nts with big throughput it can possibly feel a little like an unstable connec= tion... >=20 >> All that can somehow be neglected with the cipher-negotiaion and newer cli= ents >> since there will then be used anyways AES-256 which is a 128 bit block cip= her. >>=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. Have used the way Peter used it with the additional 'weak' entry for the resp= ective 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 chan= ged later on. As above mentioned, will push the changes after this exchange and an OK from = you. >=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 only >> after then the server can be started again. >> openvpnctrl do provides only stop|start but no save option do you know sol= ve >> 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 Michael, this won=C2=B4t 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/i= pfire/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/i= pfire/ovpn/openssl/ovpn.cnf =20 fi fi in the core updater (update.sh). There is the need for an active OpenVPN serv= er 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: Unrecogniz= ed 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 infor= mation. 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 m= achines 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 cou= ple of hours with a not working OpenVPN server if the background why that=C2= =B4s 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 o= vpn.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=3D27&t=3D20= 180 that the changes in ovpn.cnf is missing, whereby ovpnmain.cgi do serves a= ll changes. Might it be an idea to ship the changed ovpn.cnf --> https://git.ipfire.org/?= p=3Dipfire-2.x.git;a=3Dblob;f=3Dconfig/ovpn/openssl/ovpn.cnf;h=3D40daf2a0a886= dd4957df00c3303d3504f8cb0bc0;hb=3Db66b02ab73863bcb9130300d8ef0eecdc51efde3 ag= ain ? 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 m= ore time i will respond also to your ideas. --===============2040100836396142396==--