On Sun, 2018-06-24 at 11:16 +0200, Jeroen Balduyck wrote: > It seems I caught a small break looking into this. This works and > other 'older' DLTS ciphers like AES-128 work too: > > --dtls-ciphers='DES-CBC3-SHA' => is identified as DTLS 1.0 (OpenSSL > pre 0.9.8f) in Wireshark > > These do not work when using the option: > > --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. Perhaps we could entertain a feature request to restrict that dynamic negotiation... but nobody's made a good case for it yet.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
