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>
