Hi all,
Am 16.01.2018 um 13:56 schrieb Michael Tremer:
Possibly all people which uses OpenVPN as a client on IPFire are rely to this auth method cause their VPN Provider sets usually "auth-user-pass-verify" directives. Since this option is not officially supported, i think their on their own...
Well, we don't support this at the moment. And I think we should leave it like this for now since we want to release OpenSSL as early as possible.
We can add this later if we need to.
Since IPFire do provides openvpn-plugin-auth-pam.so we should be OK with script-security 2 instead of 3 but as you suggested, we can do this also later.
So should i leave the the switch for '--ncp-disable' option out of the WUI ? In that case we will reduce the ciphers on IPFire significant since OpenVPN will then use only AES-256-CBC or AES-256GCM if the clients are >=2.4.0 (which mostly are meanwhile i think) !
What are you thinking about to leave the cipher-negotiation checkbox out of the global section (in that case is all like before) but i think we should deliver at least one possibility in CCD section to disable the cipher- negotiation which would then looks like in here --> https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN- 2.4_beta2/Disable-NCP-CCD.png and is only located in the "Advanced client options" in the CCD section ?
I am not sure if this negotiation makes any sense for us. It comes a bit too late. The reason is as follows:
If someone has deployed OpenVPN in the past, they had to choose the cipher. Let's say that was AES-256-CBC. It absolutely makes no sense to add any of the weaker ciphers like AES-128-CBC. Neither for security, nor performance or compatibility. Every client must have supported AES-256-CBC in the first place.
This makes only sense in the other direction where I would want to use AES-256- GCM instead of CBC. So I could still support my clients that are on OpenVPN 2.3 and only support AES-256-CBC. But when I choose GCM, I certainly don't want any client to keep using CBC.
This is exactly what 'ncp-ciphers AES-256-GCM:AES-256-CBC' do (the cipher list is expandable, see for an example how Fedora did this --> https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN#Detaile... ). The negotiation checks if the client is AES-256-GCM ready if not AES-256-CBC will be used <-- but all that only if the client have OpenVPN 2.4.0 and above. If the client is still 2.3.x and below, the old chosen --cipher and --auth directives will be used. To make it a little clearer, all that is managed by the negotiation so i think it would makes a lot of sense.
AES-256-CBC will probably have to be set with the "cipher" option. Not sure if OpenVPN always prefers that one then.
If a 2.4.x client connects, the ncp-cipher list tries from left to right which cipher is available on the other side and uses it (pushable) which is a kind of liberation of the cipher and by the usage of GCM also for the HMAC since different algorithms can be used for specific clients and there is no need anymore the find and use the least common multi of all clients.
My point is: This is going to be complicated in the UI and giving the user a decision that they are not always competent enough to make.
So I would say we should add the new ciphers to the list and disable the negotiation for now. We won't have any disadvantages, yet.
Done. All changes are meanwhile made and ready to push. Nevertheless we need one new directive for this (--ncp-disable) otherwise OpenVPN uses --ncp-ciphers per default. Important for me, also if the time is now kind of short, to point that more clearly out. The negotiation is an advantage (possibly one of the bigger ones in the new version) compared to the old version, if we disable it to get a more clear view of potential bugs it might be a good way for the first but i think we should change this in one of the coming updates.
And after we have shipped this, we can add something to the advanced page where people can choose additional ciphers similar to the IPsec settings. So people who want to can edit this, but generally we don't give the users too many options.
Does that sound a good idea?
OK, let´s doing it.
Since the choice of the cipher is an important setting it might be great in my opinion the give the users at least a possibility (in the advanced settings section) to configure this for each client if wanted ?
Yes, see above.
But I would prefer to defer this so that we can ship OpenSSL 1.1.0 really quick now and add that with the next Core Update then. This will also allow us to ship smaller changes that shouldn't break things too easily and we can track bugs easier.
Will push it after this correspondence and an OK from you.
Above all, there are currently only 3 algorithms left on IPFire which are not affected by the Sweet32 problem (AES, Camellia and Seed which are 128 bit block ciphers).
Please mark everything as weak what is considered as such. Please add some reference in the commit message - even if that is just Wikipedia.
Will search for some reference to refer to.
Yes we would need "--ncp-ciphers ALGs" for this new feature. Generally i think this could be a security/performance gain for a lot´s of people out there especially if they are using the old and deprecated ciphers like Blowfish (old default) or the whole 3DES collection.
Actually since you raise performance: I have only considered this for roadwarrior networks, yet.
The ncp-ciphers options makes even less sense with net-to-net connections, because people control both sides of the tunnel. And then you would just want to pick one cipher and use exactly that. You don't want to leave it up to chance which cipher is used. This would also mitigate any downgrading attacks.
The negotiation do not work for N2N connections since N2N do not operate in P2MP mode. This is also showing up in the logs.
Sun Jan 14 08:15:35 2018 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode
Have nevertheless added GCM for N2N too. May there can also be done some cosmetics since the HMAC menu on N2N is useless if GCM will be used (default SHA256). N2N have currently no --tls-auth where an chosen HMAC are also used but i think this can also be done afterwards. Have integrated also --tls-crypt for N2N while my testings which works nice, --tls-auth might be also an option for N2N but that´s a future sound i think.
All tests has been done with the old OpenSSL lib. One concern for me with the new lib is if the old ovpn.cnf (OpenVPNs OpenSSL conf) is OK or if there needs to be something done too. But i´am calmed a little down if this changes are not released with the next Core update.
Just test :) We will see what breaks.
Will do surely do this if the testing is available or the language cache problem has been resolved.
If the CA or some client certificates have expired, this is what we would expect, isn't it?
Exactly.
Again, an issue where backwards-compatibility was clearly not important.
Yes but i think we found mostly some good ways around.
Peter has proposed a patch recently with improved crypto, please work together with him.
We can do this, no problem. @Peter would you write me to ummeegge at ipfire.org ?
It is here https://patchwork.ipfire.org/patch/1594/
Thanks for pointing that out. I did also changes regarding the "vpn weak" warnings but this changes includes more then the DH-parameter. As above mentioned 6 from 12 the currently available on IPFires OpenVPN are deprecated cause there can be attacked via Sweet32. OpenVPN implemented "reneg-bytes 64000000" with v. 2.3.13 which forces frequent rekeying after 64 MB data transfer, this can lead to a lot more rekeying cycles then the one hour cycle which is the regular behavior.
64MB? That is once a second over a Gigabit link. Or roughly every 5 to 6 seconds over a 100M link.
Is performance not an issue here?
It is, while rekeying no data can be transferred, if bigger DH-parameter are used the key exchange needs also longer time. If there are lot´s of clients with big throughput it can possibly feel a little like an unstable connection...
All that can somehow be neglected with the cipher-negotiaion and newer clients since there will then be used anyways AES-256 which is a 128 bit block cipher.
The SHA512 default setting changes from Peter are for N2N defaults which should be OK in my opinion since every new connection needs to be created for both sides (TLS-server and TLS-client), this should´t crash anything.
Okay. So please let's get that patch merged then.
Have used the way Peter used it with the additional 'weak' entry for the respective algorithms. Did used before the optgroup label but i thought it might be better to stay in the already given style. If wanted this can also be changed later on. As above mentioned, will push the changes after this exchange and an OK from you.
One more important thing. If we update to OpenVPN-2.4.x there is the need that the changes will be written to the server.conf (save button) otherwise the server do not start (causing the script-security entry), after i manually updated the files i needed to stop the server, hit the save button and only after then the server can be started again. openvpnctrl do provides only stop|start but no save option do you know solve this via command line parameter while the update ?
We can stop all OpenVPN instances on the command line.
For RW this is: openvpnctrl -k
And for all N2N connections that is: openvpnctrl -kn2n
Michael, this won´t work cause there is also the need to write at least two server.conf parameter (script-security 3 and ncp-disable). If there is no command which writes the changed directives from ovpnmain.cgi to server.conf (equivalent to the save button in the WUI) we would need something like this
# Add OpenVPN-2.4 directives to server.conf
if [ -e /var/ipfire/ovpn/server.conf ]; then if pgrep openvpn >/dev/null; then openvpnctrl -k sed -i -e 's/script-security 3 system/script-security 3/' -e '/status .*/ a ncp-disable' /var/ipfire/ovpn/server.conf openssl ca -gencrl -keyfile /var/ipfire/ovpn/ca/cakey.pem -cert /var/ipfire/ovpn/ca/cacert.pem -out /var/ipfire/ovpn/crls/cacrl.pem -config /var/ipfire/ovpn/openssl/ovpn.cnf openvpnctrl -s else sed -i -e 's/script-security 3 system/script-security 3/' -e '/status .*/ a ncp-disable' /var/ipfire/ovpn/server.conf openssl ca -gencrl -keyfile /var/ipfire/ovpn/ca/cakey.pem -cert /var/ipfire/ovpn/ca/cacert.pem -out /var/ipfire/ovpn/crls/cacrl.pem -config /var/ipfire/ovpn/openssl/ovpn.cnf fi fi
in the core updater (update.sh). There is the need for an active OpenVPN server to stop it, press the save button to get the changes and to start it again. Otherwise we get an
Jan 17 14:54:57 ipfire-server openvpnserver[16583]: Options error: Unrecognized option or missing or extra parameter(s) in /var/ipfire/ovpn/server.conf:10: script-security (2.4.4) Jan 17 14:54:57 ipfire-server openvpnserver[16583]: Use --help for more information.
OpenVPN-2.4.x do not start without the changed script-security directive.
Also i think the CRL should also be renewed while the update cause a lot of machines out there might have an expired CRL (last test on my machine have had that problem), the CRL update script is in fact present but the daily fcron is executed at 1:01 in the morning as far as i remember so there can be a couple of hours with a not working OpenVPN server if the background why that´s happened is not known.
One more thing Michael, possibly a little OT here but nevertheless important for OpenVPN. It seems that the last changes for the "Extended key usage" of ovpn.cnf from Core 115 has only been partly delivered. There is feedback from 3 users in the forum --> https://forum.ipfire.org/viewtopic.php?f=27&t=20180 that the changes in ovpn.cnf is missing, whereby ovpnmain.cgi do serves all changes. Might it be an idea to ship the changed ovpn.cnf --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/ovpn/openssl/ovpn.c... again ? Otherwise this feature is useless.
Some news from here. Have currently a little stress on work so my feedback on the list might come a little later.
Greetings,
Erik
P.S. Thanks to the others for their feedback (Michael Horace thanks again for your testings <-- did you know happens with your --ncp-disable issue) with more time i will respond also to your ideas.