Slashdot Mirror
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."
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."
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.
Learning HOW to think is more important than learning WHAT to think.