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
