public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH v2] OpenVPN: Introduce new AES-GCM cipher for N2N and RW
Date: Thu, 15 Feb 2018 10:59:30 +0000	[thread overview]
Message-ID: <1518692370.15001.39.camel@ipfire.org> (raw)
In-Reply-To: <1518674944.19288.46.camel@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 4868 bytes --]

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
> 
> 

  reply	other threads:[~2018-02-15 10:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 12:45 [PATCH] " Erik Kapfer
2018-02-14 14:28 ` ummeegge
2018-02-14 14:40 ` [PATCH v2] " Erik Kapfer
2018-02-14 19:11   ` ummeegge
2018-02-14 20:23     ` Michael Tremer
2018-02-15  6:09       ` ummeegge
2018-02-15 10:59         ` Michael Tremer [this message]
2018-02-15 13:30           ` ummeegge
2018-02-14 20:20   ` Michael Tremer
2018-02-15  5:02     ` ummeegge
2018-02-15 10:42       ` Michael Tremer
2018-02-15 13:35         ` ummeegge
2018-02-25 13:49 ` [PATCH v3] OpenVPN: New " Erik Kapfer
2018-02-25 17:06   ` Michael Tremer
2018-02-26  6:48     ` ummeegge
2018-02-26 10:24       ` Michael Tremer
2018-02-27  6:23         ` ummeegge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1518692370.15001.39.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox