On Mon, Oct 3, 2016 at 9:24 PM, Peter Brant <peter.brant at gmail.com> wrote: > It turns out the problem was caused by changing the DTLS cipher > security level from Medium to High on the ASA. Setting it back to > Medium has fixed the problem. > My co-worker noted that with High, the only enabled cipher was > DHE-RSA-AES256-SHA. With Medium, the following are also enabled: > > DES-CBC3-SHA > AES128-SHA > DHE-RSA-AES128-SHA > AES256-SHA > DHE-RSA-AES256-SHA > The server is now returning X-DTLS-CipherSuite: AES256-SHA. > I must confess my knowledge of encryption is rudimentary. Is the High > selection even reasonable? If so, might it be supported in a later > version of OpenSSL? That seems like a problem in ASA (that we will have to work-around unfortunately). They must have updated openssl, and as you describe openssl disables the non-DHE ciphersuites for DTLS. However, for DTLS the anyconnect protocol doesn't really use DHE (or RSA key exchange) at all. It treats the key exchange as a session resumption based on a key derived from the TLS session. So disabling AES256-SHA in HIGH level doesn't buy anything with regards to security for DTLS, it just makes interoperability harder. Fortunately we are moving away from that DTLS negotation at ocserv-openconnect [0] to a sane one, that will not have these issues. Unfortunately we will need these hacks on the client side to keep the communication with cisco servers possible. regards, Nikos [0]. https://tools.ietf.org/html/draft-mavrogiannopoulos-openconnect-00
