On Wed, 2018-07-04 at 09:07 +0100, David Woodhouse wrote: > > > --dtls-ciphers='AES-256-GCM' > > --dtls-ciphers='AES256-GCM-SHA384' > > > > The GCM cipher is the one the server negotiates correctly when not > > using the --dtls-ciphers option. > > > > So could it be that the option does not work with DTLS 1.2? > > Please try '--dtls-ciphers=OC-DTLS1_2-AES256-GCM'. > > Also please show the full output of openconnect connecting, with '- > v', > or at least what client and server put into the X-DTLS-CipherSuite > header. > > Some background would be useful to help understand this. In the > original Cisco protocol the ciphersuite and DTLS version were hard- > coded, with the ciphersuite being exchanged over the TCP connection. > The DTLS connection then "resumed" a fake session that had never > previously existed. We added options using DTLS 1.2 and newer > ciphersuites, following this model. > > Eventually we realised this was stupid, and we should just let DTLS > negotiate a new session (including DTLS version and ciphersuites) for > itself. So now we do it differently; instead of resuming a faked > session we establish a new one, using a PreShared Key (PSK) that has > been established over the TCP connection. That is the "NEGOTIATE-PSK" > option. > > The --dtls-ciphers option that you're playing with, is what we send > over the TCP connection to the server. We send a list of the options > that we support, the server picks one and tells us which to use. > > If NEGOTIATE-PSK is chosen, nothing else from the dtls-ciphers string > is taken into account. The standard DTLS negotiation happens using > all the available ciphersuites. With the ciphersuite used already in the TLS protocol having priority. That is, it will try to use the same cipher on TLS and DTLS channels. ocserv can further enforce that with the "match-tls-dtls-ciphers = true" configuration option. I guess the different ciphersuites in both channels was since the time of RC4 in TLS which could not be used under DTLS. Today there is no reason to use different ciphers, and it would be simpler if openconnect client would eliminate the --dtls-ciphers option and only require that both channels match. regards, Nikos
