Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
> On 29-08-18 17:18, Jan Just Keijser wrote: >> 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. > > $ sudo docker run --rm debian rm -rf / > rm: it is dangerous to operate recursively on '/' > rm: use --no-preserve-root to override this failsafe > > This has been like this for a long while (and not just for debian). > > -Steffan > > PS: "rm -rf /*" will try to rm (almost) everything ;-) Still, using OpenVPN with compression makes much more sense than using "rm -rf /". I really vote against removing compression from OpenVPN! Regards, Simon -- 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 29-08-18 17:18, Jan Just Keijser wrote: > 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. $ sudo docker run --rm debian rm -rf / rm: it is dangerous to operate recursively on '/' rm: use --no-preserve-root to override this failsafe This has been like this for a long while (and not just for debian). -Steffan PS: "rm -rf /*" will try to rm (almost) everything ;-) -- 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 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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
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. This gives users the on/off switch and explicitly shows them that encryption + compression is not safe (because they have to disable it and get ugly cipher none warnings). The idea about the extra command to allow compression with a warning in the actual command itself also works well, as long as the logs throw big ugly warnings. JM2C, Derek Zimmer Chief Executive Officer Open Source Technology Improvement Fund On Fri, Aug 24, 2018 at 2:16 PM, Gert Doering wrote: > Hi, > > 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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
Hi,
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.
gert
--
"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
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
On 24/08/18 13:11, Arne Schwabe wrote:
> Hey,
[...snip...]
> - Introduce compress-direction asym|full This will control if we
> actively try to compress or just allow receiving of compressed packets
I'm not sold on this one at all.
> - change the default mode to be asymmetrical.
Agreed. Local side sends uncompressed data always, but can receive compressed
data if the remote side does send it compressed. This is the best way to
achieve backwards compatibility during a migration phase. At some point in
the future, we should also remove compression support completely (we can keep
the framing support, but never do compression)
> - If compress-direction is missing from the config but comp-lzo/compress
> are present inform the user "WARN: Compression mode set to assymetrical
> to avoid VORACLE like attacks. See the man page on compress-direction
> for more details".
If compression is enabled with --comp-lzo {yes,adaptive} or --compress
{lzo,lz4} (or rather non-empty string), such a warning is definitely
appropriate.
> 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.
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". 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!
Ignoring the fact that simply too many bloggers are generally too stupid to
understand what they write about and that Google etc are too good at finding
these blogs just tells me that NOT killing compression support will simply not
resolve the VORACLE issue in the long run. Yes, we can say "But we warned you
about it". But that's simply not good enough for me, it doesn't secure
OpenVPN in reality - WE put the gun at their feet. It's not a question "if"
but "when" blog posts will appear saying "setting this option boosted my
speedtest from 10Mbit/s to 300Mbit/s despite my DSL link being 15Mbit/s.
OpenVPN is s coool!". Because security is boring and annoying - and what
is even more boring is to try to understand why such results are completely
bogus. (I encourage anyone not believing me to hang out for a longer time on
the #openvpn irc channel).
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.
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.
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
where both is really needed and will put annoying messages in the log file -
preferably on each initiated connection. But if I see any distribution at all
enabling this by
Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle
On 24/08/18 12:11, Arne Schwabe wrote: Hey, with this mail I would like to discuss the way forward for compression. Our default configuration has not compression enabled. So our default configuration is safe from Voracle. I would like to have some feedback what the rest of you thinks This could be improved.. https://github.com/OpenVPN/openvpn/blob/a6fd48ba36ede465b0905a95568c3ec0d425ca71/sample/sample-config-files/server.conf#L254 eg: # WARNING: Enabling compression has known attacks, see VORACLE # Enable compression on the VPN link and push the # option to the client (v2.4+ only, for earlier # versions see below) ;compress lz4-v2 ;push "compress lz4-v2" # This is the recommended configuration ;compress stub ;push "compress stub" # For compression compatible with older clients use comp-lzo # If you enable it here, you must also # enable it in the client config file. ;comp-lzo # This is the recommended configuration ;comp-lzo no ;push "comp-lzo no" -- 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
Hi,
On Fri, Aug 24, 2018 at 01:11:44PM +0200, Arne Schwabe wrote:
> On top of that, a lot of the traffic that the VPN carry today is either
> already compressed or encrypted and cannot be compressed any more. So
> benefits are diminishing.
This part is true for the "I use a VPN to safely surf the web" use
cases, but not for all cases where OpenVPN is used today. So please do
not make this a "we can stop using compression because it has no benefit
anyway" argument.
[..]
> So my proposal for OpenVPN is:
>
> - Introduce compress-direction asym|full This will control if we
> actively try to compress or just allow receiving of compressed packets
> - change the default mode to be asymmetrical.
> - If compress-direction is missing from the config but comp-lzo/compress
> are present inform the user "WARN: Compression mode set to assymetrical
> to avoid VORACLE like attacks. See the man page on compress-direction
> for more details".
I can live with that, though.
In cases where you know you have compressible data (because not everything
inside the VPN is "https"), and you trust the endpoints ("LAN to LAN", or
"VPN client to corporate servers only") compression can be turned on, but
the default for unsuspecting users is "safe".
> 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.
Agree.
(To repeat my main argument here, for the sake of the archives: OpenVPN
2.x is a toolbox that suits many different purposes. One of them is
"make web surfing for clients safe, via VPN service providers" - this
is an important purpose, and making OpenVPN robust against malicious
software on the client is an important goal. But I am convinced that
OpenVPN 2.x has much bigger usefulness than this, and so we should not
only look at possible code changes and "stop users from shooting their
own feet" from this particular angle. More blunt: follow the unix
matra - "do not stop people from doing stupid stuff, because that would
also stop them from doing smart stuff")
gert
--
"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
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
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Discussion: Moving forward with compression and voracle
Hey, with this mail I would like to discuss the way forward for compression. When compression was added to OpenVPN, a lot of Internet traffic was still unencrypted and encryption+compression was thought to be good thing. With recent attack like CRIME, BEAST and VORACLE, the general consensus in the crypto community is that compression should be avoided. On top of that, a lot of the traffic that the VPN carry today is either already compressed or encrypted and cannot be compressed any more. So benefits are diminishing. Our default configuration has not compression enabled. So our default configuration is safe from Voracle. Nevertheless, a lot of configuration examples are using compression and compression is wildly used because a lot of people think it is a good idea. Our current state is sane but I still we should try to change our implementation to have a minimal attack and encourage safe configuration. Outright removing compression is not an option as it would break connection to existing client/servers that have compression enabled. OpenVPN compression has always been opportunistic compression. I.e. we only send compressed payload if compression actually has a benefit. So even with compression enabled, most of the packets that are send might actually be not compressed for incompressible content. While we cannot (ignoring pushing option for the moment) change the behaviour of the other side, we can change our own behaviour to always send uncompressed packets but still accept compressed packets. Basically asymmetrically compression. This allows to mitigate VORACLE in one direction. If both sides are using this behaviour VORACLE is mitigated. So my proposal for OpenVPN is: - Introduce compress-direction asym|full This will control if we actively try to compress or just allow receiving of compressed packets - change the default mode to be asymmetrical. - If compress-direction is missing from the config but comp-lzo/compress are present inform the user "WARN: Compression mode set to assymetrical to avoid VORACLE like attacks. See the man page on compress-direction for more details". 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. - Wording is pretty important here to not scare users too much. So the message of the warning and compress-direction are not final and might require some more thoughts. I would like to have some feedback what the rest of you thinks 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
