Supporting Juniper and other types of SSL VPN

[David Woodhouse]

A few people have been asking about supporting Juniper SSL VPN in
OpenConnect, and there are others like Vyatta which might also be
relevant.

I was originally a bit reluctant to support other VPNs in OpenConnect —
applying the Unix philosophy of "do one thing, and do it well."

However, I've mostly changed my mind. The Cisco protocol-specific parts
of OpenConnect are probably only about 10% of it now, surrounded by all
the rest of the infrastructure you need to make a viable VPN client on
all platforms under the sun — tun device handling, HTTP and SOCKS proxy
support with NTLM/Kerberos/Digest/Basic authentication and libproxy for
discovery, certificate handling with PKCS#11 and TPM support, OTP
support for software and hardware tokens, etc.

So I think I'd be happy enough to look at abstracting out the specific
SSL VPN protocol parts and making OpenConnect support multiple
protocols. The main sticking point is that we actually need some details
about *how* those other SSL VPN protocols works. Someone needs to either
get proper documentation, or watch the traffic and see how they
communicate. Watching HTTPS traffic should be fairly simple with
something like mitmproxy¹ or just by pointing the client at your own
running 'openssl s_server' and seeing what it says, then using 'openssl
s_client' to say the same thing to a real server².

I think OpenConnect can be fairly flexible and support whatever we
discover. The only slight problem we might have is if we can no longer
make the assumption that you can split authentication from the actual
connection, with a "cookie" or something equivalent being the result of
the former, and used to make the latter. If you need to keep the *same*
connection open throughout authentication and the real VPN, then
certainly the NetworkManager support would need to be somewhat
rearchitected. But I think we can cope with that, and the new protocol
can actually have its *own* NM support anyway that just happens to also
use {lib,}openconnect as the back end.

I'm happy to look at merging whatever we discover, but someone else is
going to have to work out the protocol first.

I've added some people to Bcc who have enquired in private email. This
is probably best taken to the mailing list...

-- 
dwmw2

¹ https://mitmproxy.org/
² Use -crlf since HTTP needs CRLF line endings.

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