testing a new SSL+ESP VPN

[David Woodhouse]

On Tue, 2016-10-04 at 12:16 -0500, Daniel Lenski wrote:
> 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.

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

This proxy should do it:
http://tiebing.blogspot.co.uk/2013/06/golang-ssl-server-and-client-example.html


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

I doubt that. Hell, I *hope* not; the Juniper NC protocol is just
*awful*. Read oncp.c and weep.


> > 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 may be wasting effort there; personally I'd just go ahead within
OpenConnect rather than fighting 'ip xfrm' and tunnel setup.

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

For Juniper I just started with the TCP connection (relying on the DSID
cookie being passed in from outside), then I could add ESP and the
authentication support as separate independent new features. You might
find that's the easiest option.

-- 
dwmw2

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