On Tue, Feb 18, 2014 at 12:05 PM, David Woodhouse <dwmw2 at infradead.org> wrote: > Hm, remember we don't really do a DTLS handshake at all; we bypass it > with a preset master key and session-id, and just do a session resume. > Does a re-"handshake" really do anything to change the underlying random > numbers and improve security? I know, I *implemented* this session > resume in GnuTLS. But I forget the details. Quite deliberately so :) Indeed. It's a kind of cisco's PSK implementation that behaves like resumption. The rehandshake (as well as any reconnection using the same key) will refresh the used keys (mix them with new nonces). > Also, should the CSTP rehandshake method be predicated on secure > renegotiation being available? It would be good to enable it unconditionally (now it is explicitly disabled). What a server can take advantage of when doing an unsafe rehandshake, is redirect the rehandshake to another server and make the other server believe that it is your first connection there. Openconnect could mitigate that by checking that the peer's certificate remains the same on every handshake, but I think it's much easier to enable safe renegotiation (or at least not to disable it :). regards, Nikos
