[GIT PULL V2] Fixes for rekeying, Android builds, etc.

[Nikos Mavrogiannopoulos]

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