Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
On 27/08/18 14:46, David Sommerseth wrote: > 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. Meh ... Just to clarify ... It needs to be *reversed*, is what I tried to type. Also forgot to mention the USE_COMP macro as well. -- 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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
I agree with Arne on this one. I’m OK with a warning, but I don’t think we should make it impossible. This is where nasty forks start to show up because we broke something upstream (recall the day s of the lack of password-save in our Windows client). Eric F Crist > On Aug 27, 2018, at 03:10:31, Derek Zimmer wrote: > >> That is a terrible idea. The intention is good but users will then opt >> out of encryption because they want compression or build stacked VPNs. > > That was the point of the idea though. If you want to go that far to > go around security, you are very aware of the consequences of what > you're doing. If we don't want to force the users hand, a big and ugly > warning that shows up when compression + encryption is enabled may > lead to the same end result. > > In my opinion as long as the user is acutely aware of the risks and we > make the documentation and warnings very clear, the project is as safe > as it can be from user error driven security suicide. > Derek Zimmer > Chief Executive Officer > Open Source Technology Improvement Fund > > > On Mon, Aug 27, 2018 at 2:25 AM, Arne Schwabe wrote: >> Am 27.08.18 um 00:55 schrieb Derek Zimmer: >>> There's always the option of not allowing encryption to be enabled >>> with compression enabled. This keeps things like using OpenVPN as >>> fancy proxy working without endangering the privacy VPN use-case. >> >> That is a terrible idea. The intention is good but users will then opt >> out of encryption because they want compression or build stacked VPNs. >> >> Arne > > -- > 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 signature.asc Description: Message signed with OpenPGP -- 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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
>That is a terrible idea. The intention is good but users will then opt >out of encryption because they want compression or build stacked VPNs. That was the point of the idea though. If you want to go that far to go around security, you are very aware of the consequences of what you're doing. If we don't want to force the users hand, a big and ugly warning that shows up when compression + encryption is enabled may lead to the same end result. In my opinion as long as the user is acutely aware of the risks and we make the documentation and warnings very clear, the project is as safe as it can be from user error driven security suicide. Derek Zimmer Chief Executive Officer Open Source Technology Improvement Fund On Mon, Aug 27, 2018 at 2:25 AM, Arne Schwabe wrote: > Am 27.08.18 um 00:55 schrieb Derek Zimmer: >> There's always the option of not allowing encryption to be enabled >> with compression enabled. This keeps things like using OpenVPN as >> fancy proxy working without endangering the privacy VPN use-case. > > That is a terrible idea. The intention is good but users will then opt > out of encryption because they want compression or build stacked VPNs. > > Arne -- 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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
Am 27.08.18 um 00:55 schrieb Derek Zimmer: > There's always the option of not allowing encryption to be enabled > with compression enabled. This keeps things like using OpenVPN as > fancy proxy working without endangering the privacy VPN use-case. That is a terrible idea. The intention is good but users will then opt out of encryption because they want compression or build stacked VPNs. Arne -- 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
