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

[Kevin Cernekee]

On Mon, Feb 17, 2014 at 11:41 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On a second read, I think my changes conflict with:
> a1e3914fd0f469640a323da63715e8abf764a3a0
>
> The latter sets the rekey method in TLS to be the same as the CSTP rekey
> method, while in 14d807f58d2ca82f60505ef92115258c2d26da3f I assumed that
> DTLS will have rekey method of NONE and will be reconnected at the CSTP
> rehandshake/reconnect.

Agreed - we can revert my change in dtls.c.  It would be nice to have
a block comment somewhere explaining why dtls_times.rekey_method ==
REKEY_NONE doesn't actually mean DTLS never gets rekeyed.

Also, start_cstp_connection() can still change the DTLS parameters.
I'd assume we need to call dtls_reconnect() unconditionally after
cstp_reconnect() to allow for this, or go back to calling dtls_close()
upon master secret regeneration.  But it's OK to skip dtls_handshake()
after cstp_handshake(), provided that dtls_times.rekey_method !=
REKEY_NONE.

This still leaves the question of whether it is safe to rekey DTLS via
dtls_reconnect() / dtls_try_handshake(), or if we actually need to
send a new master secret first?  What do the Cisco clients do?  Maybe
the master secret regeneration could be moved elsewhere.

Absent a full CSTP reconnection, how should dtls_times.last_rekey get updated?

If keepalive_action() only returns KA_REKEY for REKEY_TUNNEL, will the
new REKEY_SSL logic in dtls.c ever run?

FWIW I set a 4-minute rekey interval on my ASA, disabled all rekeying
in openconnect, and ran it overnight with no obvious problems.  But I
would hate to break somebody else's configuration, because these "VPN
quits passing traffic after 3 days" problems are very frustrating to
debug.