On 27/08/18 14:46, David Sommerseth wrote:
On 24/08/18 21:16, Gert Doering wrote:
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".
The only thing I am willing to agree to here, is that we have very different
views of how to ensure OpenVPN provides a secure VPN solution and how to
achieve that goal.
From my point of view, in the moment a VPN is susceptible to not provide a
solid protection of a connections content, it is no longer a Virtual _Private_
Network. It is just a virtual network. And that is an entirely different
product.
I'm not going to argue the other points of yours, as I do not see this leading
this discussion forward. I just disagree with your point of view and think
they do not move OpenVPN in the right direction of the security requirements
of the 21th century. My stance is clear: Compression and encryption does not
belong together.
I don't think anyone disagrees with you taht compression+encryption is
unsafe. However, the dangers or compression+encryption are overstated,
IMHO.
However, I happen to agree with Gert that OpenVPN is a Swiss army knife
VPN toolbox, and if one of those tools makes a user's VPN unsafe, then
so be it. I have good use for disabling encryption in a VPN tunnel -
fully well knowing that it makes things unsafe. I may be warned about
this, but if a tool prohibits me from doing something stupid then it is
IMO a bad tool.
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.
Wrong. We have those #ifdefs already, it just needs to be reverted and add an
additional logic in configure.ac to "unlock" unsafe features. Look for
ENABLE_LZO and ENABLE_LZ4 in the code.
And I still believe features which enables known attack vectors mandates
compile time configuration. Those sites really requiring this feature should
be capable of rolling their own builds.
Further, some metrics would be good to have in this discussion as well:
- How efficient is compression on today's tunnels? Both in special use case
scenarios as well as the more common and average use cases.
- How many sites demands and depends on compression, where their use case
really results in a noticeable results with compression?
This kind of metrics is the only thing which truly can make me reconsider my
view. And it needs to be a considerable amount of use cases, as it is waste
of time and energy to keep specific features alive if there is just 2-3% of
the user base really needing and requiring it - especially when the risk for
weakened security for the 97-98% of users is considerably higher.
These are interesting metrics - and I suspect that for more users
compression does more harm than good in terms of performance. However, I
do not think it is up to the developers (you/we) to decide whether a
user can enable encryption or not.
But, there is one aspect we have not touched. Things are moving forward with
the transport plug-in patches, even though the primary goal currently is to
handle obfuscation. It should be investigated whether compression can be put
in as part of this plug-in API. This means you can have your compression
feature and the core of OpenVPN itself can be without compression. I will not
object to such an approach.
A transport plugin to handle encryption/obfuscation would work, I guess,
but then you run into the problem of running OpenVPN with "safe" or
"unsafe" plugins - should we warn users about that? prohibit it? Again,
I would not like a tool that prohibits me from doing stupid : that's the
whole Unix/Linux philosophy I guess. Since when can I not type in
rm -rf /
any more ? did someone build in a flag into the "rm" command to stop me
from doing so? I sure hope not.
JM2CW,
JJK
------------------------------------------------------------------------------
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
