On 4 July 2018 at 10:07, David Woodhouse <dwmw2 at infradead.org> wrote: > > 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. Hi David. Sorry for the wall of text:-) but this is what I get when I use '--dtls-ciphers=OC-DTLS1_2-AES256-GCM' X-CSTP-Version: 1 X-CSTP-Server-Name: ocserv 0.11.9 X-CSTP-DPD: 90 X-CSTP-Address: 10.65.94.55 X-CSTP-Netmask: 255.255.0.0 X-CSTP-DNS: 8.8.8.8 X-CSTP-DNS: 4.2.2.2 X-CSTP-Tunnel-All-DNS: false X-CSTP-Keepalive: 32400 X-CSTP-Idle-Timeout: none X-CSTP-Smartcard-Removal-Disconnect: true X-CSTP-Rekey-Time: 172825 X-CSTP-Rekey-Method: ssl X-CSTP-Session-Timeout: none X-CSTP-Disconnected-Timeout: none X-CSTP-Keep: true X-CSTP-TCP-Keepalive: true X-CSTP-License: accept X-DTLS-DPD: 90 X-DTLS-Port: 22 X-DTLS-Rekey-Time: 172835 X-DTLS-Rekey-Method: ssl X-DTLS-Keepalive: 32400 X-DTLS-Session-ID: XXXXXXXXXXXXXX (no idea might be sensitive info so I blanked this line) X-DTLS-CipherSuite: OC-DTLS1_2-AES256-GCM X-DTLS-MTU: 1340 X-CSTP-Base-MTU: 1406 X-CSTP-MTU: 1340 X-DTLS-Content-Encoding: lzs X-CSTP-Content-Encoding: lzs CSTP connected. DPD 90, Keepalive 32400 CSTP Ciphersuite: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM) DTLS option X-DTLS-DPD : 90 DTLS option X-DTLS-Port : 22 DTLS option X-DTLS-Rekey-Time : 172835 DTLS option X-DTLS-Rekey-Method : ssl DTLS option X-DTLS-Keepalive : 32400 DTLS option X-DTLS-Session-ID : XXXXXXXXXXXXXX (no idea might be sensitive info so I blanked this line) DTLS option X-DTLS-CipherSuite : OC-DTLS1_2-AES256-GCM DTLS option X-DTLS-MTU : 1340 DTLS option X-DTLS-Content-Encoding : lzs DTLS initialised. DPD 90, Keepalive 32400 Connected as 10.65.93.110, using SSL + lzs DTLS handshake timed out DTLS handshake failed: Resource temporarily unavailable, try again ----------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- If I use '--dtls-ciphers=PSK-NEGOTIATE' all goes well and it uses the OC-DTLS1_2-AES256-GCM Cipher. So this might just be the server declining a valid string OR PSK-NEGOTIATE is the only valid string allowed for DTLS 1.2. I believe from reading through the lines you confirmed that PSK-NEGOTIATE is the only valid option? A use case would be to prevent the use of weak ciphers or prefer a less powerful cipher if speed is the priority. Although admittedly, I also like the control.
