On 04/11/18 18:05, Javier Santos wrote: [...snip...] > > Based on their above four statements, how accurate are the staff's > assessments of the > VORACLE attack?> TL;DR response to their argumets: Poor and lazy attitude with poor understanding of infosec. Conclusion: Change VPN provider ASAP.
And the longer response:
> 1) The attacker needs to be on the same network as the victim. This means the
> vulnerability cannot be exploited from
> the Internet without additional exploits/attacks.
Which hits everyone being on a university wireless network, a coffee shop with
free wifi and similar. And how hard is it to set up a fake access point in a
public place? This argument is just silly.
> 2) It only works with HTTP sites - almost all critical websites now enforce
> HTTPS where the VORACLE attack does not
> work
It is true that this works with HTTP, but not necessarily only HTTP. And
while the argument that "critical websites" enforces HTTPS makes some sense,
it disregards scenarios where it is not the traffic itself which is important
- but the traffic can be used to "fingerprint" a person.
The most obvious example is using OpenVPN from behind country wide firewalls,
to detect if a person is accessing, for example, news services which normally
would be blocked - there's too many news sites around the world which goes
unencrypted [0]. But this can also be used in other scenarios to get more
information about a user to be used in other social engineering attacks. And
even though many services protects the important information with encryption,
some poorer designed sites grab insensitive "files" via http in parallel (but
I believe most browsers somehow will warn about that too).
So while unencrypted http is one of the easiest attack vectors with VORACLE,
it doesn't mean it is the _main_ attack vector.
[0] Most web browsers will nowadays warn users about using http instead of
https, but that itself is not solving VORACLE.
> 3) The attacker needs to trick the victim to visit a website that is under
> his control.
This again ignores how easy it is to setup up a fake public wifi which enables
the http traffic to be sent via a proxy service which can inject the needed
data in the http stream. This isn't even rocket science.
> 4) If you are using Chrome, you are not affected by this vulnerability.
That's just a poor and lousy argument. I'm not even going to start ranting
about that.
> For these reasons we have decided not to jump to drastic measuers and
> deactivate compression for everyone since it gives various advantages (like
> less needed bandwidth effectively resulting in faster speeds).
I read this, combined with the previous arguments as: "We don't know a sh*t
about infosec and won't bother about it."
So my conclusion is: Change VPN provider ASAP.
And a shameless ad (since I work for OpenVPN Inc) - consider PrivateTunnel
[1], a service provided by OpenVPN Inc. We take these aspects far more
serious plus it helps funding the company hiring people who also works on the
open source code which the community benefits from.
[1] <https://www.privatetunnel.com/>
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
