Supporting Juniper and other types of SSL VPN

[David Woodhouse]

On Sun, 2015-01-04 at 00:01 +0100, Nikos Mavrogiannopoulos wrote:
> On Thu, 2015-01-01 at 10:29 +0000, David Woodhouse wrote:
> > 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.
> 
> I'm not sure I like that. What is juniper SSL VPN? Is it a protocol
> worth implementing or is yet another unstudied protocol which may be
> insecure?

It's unstudied as yet. At a high level, it looks like it starts off very
similar to AnyConnect — authentication and setup over HTTPS, with a
fallback option to carry traffic over the HTTPS connection too.

Obviously it has a UDP transport that it'll use where it can — although
its UDP transport is actually ESP not DTLS.

>  As it is now openconnect is both a protocol and program.

Well, OpenConnect is still fairly fundamentally an implementation of the
Cisco AnyConnect protocol. We've made some relatively minor tweaks to be
compatible with improvements that you've made in ocserv, but that's it.

If you want to fix the protocol more intrusively as you describe below,
I suspect you may diverge from the original goal of OpenConnect so far
that we will *already* need it to be an implementation of two different
VPN protocols, even without looking at Juniper :)

>  Both are known to be reasonably secure. I wouldn't like openconnect
> at some point to transparently negotiate pptp for me.

Yeah, we wouldn't want that.

Maybe we'd split out the generic parts into a separate library, keeping
the Cisco-specific parts in libopenconnect and using the new library
from that. Then the other protocol can also use the same generic
library.

So you'd still have *only* the AnyConnect protocol in {lib,}openconnect
almost exactly as it is at the moment, while another library and
executable could support the other protocol but without reimplementing
the 90% of OpenConnect that *isn't* protocol-specific.

Or maybe the divergence ends up being so small that we'd still actually
build a single library+executable, and add a new 'protocol' field to
openconnect_vpninfo_new(), and either a --protocol argument to
openconnect(8) or perhaps make it look at argv[0] to see which protocol
to support.

Either way, it probably doesn't make a huge amount of sense to speculate
too wildly until we've seen the details of the protocol — which people
are going to have to work out if they want a decent Linux client, even
if they *do* end up writing one from scratch without using a single line
of OpenConnect code.

> Said that, I'd like the current openconnect protocol to be better, and
> standardized, and it is one of my goals this year to write a draft
> description of the protocol, possibly enhancing it as well by
> eliminating the hacks from it, like the openssl string negotiation, and
> the explicitly transferred DTLS key.

I'd like that too, but I don't think Cisco are going to be at all
interested. Which leaves us either constrained to being compatible with
their protocol (including future developments of it which might even be
*intended* to break us), or accepting that we have forked it
incompatibly.

-- 
dwmw2
-------------- 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/20150103/aa6a1364/attachment.bin>