Submitted via IRC for Fnord666
A new attack named VORACLE can recover HTTP traffic sent via encrypted VPN connections under certain conditions.
The attack was discovered by security researcher Ahamed Nafeez, who presented his findings at the Black Hat and DEF CON security conferences held last week in Las Vegas.
[...] VORACLE is not a new attack per-se, but a variation and mix of older cryptographic attacks such as CRIME, TIME, and BREACH.
In those previous attacks, researchers discovered that they could recover data from TLS-encrypted connections if the data was compressed before it was encrypted.
Fixes for those attacks were deployed in 2012 and 2013, respectively, and HTTPS connections have been safe ever since.
But Nafeez discovered that the theoretical points of those attacks were still valid when it came to some type of VPN traffic.
Nafeez says that VPN services/clients that compress HTTP web traffic before encrypting it as part of the VPN connection are still vulnerable to those older attacks.
There are 3 workarounds listed: (1) switch to a non-OpenVPN protocol, (2) stay away from HTTP websites (HTTPS traffic is immune), or (3) use a Chromium-based browser.
(Score: 4, Interesting) by ikanreed on Monday August 20 2018, @02:36PM (1 child)
It seems like compression should pre-emptively optimize the level of data entropy. Encryption of entropic data should be equally entropic data without any sort of predictable context. The article just repeats the claim over and over that compression makes it work and should be turned off.
But I want to know what it could possibly expose. Is there some kind of compressed header that's larger than the chunk size of the encryption routine that's always the same(that you could then compare against a rainbow table to ID a key)? What's the deal?
(Score: 4, Informative) by Anonymous Coward on Monday August 20 2018, @05:11PM
e.g. You can sniff someone's session cookie: https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks-openvpn3-voracle.gif [defcon.org]
PDF: https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/Nafeez/DEFCON-26-Nafeez-Compression-Oracle-attacks-on-VPN-Networks.pdf [defcon.org]
(Score: 2) by Whoever on Monday August 20 2018, @03:03PM
4. Disable compression in the OpenVPN configuration.
(Score: 0) by Anonymous Coward on Monday August 20 2018, @05:30PM (1 child)
1) no thanks.
2) already do that mostly, but i'll pay more attention. a browser option to block with click through option would be nice.
3) no thanks.
i like the other poster's #4
(Score: 0) by Anonymous Coward on Monday August 20 2018, @09:09PM
Hoperfully WireGuard [phoronix.com] makes this obsolete.
(Score: 1, Informative) by Anonymous Coward on Monday August 20 2018, @05:58PM (1 child)
Why does using chromium fix it:
So, the key part would be to split requests into header and body packets.
(Score: 3, Interesting) by coolgopher on Tuesday August 21 2018, @01:23AM
Unless Chromium actually sets the PSH flag when it writes the headers, there's no guarantee that the network stack won't merge the packets containing header and body data. And the browser really shouldn't be messing around at that low a level.