Juniper SSL VPN login fails

[Nikos Mavrogiannopoulos]

On Tue, 2015-04-14 at 13:29 +0100, David Woodhouse wrote:
> On Tue, 2015-04-14 at 15:07 +0300, Nikos Mavrogiannopoulos wrote:
> > Indeed. Re-authentication cannot happen transparently in an application,
> > i.e., suddenly the server or client change identity and no-one is
> > notified. The fact that gnutls insists on explicit re-authentication by
> > the application, protected applications from attacks like the triple
> > handshake attack and the other re-handshake-based attacks on TLS.
> 
> ... which is why I need to think hard about the fact that my patch
> automatically just *does* the renegotiation whenever it's asked to.
> And check it'll do the right thing if the server identity changes, etc.

The safest approach is to check gnutls_safe_renegotiation_status() and
only allow renegotiation if it is in use. That way you can be assured
that you will be talking to the same server as the first negotiation
(i.e., the server didn't forward the connection somewhere else). If that
is not available (e.g., if the juniper servers are too old to support
safe renegotiation) you may have to resort into checking that the
certificate presented remained the same.

> And might also want to limit the circumstances in which it tolerates
> renegotiation at all — only when talking to a Network Connect server,
> and only at certain points in the connection.

That's what I do in ocserv as well, mostly to prevent DoS attacks by
clients who ask for renegotiation too many times.

regards,
Nikos