On Tue, Aug 7, 2018 at 2:10 PM, Jeroen Balduyck <jeroen.balduyck at gmail.com> wrote: >> >> The server should pick the same ciphersuite as in the TLS channel. However you raise a valid point, you have no way to affect that ciphersuite right? Either in the old or the new protocol. Indeed the oc client gives >no control on the priority string used to negotiate. You can only configure it at server side. That looks like an omission. >> > > The server is definitely *not* picking the same cipher as in the TLS > channel. That TLS cipher (AES256-GCM-SHA384 ) is not being offered for > the DTLS-channel when using PSK-negotiate (as I checked using > Wireshark). So the server can't pick it for that reason. Hence, with > PSK-negotiate we arrive at AES256-CBC-SHA for the DTLS-channel. So > that's issue 1. That seems to remind some limitations of the openssl build of openconnect but I may be wrong. Are you compiling the openconnect client with openssl or gnutls? > 2nd issue is that I can use -dtls-ciphers=OC-DTLS1_2-AES128-GCM as a > parameter at client side to force a GCM cipher. Please see the replies from David and me. This only negotiates the algorithm of the DTLS part of the session _not_ the TLS, and is doing it in an unnatural way via text strings while DTLS has a robust negotiation mechanism. What openconnect client is missing is a way to set the ciphersuite preferrence of the client (in TLS or DTLS) by command line. Feel free to submit a patch to address that; note that these are already configurable if you have control on the server side. regards, Nikos
