| | 1 | = [DRAFT] VORACLE attack and OpenVPN = |
| | 2 | |
| | 3 | == Background == |
| | 4 | |
| | 5 | Security researcher Ahamed Nafeez has [https://speakerdeck.com/skepticfx/voracle-compression-oracle-attacks-on-vpn-tunnels presented a new attack vector] which targets VPN tunnels which utilizes compression, named **VORACLE**. The attack vector bares similarities to the CRIME and BREACH attacks, which hit especially HTTPS based connections. |
| | 6 | |
| | 7 | The crux of this attack is the compression feature OpenVPN has had support for since the early OpenVPN v1.x days, in various ways. The compression feature is being enabled when you use one of the following configuration options: |
| | 8 | |
| | 9 | * `--comp-lzo` |
| | 10 | * `--comp-lzo yes` |
| | 11 | * `--comp.lzo adaptive` |
| | 12 | * `--compress lzo` |
| | 13 | * `--compress lz4` |
| | 14 | * `--compress lz4-v2` |
| | 15 | |
| | 16 | Configurations *NOT* using `--comp-lzo` or `--compress` are *NOT* affected by VORACLE. |
| | 17 | |
| | 18 | === Simplified Example === |
| | 19 | The example mentioned here is not the only possible attack against encryption + compression. It is also very simplified to explain the principle of attacks like VORACLE, CRIME and BEAST. |
| | 20 | |
| | 21 | 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. |
| | 22 | 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 message, she gets a pretty good idea how close her guesses are as the encrypted message gets shorter when her guesses get better. |
| | 23 | |
| | 24 | Without compression the length of the encrypted packets does not change, so Eve cannot gain any information. (Strictly speaking the length changes if Eve's password length changes but that gives no additional information) |
| | 25 | |
| | 26 | The real world attacks are more complicated and need to take in account the specific circumstances (e.g. HTTPS or VPN) but they rely on the same principle as demonstrated in this simple example. |
| | 27 | |
| | 28 | === Compression is **NOT** enabled by default === |
| | 29 | |
| | 30 | It is important to know that compression has never been enabled by default. An OpenVPN configuration (implying both the local and remote side) must explicitly enable compression. |
| | 31 | |
| | 32 | These options here covers what is called the OpenVPN Data Channel in the wire protocol. The data channel is used to transfer network traffic from one side to the other side. OpenVPN also uses a Control Channel, where the TLS protocol is used. OpenVPN has disabled compression explicitly inside the Control Channel explicitly since OpenVPN 2.3.9 and OpenVPN 2.4.0 when compiled against OpenSSL. The compression on the Control Channel is not configurable. OpenVPN compiled against mbed TLS and PolarSSL has no support for modifying compression on the Control Channel, but it is disabled by default in the compiling process of the mbed TLS/PolarSSL library. No payload packets are send over this channel and communication is strictly between openvpn server and client, makeing chosen plaintext like BEAST, CRIME and VORACLE extremely difficult for the Control Channel. |
| | 33 | |
| | 34 | == Mitigaion == |
| | 35 | |
| | 36 | The compression feature in OpenVPN is dynamic and by using the `--compress` or `--comp-lzo` options, the wire protocol used between the OpenVPN clients and server changes slightly, to encapsulate packets in what is referred to a _compression frame_. This does not mean data this frame carries is always compressed, but it *might* be compressed, all depending on a flag in the frame header. |
| | 37 | |
| | 38 | It is important to remember that `--comp-lzo` or `--compress` must be used on both the local and the remote side. If only one side uses any of these options, it will not be a functional VPN tunnel. Further, `--comp-lzo` and `--compress` have overlapping feature support, meaning that `--compress lzo` is identical to `--comp-lzo yes`or `--comp-lzo adaptive`. |
| | 39 | |
| | 40 | To mitigate the VORACLE attack you can thus disable compression in the configuration file without breaking other connections during a gradual configuration update. And *ONLY* use these options *if* you already use `--comp-lzo` or `--compress` in your configuration. |
| | 41 | |
| | 42 | === Community edition: OpenVPN 2.3.x and OpenVPN 2.4.x === |
| | 43 | If a soft migration is not needed you can remove all comp-lzo and compress from all clients and server configs to disable compression. |
| | 44 | |
| | 45 | On the server side use: |
| | 46 | - OpenVPN 2.4.0 newer and only OpenVPN 2.4.x or newer clients: Use `--compress stub-v2` and `--push "compress stub-v2"` |
| | 47 | - OpenVPN 2.3.X and older: Use `--comp-lzo no` and `--push "comp-lzo no"` |
| | 48 | |
| | 49 | |
| | 50 | This ensures the server will not initially try to use compression, and tells clients to not use it either. All of this keeps the compression framing intact and ensures backwards compatbility with clients not pulling in pushed options. |
| | 51 | |
| | 52 | On the client side: |
| | 53 | The client side configuration' compression needs to match the server configuration (either explicit with the right `compress`/`comp-lzo` config option or implicit through pushed option). A client side mitigation is therefore currently not possible in all scenarios without upgrading the client. |
| | 54 | |
| | 55 | - OpenVPN 2.4.0 and newer, and server respecting client capabilities: |
| | 56 | |
| | 57 | This is only valid for servers that respect the capabilities that the client sends to it (for example OpenVPN Access server) |
| | 58 | |
| | 59 | |
| | 60 | replace the `comp-lzo no` option with `comp-lzo stub`. |
| | 61 | |
| | 62 | |
| | 63 | This will stop the client from annoucing compression support (via `IV_LZO=1`, `IV_LZ4=1` etc) and only advertises stub support. |
| | 64 | |
| | 65 | If your connection stops working after this change your server does not respect the client capabilities. |
| | 66 | |
| | 67 | |
| | 68 | |
| | 69 | === Commercial products: Access Server === |
| | 70 | |
| | 71 | The compression feature is enabled by default. It can be disabled under Advanced VPN, "Default Compression Settings" setting. |
| | 72 | |
| | 73 | The same can be achieve via the command line: |
| | 74 | |
| | 75 | /usr/local/openvpn_as/scripts/sacli --user '__DEFAULT__' -k prop_lzo -v false UserPropPut |
| | 76 | |
| | 77 | Access Server allows also to set compression on a per user basis. If a user setting is present, it overrides the default setting. |
| | 78 | |
| | 79 | For a client side mitigation replace the `comp-lzo no` in the client config with `compress stub`. |
| | 80 | |
| | 81 | === Commercial products: OpenVPN Connect === |
| | 82 | |
| | 83 | Inside the OpenVPN Connect app, open the left-side menu inside the "Access Server" and "OVPN Profile" sections and click on the "Settings" menu item. Scroll down to the "Compression" |
| | 84 | section and select "Downlink Only". This will ensure that the client will not try to compress any packets but still accepts compressed packets if |
| | 85 | |
| | 86 | |
| | 87 | === Commercial products: Private Tunnel === |
| | 88 | |
| | 89 | Neiter the Private Tunnel app nor the service facilitates the compression feature, no need to change anything. |
| | 90 | |
| | 91 | == But I really need compression == |
| | 92 | In most cases this is more a perceived need than a real need. |
| | 93 | |
| | 94 | - Most traffic is not compressible since it either already compressed (e.g. large downloads) or is encyrpted and cannot be compressed |
| | 95 | - VPN compression is fairly inefficient compare to normal compression. Only one packet at a time (~1400) is compressed. It is always better compress data at a higher protocol layer |
| | 96 | |
| | 97 | |
| | 98 | == The plan forward == |
| | 99 | |
| | 100 | There are on-going discussions in the [https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17417.html OpenVPN developers community] on how to resolve this better in future releases. Changes will be applied to both the OpenVPN 2.x community versions, OpenVPN 3 Core library. These changes will also propagate into our commercial offering as new defaults. |
| | 101 | |
| | 102 | There is consensus about disabling compression by default when the local OpenVPN process sends data to a remote OpenVPN process, but will accept compressed packets from the remote side. This is called asymmetric compression. The advantage of this approach is that it does not break any existing configurations. The `--comp-lzo` and `--compress` options will then primarily just enable the compression framing and the `lzo` and `lz4` options which `--compress` takes defines the decompression algorithm needed to use. |
| | 103 | |
| | 104 | Currently the biggest disagreement is if it should be allowed or even possible to enable symmetric compression - which allows the local side to compress the data it sends to the remote side. |
| | 105 | |
