--dtls-ciphers=LIST option not working

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20180704/f9e3fecf/attachment-0001.bin>


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux