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,