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.
> 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.
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.
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital 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 Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
