testing a new SSL+ESP VPN

[Daniel Lenski]

On Tue, Oct 4, 2016 at 1:47 PM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> 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.
>
> Yeah, you want to do it one SSL record at a time, and forget about
> doing it in terms of HTTP request/response. Like Juniper, you have an
> HTTP GET request that never ends.
>
>
> At least Cisco had the decency to call this a 'CONNECT' request :)

Gotcha. Clearly more than one brilliant mind has thought, "IP over TCP
is such a beautiful idea. Let's add HTTP and make it even more
beautiful."

>> 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.
>
> Sounds good. Can you share some (slightly redacted) XML from the
> negotiation... in fact, can you share the *entire* negotiation from
> start to finish, and I'll opine on how it can fit into the OpenConnect
> auth + connection model?

Here's the authentication process as logged by mitmproxy, with
identifying information and keys redacted or bowdlerized:
https://gist.github.com/dlenski/5046e5f934ac111e8d8718fc10c25703

It's extremely verbose, what with the XML and all, but this does make
it pretty straightforward to interpret the IPsec configuration with
confidence.

I probably won't have any more time to play around with it until the weekend.

-Dan