Reduce unnecessary connection-rebuilding for Juniper

The current oNCP (Juniper) protocol support sets "Connection: close" in all
HTTP requests.  This is not ideal because it requires many TLS handshakes
and round-trips, making the connection very slow to start when the latency
of the connection to the gateway is high, especially if the number of
authentication forms and redirects is large.

Simply removing the "Connection: close" header causes the oNCP connection
to fail; the server doesn't interpret the first packet sent over the oNCP
tunnel correctly (the vestigial authentication packet).

However, it appears that the "Connection: close" header *only* needs to be
specified for this final HTTP request, and not for any of the prior ones.
The presence of this header seems to signal to the gateway that it should
stop treating this as an HTTP connection, and start treating it as an
oNCP tunnel.

Tested on two different Juniper gateways, one which returns
"NCP-Version: 2" and one which returns "NCP-Version: 3" in response to
the oNCP negotiation requests.

diff --git a/auth-juniper.c b/auth-juniper.c
index acd9c77e81c80da70429da38ab828e23edd3f223..30ceb3aee80c5bf7c74df81a93bd5c2490d0fd62 100644 (file)
--- a/auth-juniper.c
+++ b/auth-juniper.c
@@ -47,7 +47,6 @@ void oncp_common_headers(struct openconnect_info *vpninfo, struct oc_text_buf *b
 {
        http_common_headers(vpninfo, buf);
 
-       buf_append(buf, "Connection: close\r\n");
 //     buf_append(buf, "Content-Length: 256\r\n");
        buf_append(buf, "NCP-Version: 3\r\n");
 //     buf_append(buf, "Accept-Encoding: gzip\r\n");

diff --git a/oncp.c b/oncp.c
index 59d2fd9819bce84b4b1d837f3b4d291f453d7acd..5690edd91354b7b64ab00c1d3f0cb33e75ba6e73 100644 (file)
--- a/oncp.c
+++ b/oncp.c
@@ -561,6 +561,11 @@ int oncp_connect(struct openconnect_info *vpninfo)
        reqbuf = buf_alloc();
 
        buf_append(reqbuf, "POST /dana/js?prot=1&svc=1 HTTP/1.1\r\n");
+       /* Seems unnecessary because we always ignore the response body,
+          and close the connection anyway, but retained in case any
+          server depends on it. (See comments on second negotiation
+          request below. */
+       buf_append(reqbuf, "Connection: close\r\n");
        oncp_common_headers(vpninfo, reqbuf);
        buf_append(reqbuf, "Content-Length: 256\r\n");
        buf_append(reqbuf, "\r\n");
@@ -572,6 +577,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
                goto out;
        }
 
+       vpn_progress(vpninfo, PRG_TRACE, _("Sending oNCP negotiation request #1\n"));
        ret = vpninfo->ssl_write(vpninfo, reqbuf->data, reqbuf->pos);
        if (ret < 0)
                goto out;
@@ -606,6 +612,13 @@ int oncp_connect(struct openconnect_info *vpninfo)
 
        buf_truncate(reqbuf);
        buf_append(reqbuf, "POST /dana/js?prot=1&svc=4 HTTP/1.1\r\n");
+       /* The TLS socket actually remains open for use by the oNCP
+          tunnel, but the "Connection: close" header is nevertheless
+          required here. It appears to signal to the server to stop
+          treating this as an HTTP connection and to start treating
+          it as an oNCP connection.
+          */
+       buf_append(reqbuf, "Connection: close\r\n");
        oncp_common_headers(vpninfo, reqbuf);
        buf_append(reqbuf, "Content-Length: 256\r\n");
        buf_append(reqbuf, "\r\n");
@@ -616,6 +629,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
                ret = buf_error(reqbuf);
                goto out;
        }
+       vpn_progress(vpninfo, PRG_TRACE, _("Sending oNCP negotiation request #2\n"));
        ret = vpninfo->ssl_write(vpninfo, reqbuf->data, reqbuf->pos);
        if (ret < 0)
                goto out;