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
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 Openvpnfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/openvpn-devel