On Wed, Feb 12, 2014 at 2:10 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > On Tue, Feb 11, 2014 at 11:06 PM, David Woodhouse <dwmw2 at infradead.org> wrote: >>> According to their documentation it performs a rehandshake over the >>> session. That has to be verified with a cisco server though. >>> For openconnect to support that (and test it), calling >>> gnutls_handshake() over an existing session would be sufficient. >> I have a *very* vague recollection of having tried that, and it not >> being sufficient. It's been a long time though. And it might only have >> been DTLS which stopped working; that required a rekey after 24 hours. >> Which made it very painful to test, of course. > > It could be that anyconnect servers use a custom protocol to negotiate > the rehandshake. For example it could be something like a packet > 'start rehandshake' and then start the actual TLS rehandshake, but I > find it highly unlikely as it is pointless. I have modified the rekey > branch to handle redhandshakes, so I'd appreciate if somebody could > test it against a cisco server. > > As I understand one would need to set something like > svc rekey method ssl > svc rekey time 1 On my ASA running 8.4, the syntax is a little different: group-policy default attributes webvpn anyconnect ssl rekey time 4 anyconnect ssl rekey method ssl The allowed range is 4..10080 minutes. If I set method "ssl" or "new-tunnel", the result is the same: X-CSTP-Rekey-Time: 240 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. If I set method "none", all of the above headers disappear. FWIW, I still need this patch to prevent DTLS from going out to lunch after CSTP reconnections: https://github.com/cernekee/openconnect/commit/a53877ea22a546b12a9e2c30561fbd38c695532e Every time I reconnect CSTP, I receive a new DTLS session ID from the ASA.
