Juniper SSL VPN login fails

[Tom Metro]

David Woodhouse wrote:
>Tom Metro wrote:
>> Failed to read from SSL socket: Rehandshake was requested by the peer.
> 
> Right. The Juniper server asks for a rehandshake when it decides it
> wants to see a client certificate - even if you already offered one in
> the initial connection. Which we do but their client presumably
> doesn't.
> 
> We need to make our code handle that.

So this is either a known limitation you've encountered already, or at
least logically follows based on what you know about the behavior of the
OpenConnect code? OK, then at least we don't need to go hunting for the
underlying cause.

I haven't looked up the SSL terminology to know the distinction between
a renegotiation and a rehandshake (if there is one), but isn't it
logical that the server would want to see the client's credentials if
the parameters of the link are being reexamined?


> You could probably do that as a
> quick hack without much difficulty. 

./openconnect --version

reports:
OpenConnect version v7.05
Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP
software token, TOTP software token, DTLS

So I gather I'd start by looking in the GnuTLS related files. Although...

I can't find "Rehandshake was requested by the peer" in the code. Is
that an error message generated by GnuTLS? I see similar error messages
in other source files:

cstp.c:	vpn_progress(vpninfo, PRG_ERR, _("Rehandshake failed; attempting
new-tunnel\n"));
dtls.c:	vpn_progress(vpninfo, PRG_ERR, _("DTLS Rehandshake failed;
reconnecting.\n"));
oncp.c:	vpn_progress(vpninfo, PRG_ERR, _("Rehandshake failed; attempting
new-tunnel\n"));

auth-juniper.c suggests that it might be using code in oncp.c for the
transport, and oncp.c seems to be the layer at which rehandshake
problems are addressed (I was expecting to find that in the ssl.c or
lower layer), and oncp.c seems to sit above gnutls.c (is ssl.c another
layer in the middle?). If that's correct, then the modification needs to
go into oncp.c, and should be applicable to either GnuTLS or OpenSSL.

Am I anywhere close to being on the right track?


> ...make sure it works sanely with both GnuTLS and
> OpenSSL builds of OpenConnect.

Do you have reason to believe the fix will be library specific?


> Before actually committing it I'd
> want to familiarise myself with the insecure handshake security issues
> from last year and make sure that whatever we do isn't opening a
> vulnerability...

Sure. There are versions of that problem dating back to 2009:
http://itknowledgeexchange.techtarget.com/Irregular-Expressions/ssl-tls-renegotiation/

 -Tom