Hello, first of all. May it is better to wait with the introduction of AES-GCM until OpenSSL-1.1.0g + OpenVPN-2.4.4 has been released, or what do you think ?
On Wed, 2018-02-14 at 20:11 +0100, ummeegge wrote:
As a version 3 idea, or might it be possibly a better idea to delete the '--auth *' directive in N2N.conf if AES-GCM has been chosen ? i think it might also be better to integrate '--tls-crypt' --> https://www.mail-archive.com/openvpn- devel@lists.sourceforge.net/msg12357.html
I do not get any of those arguments in that email. I find that highly useless for a legitimate use of VPNs.
Not sure what you exactly mean with 'useless' ?
I thought some of that is a bit esoteric cryptography.
:D i see, you are also right this is a kind of esoteric in the true sense of the word (designed for or understood by the specially initiated alone ;) .
Hiding the TLS connection makes sense when you are in China behind the big state-run firewall, but that is about it.
Not only, to some extend the Heartbleed vulnerability for example was not exploitable with an active --tls-auth (--tls-crypt serves the same mechanism) --> https://community.openvpn.net/openvpn/wiki/heartbleed but OpenVPN do also strongly encourage to use such protections --> https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth .
I mean I am not against it, but this is pretty useless and probably only creates many confusing configuration options for the average user.
Have integrated it some months ago in my environment (works here without problems) and it can be activated via one checkbox https://people.ipfire.org/~ummeegge/screenshoots/OpenVPN-2.4_beta2/N2N_tls-c... same like --tls-auth which IPFire serves for Roadwarriors since 2 or 3 years meanwhile.
Just to clarify, --auth HMAC is also used by --tls-auth which serves a separate layer of authentication protection for the control channel (to mitigate DoS attacks and attacks on the TLS stack).
--tls-crypt is a new feature in v2.4 which not only authenticates (like --tls-auth do), but also encrypts the TLS control channel (more privacy) but uses AES-256-CTR instead of the --auth HMAC (also called "poor-man's" post-quantum security).
I am never a fan of non-standard cryptography. Has this been properly peer- reviewed?
I think it has also been reviewed while the v2.4 security evaluation from Quarkslabs and PrivateInternetAccess https://blog.quarkslab.com/resources/2017-05-11-security-assessment-of-openv... take a look into the 'Recommendations' section under '2. Executive Summary' . But it is also meanwhile widely used on other distros e.g. https://redmine.pfsense.org/issues/7071%C2%A0 but also by some VPN providers i think.
Both options are currently not available for N2N but may in the future. So i thought it might be better to delete the '--auth HMAC' directive in N2N.conf if GCM has been selected.
GCM already has the authentication built in.
This are two different layers of security in my opinion whereby both directives do offers a 2nd line of defense if a future flaw is discovered in a particular TLS cipher-suite or implementation, whereby --tls-crypt encrypts also the control channel. A little deeper explanation can also be found in the hardening wiki or in here http://archive.openvpn.net/pipermail/openvpn-devel/2016-July/024892.html for a little more info causing --tls-crypt .
The --tls-crypt is something that should never be enabled by default. But if you want to have it, add it.
Think so and i haven´t it enabled by default, integrated it in the same way as --tls-auth is already integrated, ticking a checkbox and ready.
But as mentioned this is a future sound of music and i would wait with this since there are more important things i think (--ncp-cipher, AES- GCM integration, deprecated directives such as comp-lzo, ...).
Most important for me was to come to a decision for the AES-GCM patch if i should delete the 'auth' directive (needed only for --tls-auth since it use the same HMAC then the old ciphers) if a GCM cipher has been chosen and i think i will do this to keep the house clean so to say ;-).
Greetings,
Erik