[PATCH] DTLS: Add ECDHE-RSA-AES256-SHA384 as a v1.2 cipher suite

[Jason Gunthorpe]

On Fri, Jul 31, 2020 at 02:41:46PM -0700, Daniel Lenski wrote:
> On Fri, Jul 31, 2020 at 2:19 PM Nikos Mavrogiannopoulos
> <n.mavrogiannopoulos at gmail.com> wrote:
> >
> > On Thu, Jul 30, 2020 at 10:00 PM Jason Gunthorpe <jgg at ziepe.ca> wrote:
> > >
> > > If GCM is not available on the VPN server this is a reasonable fallback.
> > >
> > > Severs will not auto-fallback to older TLS if the X-DTLS12-CipherSuite is
> > > sent, so the existing non-GCM modes with the old TLS do not negotiate.
> >
> > In terms of security that's super ugly. All these CBC ciphersuites are
> > problematic in TLS1.2 due to lucky13 attacks; TLS1.3 dropped all of
> > them. It is simply too hard to make them secure and that's why they
> > are disabled by default in openconnect. Not probably helpful solution,
> > but you may want to refer your IT to good advise at:
> > https://bettercrypto.org/
> 
> I believe that the only situation where this would actually *lower*
> the security of a connection would be the case where a server supports
> *both* GCM and CBC for DTLS 1.2 ciphers, but (for some insane reason)
> chooses the CBC cipher when offered both options.
> 
> Do I have that right?

I think so.

It is already the case that openconnect will accept < TLS1.2 ciphers
including CBC versions, so I'm not sure how adding them to the TLS1.2
list makes anything less secure?

Arguably openconnect could do with a --secure-crypto option that used
only good stuff to prevent any possible downgrade attack.

Anyhow, the other work around is to use the --dtls-ciphers option to
switch into < 1.2 mode which still has the lucky13 problem and a whole
bunch of other issues too.

IT says that Cisco told them to disable GCM as it has some bug. It
will come back eventually when they get a fix. In the mean
time having a VPN would be nice, and the Windows client negotiates
this suite as the choice next in line.

Jason