On 02/14/2014 11:24 AM, David Woodhouse wrote: > On Thu, 2014-02-13 at 22:53 -0800, Kevin Cernekee wrote: >> If I set method "ssl" or "new-tunnel", the result is the same: > >> X-CSTP-Rekey-Method: new-tunnel >> X-DTLS-Rekey-Time: 240 >> >> This could be a bug, or maybe it means the "ssl" method isn't >> implemented on this firmware version. > > Perhaps the SSL renegotiation method got deprecated around the time of > CVE-2009-3555. CVE-2009-3555 is unrelated to renegotiation as used in anyconnect. The issue with renegotiation was when combined with https as a method of "upgrading" credentials through renegotiation (e.g., provide your client certificate only at a specific url through renegotiation). It seems that (at least some of) the anyconnect clients when they encounter the 'ssl' variant, they do renegotiate on the tcp channel, and for some reason tear and reconnect the DTLS channel (they could have had issues renegotiating the DTLS session the way they establish it). ocserv could handle that mode as well as it considers the TCP channel the primary. That way we could support a channel that doesn't re-establish itself at rekey time. However, I find the tearing apart and re-establishment of the DTLS channel a waste. Would it make sense to have a mode 'oc-ssl' that will rehandshake on both channels? regards, Nikos
