On Fri, Aug 24, 2018 at 04:31:44PM +0200, David Sommerseth wrote:
> > Open Points:
> > 
> > - Gert strongly thinks that some people might want to continue having
> > full compression despite the risks. I think it is reasonable to expect
> > them to add 'compress-direction full' and push "compress-direction full"
> >  to the server configuration, so touching clients is not needed.
> I do disagree with Gert on this topic.  I think it is stupid to openly allow
> people to shoot themselves in the foot, even if we tell them in clear text it
> is stupid and kittens will die.  I can understand there are some use cases
> where these risks doesn't matter, but in this case this is not a strong enough
> argument to improve the overall situation for a clearly defined threat.

You do not need to agree with me on this, you just need to accept this
as a fact of life.  I will resist any change that removes useful 
functionality from the "swiss tool kit of VPN" side of OpenVPN just 
because users could "get it wrong".

I'm fine with compromising on making this an explicit "expert mode" knob.

> There are tons of blog posts on the interwebs which will get this wrong, no
> matter how much we warn about it, and users will go "oh, this blog told me to
> do so".  

We're not going to save the world, and I refuse crippling my tools because
someone else is refusing to read the manual about "do not turn on expert
mode if you do not know what this is for".

Again: OpenVPN is much more versatile than "VPN for dummies, with 
no switches provided, because someone could get them wrong".  This is 
why I am interested in this project - the flexibility of OpenVPN to 
handle setups where more "basic" VPN projects hit their limits.

> Just look at the "bypass-dhcp" flag to --redirect-gateway is widely
> found on many blog posts - including those you would thought had better
> capacity to understand that DHCP flags in a routed tun setup does not make any
> sense at all.  Yes, I am looking and pointing sharply at you Digital Ocean.
> Yes, they even tell people to build a CA on a publicly available server
> without even having the CA private key password protected (!).  And people
> blindly tag along thinking they have a safe and cool setup.  Because it works!

So we should remove X509 mode because people find bad instructions on
how to run their CA on the web?

See where your arguments lead?

> OpenVPN simply has too many users and use cases that we can consider the
> usefulness of compression which  a smaller minority group of users really can
> use safely.  There are too many who will do this wrong.

I do not care.  Really.  If people enable an expert mode switch without
reading a warning label, they get what they asked for *and this is the
way it needs to be*.

We're not removing root accounts and sudo from unix, just because people
can be told to do "curl $somesite | sudo bash", no?

> This swiss-army knife idea about OpenVPN is dangerous, because of the amount
> of possible insecure configurations.  And we have already killed off and will
> remove several options which are equally bad.  We no longer have --no-iv and
> --key-method.  We will remove several insecure ciphers (and BF is definitely
> quite fast on smaller hardware without any hardware acceleration support,
> compared to AES-128-CBC - the same "swiss-knife" argument can be applied here
> too to keep BF) ... and there will be more options too facing the same
> destiny.  Just as a parallel, SSL libraries has kicked out MD5 support for
> certificate signing, which surely could be used safely in closed laboratory
> networks where this kind of security issues does not apply.  You can find
> millions of reasons why to keep a specific feature you care for, if you just
> dig long enough.  But it does not necessarily give any valid reasons why to
> keep it.

Changing ciphers and hash algorithms does not really take functionality away.

> Therefore, my conclusion is:  We cannot keep a feature in OpenVPN which
> benefits the few but puts the larger user base at risk due to bad 
> configurations.
> Compression and encryption does not belong together.  Period.
> There is only one small tiny compromise I can be willing to consider:
>     ./configure --enable-insecure-and-risky-voracle-attack-vector \
>                 --enable-yes-I-really-know-what-I-am-doing

No, because this is silly.   By your own argument, people are not expected
to compile openvpn nowadays ("this is what distribution maintainers will
do for you"), and we're *removing* #ifdefs, not adding new ones.

I'm not here to protect users that are unwilling to read documentation.

I'm here to build and maintain a versatile VPN solution that can do 
everything that more dumbed down software can not do.

"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             g...@greenie.muc.de

Attachment: signature.asc
Description: PGP signature

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Openvpn-devel mailing list

Reply via email to