Hi, On Thu, 2018-02-15 at 07:09 +0100, ummeegge wrote: > Hi, > and thanks for your feedback. > > Am Mittwoch, den 14.02.2018, 20:23 +0000 schrieb Michael Tremer: > > Hi, > > > > 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(a)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. Hiding the TLS connection makes sense when you are in China behind the big state-run firewall, but that is about it. I mean I am not against it, but this is pretty useless and probably only creates many confusing configuration options for the average user. > 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? > 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. > > > > > > > instead of '--tls-auth' to N2N connections which uses a static AES- > > > 256-CTR > > > whereby > > > a HMAC can not be selected ? > > > > The counter mode does not provide authentication like GCM does. > > > > Sure CTR is different to GCM but according to OpenVPN-2.4 manpage > --> https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ( under ' > --tls-crypt keyfile' ) > it encrypts but also authenticates. So this is basically using a static key and then running the TLS connection through it? Usually there will be a DH key exchange and a classic TLS connection. And who wants to use CTR mode when you can have GCM? This can only be to speed things up a bit because messages are now being encrypted twice. > Logs from testings with --tls-crypt, AES-GCM for N2N looked like this: > > Apr 7 16:59:58 ipfire UE2n2n[1530]: disabling NCP mode (--ncp-disable) > because not in P2MP client or server mode > Apr 7 16:59:58 ipfire UE2n2n[1530]: OpenVPN 2.4.1 i586-pc-linux-gnu [SSL > (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr 5 2017 > > ... > > Apr 7 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encryption: > Cipher 'AES-256-CTR' initialized with 256 bit key > Apr 7 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encryption: > Using 256 bit message hash 'SHA256' for HMAC authentication > Apr 7 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encryption: > Cipher 'AES-256-CTR' initialized with 256 bit key > Apr 7 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encryption: > Using 256 bit message hash 'SHA256' for HMAC authentication > > ... > > Apr 7 17:00:04 ipfire UE2n2n[1531]: Data Channel Encrypt: Cipher 'AES-256- > GCM' initialized with 256 bit key > Apr 7 17:00:04 ipfire UE2n2n[1531]: Data Channel Decrypt: Cipher 'AES-256- > GCM' initialized with 256 bit key > Apr 7 17:00:04 ipfire UE2n2n[1531]: Control Channel: TLSv1.2, cipher > TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA > Apr 7 17:00:04 ipfire UE2n2n[1531]: [xxx.xxx-gateway.de] Peer Connection > Initiated with [AF_INET]91.192.xxx.xxx:61000 > Apr 7 17:00:05 ipfire UE2n2n[1531]: Initialization Sequence Completed > > > So i would a kind of prepare this a little for a potential future > (deleting --auth from N2N.conf if GCM is used) but if there is a > decision in the future to use --tls-auth, the HMAC selection makes > sense even we use GCM. But since --tls-crypt uses only AES-256-CTR the > HMAC selection is useless if GCM has been chosen. Let's focus on things that are useful for the average user first. I think --tls- auth does not add anything extra when using GCM, but it doesn't harm anyone either. The --tls-crypt is something that should never be enabled by default. But if you want to have it, add it. > > Sorry for the longer term thinking and possible confusions. > > Greetings, > > Erik > >