testing a new SSL+ESP VPN

[Daniel Lenski]

On Tue, Oct 4, 2016 at 11:16 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> Sounds like you've made good progress with understanding this.
>
> What happens if the ESP channel *cannot* be established? Does it keep
> talking over TCP? That's one of the main advantages of an SSL VPN,
> surely?

Indeed, it does keep talking over TLS if I block the relevant UDP
port. It starts the connection via "GET /ssl-tunnel-connect.sslvpn"
and I can see the encrypted traffic in Wireshark.

However, if I try to force the TLS tunnel through mitmproxy, it errors
out. I suspect this is because mitmproxy tries to buffer the entire
request/response, and doesn't know how to handle a long-running "GET"
connection which neither side closes.

>
> For Juniper, I got the TCP mode working, and *then* added ESP support.
>

I found this gem of a comment in http.c ... I suspect I may be dealing
with something similar here. Do you have any suggestions for
intercepting the TLS traffic? Perhaps my first guess should be that it
uses precisely the same stream format as Juniper :-p.

        /*
         * A long time ago, I *wanted* to use an HTTP client library like cURL
         * for this. But we need a *lot* of control over the underlying SSL
         * transport, and we also have to do horrid tricks like the Juniper NC
         * 'GET' request that actaully behaves like a 'CONNECT'.
         *
         * So the world gained Yet Another HTTP Implementation. Sorry.
         *
         */

> It can be done with 'ip xfrm', something like this:
> https://gist.github.com/vishvananda/7094676
>

Wow! ip xfrm appears to be just what I need. I'll give that a shot
before I dive into the openconnect code.

> You might do better just to go ahead and add it to OpenConnect though.
> Forget the HTTPS and XML config part for now; just hard-code it for now
> so that 'obtain_cookie' and other methods do nothing but return
> success, and set up an ESP connection with *fixed* parameters from your
> manual testing. Then you can flesh out the HTTPS/XML parts later, if
> you want to do it in that order.
>
> The ESP parts of OpenConnect are *mostly* generic, without any Juniper-
> specific bits in them. The main case I see where that's *not* true is
> where we use Juniper-specific numbering in vpninfo->esp_enc and
> vpninfo->esp_hmac, and the trick where we send zero-length data packets
> as a probe, and expect those back from the server before we consider
> the connection 'established' over UDP.

Good to know. It appears that this VPN uses the exact same combination
of aes-128-cbc and hmac-sha-1-96, although the Windows client proposes
other cipher suites as well.

-Dan