[EXTERNAL] Re: Cisco recommends OpenConnect

[David Woodhouse]

On Thu, 2022-06-09 at 14:15 -0700, Daniel Lenski wrote:
> On Mon, Jun 6, 2022 at 12:54 PM Randall Sindlinger <randall.sindlinger at ssaihq.com> wrote:
> > In any case, has this and the DevNet recommendation been added to the
> > https://www.infradead.org/openconnect/
> >  page?  I'm not sure where it would best fit; but I think it
> > would be invaluable to give users and potential users the knowledge that Cisco has all but formally
> > approved it.  It sure would have helped me, at least!
> 
> Hmmm. Remind me again why "the endorsement of Cisco" is an endorsement
> that OpenConnect would want…? 😅

We don't, necessarily — the reason I wrote OpenConnect in the first
place is because Cisco's own solution for Linux fell *so* far short of
even being barely acceptable. I don't care about their 'approval'
because I have such a low opinion of them it means nothing to me.

But IT departments using proprietary VPN products clearly *do* trust
the likes of Cisco far more than we do, and the endorsement *is*
meaningful to them. So it doesn't hurt to highlight it.

Especially for individual users who are seeking "permission" to use
OpenConnect against their corporate network, the endorsement could be
very useful.


> More seriously, I'm rather equivocal about encouraging corporate
> network IT departments to replace proprietary clients with
> OpenConnect.
> 
> Those corporate network IT folks are always asking us things like,
> "Hey, OpenConnect is great! We want to use it for our whole fleet. By
> the way, can you make it so OpenConnect will check a flag sent by the
> server and then disable access to other network devices?"…
> 
> … and that's the part where I have to tell them, "Look, I'm not your
> ally here, I'm your adversary. The reason I got involved in developing
> OpenConnect was to work around all of these network security policies,
> so that I could actually Get Stuff Done on the VPNs I was connecting
> to. My primary interest in such policies is documenting and explaining
> how to evade them."

I strongly disagree with this.

OpenConnect gives you *control*, sure. It *allows* you, as a user, to
override and bypass certain policies. Strictly speaking, so do the
proprietary clients if you try hard enough; we'd just a little more
honest about it. 

But overriding security policies is *not* its raison d'être, as you
seem to be implying above. If we don't yet support those "bar all local
network access and route to the VPN so users can't even print" or "Bar
all Legacy IP/IPv6 becaue the VPN only supports the other" features,
that is a bug/missing feature and we *do* aspire to do those things by
*default*, even if we know some users might disable them.

I *absolutely* want to be the ally of corporate IT departments who want
to use OpenConnect and want to know that it *can* meet their
requirements. And does so out of the box without having to be tweaked.

We are *also* the ally of individual users who want to have control of
what's on their box, and who want to use properly integrated open
source software. And where their desires mismatch with those of their
employers, that's none of our business.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20220610/7ecc926c/attachment-0001.p7s>