From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: [PATCH v2] OpenVPN: Introduce new AES-GCM cipher for N2N and RW Date: Thu, 15 Feb 2018 07:09:04 +0100 Message-ID: <1518674944.19288.46.camel@ipfire.org> In-Reply-To: <1518639831.15001.12.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2590318212168036100==" List-Id: --===============2590318212168036100== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, and thanks for your feedback. Am Mittwoch, den 14.02.2018, 20:23 +0000 schrieb Michael Tremer: > Hi, >=20 > On Wed, 2018-02-14 at 20:11 +0100, ummeegge wrote: > >=20 > > 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=C2=A0 > I do not get any of those arguments in that email. I find that highly > useless > for a legitimate use of VPNs. >=20 Not sure what you exactly mean with 'useless' ? 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). 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. > >=20 > > 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. >=20 Sure CTR is different to GCM but according to=C2=A0OpenVPN-2.4 manpage=C2=A0 --> https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage ( under '--tl= s-crypt keyfile' )=C2=A0 it encrypts but also authenticates. Logs from testings with --tls-crypt, AES-GCM for N2N looked like this: Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1530]: disabling NCP mode (--ncp-disa= ble) because not in P2MP client or server mode Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1530]: OpenVPN 2.4.1 i586-pc-linux-gn= u [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Apr=C2=A0= =C2=A05 2017 ... Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encry= ption: Cipher 'AES-256-CTR' initialized with 256 bit key Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1531]: Outgoing Control Channel Encry= ption: Using 256 bit message hash 'SHA256' for HMAC authentication Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encry= ption: Cipher 'AES-256-CTR' initialized with 256 bit key Apr=C2=A0=C2=A07 16:59:58 ipfire UE2n2n[1531]: Incoming Control Channel Encry= ption: Using 256 bit message hash 'SHA256' for HMAC authentication ... Apr=C2=A0=C2=A07 17:00:04 ipfire UE2n2n[1531]: Data Channel Encrypt: Cipher '= AES-256-GCM' initialized with 256 bit key Apr=C2=A0=C2=A07 17:00:04 ipfire UE2n2n[1531]: Data Channel Decrypt: Cipher '= AES-256-GCM' initialized with 256 bit key Apr=C2=A0=C2=A07 17:00:04 ipfire UE2n2n[1531]: Control Channel: TLSv1.2, ciph= er TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA Apr=C2=A0=C2=A07 17:00:04 ipfire UE2n2n[1531]: [xxx.xxx-gateway.de] Peer Conn= ection Initiated with [AF_INET]91.192.xxx.xxx:61000 Apr=C2=A0=C2=A07 17:00:05 ipfire UE2n2n[1531]: Initialization Sequence Comple= ted 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. Sorry for the longer term thinking and possible confusions. Greetings, Erik --===============2590318212168036100==--