Juniper SSL VPN login fails

[David Woodhouse]

On Sun, 2015-04-12 at 19:02 -0400, Tom Metro wrote:
> 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,

Yes, I've been given admin access to a spare server and had briefly
configured it for certificate auth — and had seen the behaviour you
report.

> 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?

If the client presented its credentials when it first made the
connection, there doesn't seem to be any reason to trigger a
renegotiation just to see the same information *again*.

> 
> > 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:

GnuTLS returns the GNUTLS_E_REHANDSHAKE "error" code when we attempt
to read from the socket. We are expected to react accordingly, if we
want to actually do the renegotiation. Try the patch below.

...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?

Yes, but actually the OpenSSL build seems to renegotiate all by itself
without requiring the application to do anything. So probably all we
need is this:

diff --git a/gnutls.c b/gnutls.c
index 3f79a22..bf20b41 100644
--- a/gnutls.c
+++ b/gnutls.c
@@ -148,6 +148,10 @@ static int openconnect_gnutls_read(struct openconnect_info *vpninfo, char *buf,
                        vpn_progress(vpninfo, PRG_DEBUG, _("SSL socket closed uncleanly\n"));
                        return 0;
 #endif
+               } else if (done == GNUTLS_E_REHANDSHAKE) {
+                       int ret = cstp_handshake(vpninfo, 0);
+                       if (ret)
+                               return ret;
                } else {
                        vpn_progress(vpninfo, PRG_ERR, _("Failed to read from SSL socket: %s\n"),
                                     gnutls_strerror(done));
@@ -203,6 +207,10 @@ static int openconnect_gnutls_gets(struct openconnect_info *vpninfo, char *buf,
                                ret = -EINTR;
                                break;
                        }
+               } else if (ret == GNUTLS_E_REHANDSHAKE) {
+                       ret = cstp_handshake(vpninfo, 0);
+                       if (ret)
+                               return ret;
                } else {
                        vpn_progress(vpninfo, PRG_ERR, _("Failed to read from SSL socket: %s\n"),
                                     gnutls_strerror(ret));


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150413/923e8993/attachment.bin>