Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

[BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Industry news items concerning VPNs, darknets, crypto, surveillance and secure computing.
User avatar

Topic Author
parityboy
Site Admin
Posts: 1200
Joined: Wed Feb 05, 2014 3:47 am

[BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Post by parityboy » Tue Aug 21, 2018 9:58 pm

VORACLE = CRIME for VPNs

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.
Source

...and that, ladies and gents, is why HTTPS is so important. :)

User avatar

Fermi
Site Admin
Posts: 202
Joined: Tue Jun 17, 2014 11:42 am

Re: [BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Post by Fermi » Tue Aug 21, 2018 11:22 pm

We did study this attack and will take appropriate actions to disable pre-encryption compression.
Twitter and this forum will keep you up to date on the changes we are planning.

/Fermi


User avatar

df
Site Admin
Posts: 388
Joined: Thu Jan 01, 1970 5:00 am

Re: [BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Post by df » Thu Jan 03, 2019 9:03 pm

@parityboy
No, it's always been enabled, at least until Oct of last year

User avatar

Topic Author
parityboy
Site Admin
Posts: 1200
Joined: Wed Feb 05, 2014 3:47 am

Re: [BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Post by parityboy » Mon Jan 14, 2019 3:24 pm

@df

Really? All of the security-related posts here on the form have all pointed to compression being disabled (at least according to PJ and the earlier configs).

User avatar

df
Site Admin
Posts: 388
Joined: Thu Jan 01, 1970 5:00 am

Re: [BleepingComputer] VORACLE Attack Can Recover HTTP Data From VPN Connections

Post by df » Mon Jan 21, 2019 3:52 am

Ah, that's right. In the ancient 2013 post @ viewtopic.php?f=38&t=5981 PJ describes in his round-about way something that sounds an awful lot like VORACLE, which was the reason we've (almost) always had compression disabled.
IIRC, back then we had a mixture of "comp-lzo no" in the server configs and "comp-lzo" in the client configs.
The latter would normally default to "adaptive" compression, which the manual describes as:

"Adaptive compression tries to optimize the case where you have compression enabled, but you are sending predominantly incompressible (or pre-compressed) packets over the tunnel, such as an FTP or rsync transfer of a large, compressed file. With adaptive compression, OpenVPN will periodically sample the compression process to measure its efficiency. If the data being sent over the tunnel is already compressed, the compression efficiency will be very low, triggering openvpn to disable compression for a period of time until the next re-sample test."

But then the server would push "comp-lzo no", overriding the client-side "comp-lzo", essentially disabling LZO.
At least, until OpenVPN 2.4 came around. As I stated in https://cryptostorm.is/blog/new-features -

"In certain mixtures of the client running OpenVPN 2.3 and the server running 2.4, "--comp-lzo no" doesn't disable compression, it instead enables LZO compression with the stub algorithm, which means it's still vulnerable to VORACLE."

So compression might have been used in certain setups in the past.

Post Reply