The VORACLE attack vulnerability

Description

Security researcher Ahamed Nafeez has ​presented a new attack vector which targets VPN tunnels which utilize compression, named VORACLE. The attack vector bears similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections.

It has been discovered that it is possible to gain information about an encrypted VPN tunnel's contents in very specific circumstances, if an attacker has the ability to capture the encrypted data packets while a certain type of data is transferred through the VPN tunnel. By that we mean that if a VPN user visits for example an unencrypted HTTP website through an encrypted VPN tunnel, and this information is being compressed and encrypted through the VPN tunnel, certain clues about the contents of this information can still be gathered if the encrypted packets can be captured and analysed, and data can be fed through the VPN tunnel by the attacker. To explain this better, following below is a simplified example. The example mentioned here is not the only possible attack against encryption combined with compression, and it is also very simplified, but it is useful to explain the principle behind attacks like VORACLE, CRIME and BEAST.

Let's say Alice has setup a login page. To check passwords entered there, Alice sends a message like "tell me if <the password entered> matches <secret password>" to Bob. This information between Alice and Bob is sent through an encrypted VPN tunnel that also uses compression. The more similar the <the password entered> is to <secret password> the better this message compresses. If the attacker Eve can ask Alice to verify passwords and can see the length of the encrypted VPN messages, she gets a pretty good idea how close her guesses are, since the encrypted messages get shorter when her guesses get better.

Without compression the length of the encrypted packets does not change, so Eve cannot gain any information from this. Strictly speaking the length changes if Eve's password length changes but that gives no additional information. The real world attacks are more complicated and need to take in account the specific circumstances (for example HTTPS or VPN) but they rely on the same principle as demonstrated in this simple example.

Mitigation

Due to the fact that exploiting such an attack is not trivial, we are not treating this situation as an emergency. For now, it is advised that users of the OpenVPN Access Server and the OpenVPN Connect Client software disable the use of compression. This effectively makes exploiting this vulnerability impossible. This can very easily be done on the OpenVPN Access Server by going to the admin web interface, and going to Advanced VPN. There you can disable compression. The client connection profiles may still provide an instruction to enable compression, but it will be disabled if the server denies the use of compression.

For open source OpenVPN users, we direct you to the community wiki article regarding VORACLE.

Resolution

There are still discussions ongoing on how exactly in the open source OpenVPN project compression will be disabled, but for now in our commercial products we will be disabling compression by default in future releases of Access Server. We intend to make it so that when people update their OpenVPN Access Server, or install a fresh Access Server installation, the default setting will be that compression will be disabled. We will also be hiding and disabling the compression feature in later releases of OpenVPN Access Server and work on phasing it out entirely over time, as there is at this time simply no secure method of guaranteeing the security of the data in all situations while compression is enabled.

Our Private Tunnel cloud service had compression switched off already, so is not affected by this issue.

If you wish to disable compression on your own Access Server, go to the admin web interface, go to Advanced VPN, and switch off support for compression.