New VORACLE Attack Can Recover HTTP Data From Some VPN Connections (bleepingcomputer.com)

"A new attack named VORACLE can recover HTTP traffic sent via encrypted VPN connections under certain conditions," reports Bleeping Computer, citing research presented last week at the Black Hat and DEF CON security conferences. An anonymous reader writes: The conditions are that the VPN service/client uses the OpenVPN protocol and that the VPN app compresses the HTTP traffic before it encrypts it using TLS. To make matters worse, the OpenVPN protocol compresses all data by default before sending it via the VPN tunnel. At least one VPN provider, TunnelBear, has now updated its client to turn off the compression. [UPDATE: ExpressVPN has since also disabled compression to prevent VORACLE attacks.]

HTTPS traffic is safe, and only HTTP data sent via the VPN under these conditions can be recovered. Users can also stay safe by switching to another VPN protocol if their VPN client suppports multiple tunneling technologies.
In response to the security researcher's report, the OpenVPN project "has decided to add a more explicit warning in its documentation regarding the dangers of using pre-encryption compression."

Comments

This suggests a serious weakness.

[BitterOak]

A good encryption algorithm should be able to protect any data, regardless of whether or not it is compressed. If compressing data before encryption renders the encryption algorithm insecure, I would suggest the algorithm was weak to begin with. Perhaps better, newer algorithms are needed. I'd be wary of a solution that just says "turn off compression and you'll be fine."

Re:This suggests a serious weakness.

[lsllll]

A good encryption algorithm should be able to protect any data, regardless of whether or not it is compressed. If compressing data before encryption renders the encryption algorithm insecure, I would suggest the algorithm was weak to begin with. Perhaps better, newer algorithms are needed. I'd be wary of a solution that just says "turn off compression and you'll be fine."

Huh? Neither algorithm is weak. Did you watch the slides? Each do their own thing well. This is a genius attack, in that it can brute force things like session cookies, passwords, etc.

In a way it reminds me of SQL attacks that try to find table names by going through alphanumeric and underscores one character at a time until they get the whole table name and then do whatever they want once they have the table names.

Re: This suggests a serious weakness.

[lsllll]

It didn't click for me until slide #70. Here's the link to the slides.

Re:This suggests a serious weakness.

[chill]

You're not understanding the attack. It isn't an attack on the encryption itself, but rather taking advantage of the fact that compression happens first and being able to inject some data. By injecting some data that is then compressed, and observing the change in resultant size, they can infer certain things about the encrypted payload.

For example, if the plain text is "AAAABCDEF" a simple compression tool would turn that into "4ABCDEF" before encrypting. The size changed from 9 bytes to 7.

If you can inject AAA and make it "AAAAAAABCDEF" which then compresses to "7ABCDEF", the size of the resulting encrypted string goes from 12 to 7.

Both the 7 byte streams are perfectly encrypted, but I could now infer that multiple As are part of the plaintext.

Yes, this takes the ability to inject data, hence luring to a compromised site. Yes, it takes a LOT of packets to do this, and it really only works on things like web cookies, which are 4K maximum and much smaller in practice.

But is has nothing to do with the quality of the encryption algorithm.

Re:This suggests a serious weakness.

[DarkOx]

What you don't understand is that you just described virtually every web page. This is essentially the same attacks that worked on SSL3.0 and TLS1.0 when compression was enabled.

The reason it works is that the attacker has access to 99% (roughly) of the plain text. Lets say I want to discover you bank routing number on a web page. As the attacker I register myself and discover the size and all the non-dynamic content on the page. I can inject my own content say a short string of numeric characters and compress the data. I can than observe the change in size.

Now if I am observing your network traffic and I know what site your pulling say based on the IP address. I can sit and look at the transfer size. When I see a server response the same size as one of my candidate compression tests; I now know at least one possible value for the dynamic content.

Its not a problem with the encryption algorithm. The message would not be recoverable unless I already knew almost all of it. Without thousands of cipher texts I can even begin to work out the change content. TLS address this by padding the responses with a little random length data.The trouble is the plain protocol has no padding and the VPN does not either. This can be fixed easily but its going to have a negative performance impact.

Not particularly worried here

[whoever57]

"According to Nafeez, all an attacker needs to do is to lure a user on an HTTP site. This site can be under his control, or a legitimate site where the attacker can execute malicious code â"for example, via malvertising (malicious ads).

This allows the attacker to steal and decrypt "secrets" from that site, such as session cookies, which, in turn, let the hacker log into that website as the user."

If I understand this correctly, the user has to visit a http: site under the control of the attacker and then the attacker can grab secrets associated with that site?

Re:Not particularly worried here

[lsllll]

All the attacker needs is to be able to inject something into the communication stream, pre-compression, and be able to monitor the length of the packets being sent back and forth. Over time, given that the same information is being sent over and over (think cookies), the attacker can then brute force the contents.

how realistic is this?

[hazard]

It seems that the attack requires the victim to load the same page many times, in order to measure differences in packet length? In real life, how often one visits the same page (and this page doesn't change)? If I understand this correctly, the attack will be very slow in real life, apart from some specific cases where user visits a website which reloads itself continuously.

Also, in this day and age, would anyone trust authenticated sites which do not use https? These sites themselves are the main problem.

Re:AirVPN has had compression disabled for a while

[nawcom]

And I'll just add that it's annoying that on neither TFA or on this /. post is the actual setting comp-lzo specifically mentioned. You have to interpret the patch diff linked in TFA.

To disable lzo compression, make sure "comp-lzo no" is included in the config as mentioned in my parent post.