OpenVPN setting: Compression - No Preference

[JohnDoe17]

Can someone verify my understanding, please?  (I'm trying to implement mitigations against VORACLE attack.)

Setting "Compression" to "No Preference" actually *disables* compression in OpenVPN, correct?  I.e., it omits both the legacy "comp-lzo" and the newer-but-still-not-recommended "compress" options, right?

I wish the terminology used for this setting was a bit clearer, but apparently this is a complaint I should take up with OpenVPN not OPNsense  ;) as it seems to be their definition.

JD17

[JohnDoe17]

Anyone have any thoughts on this?

Specifically, what OpenVPN options does OPNsense's "No Preference" translate to?

Is there a way I can turn on debugging or look at log files or something to figure this out?

Thanks.

JD17

[mimugmail]

You can compare the output of config in folder /var/etc/openvpn

[benyamin]

Apologies for necroposting...  :-[

Was just reviewing this since we moved to OpenVPN 2.6...

When setting compression to No Preference, the runtime configuration does not list --compress empty, i.e. compress, instead there is no compression option at all. This effectively disables compression. This is important because an empty compression parameter would still enable packet framing for compression and allow a different parameter to be set later. An empty compression parameter also permits lzo and lz4 compression to be used - which is certainly not desirable!

Should this behaviour not be assigned to a new None/Disabled parameter in the GUI, with No Preference simply adding the compress option to the runtime configuration...? Hard one to change without an upgrade script to set all previous configurations using No Preference to None/Disabled (for potential security reasons).

I'm curious whether adding allow-compression no (vanilla OpenVPN's default) enables stub and stub-v2 framing and compression when compress isn't enabled. It's worth noting this setting might interfere with compress migrate but I haven't tested same. YMMV.

EDIT: To retract my comments about renaming above. I hadn't noticed the Partial option in the GUI, which is equivalent to --compress (empty) and used to prepare the compression frame. Moreover, peers can still negotiate or get pushed other compression options, so No Preference is a reasonable description.

[hushcoden]

@benyamin, can you then clarify which the best selection would be, e.g. No Preference or Legacy - Disabled LZO algorithm (--comp-lzo no) or?

Tia.

[benyamin]

@benyamin, can you then clarify which the best selection would be, e.g. No Preference or Legacy - Disabled LZO algorithm (--comp-lzo no) or?

Tia.

No Preference appears to disable compression instead (by removing the compress option), which is important in the mitigation of VORACLE attacks.

If you don't specify comp-lzo, then comp-lzo adaptive (the default) should not be enabled. As an aside the use of comp-lzo with comp-noadapt is likely the same as comp-lzo yes...  ::) Using comp-lzo no is not compatible with compress or compress stub, with the latter potentially enabled with the use of allow-compression no.

Regarding allow-compression, per my post below above, the default is allow-compression no, which is not intuitive at all...! I think it best to not specify allow-compression no, but allow-compression asym might be beneficial in migration away from the use of compression (in conjunction with compress migrate) - but only in that scenario.

Confused yet...?  :o ???

Let me see if I can clarify...

The VORACLE wiki page at OpenVPN says:

If a soft migration is not needed you can remove all comp-lzo and compress from all clients and server configs to disable compression.

So my take is that if you don't specify any comp-lzo, compress or allow-compression options, then compression will not be enabled and you will have mitigated VORACLE attacks. I guess the only caveat here is that you might get PUSHed those options by a server that doesn't respect the client. In that case, something like the following might be needed to ensure mitigation:

Code Select Expand

pull-filter ignore comp
pull-filter ignore allow-compression


Clear as mud...?

You can also find more information in the Reference Manual For OpenVPN 2.6.

[benyamin]

I should point out that I have one VPN server that PUSHes me comp-lzo no, and because the frame is changed it has often been subject to replay attacks looking to exploit the compression.

Using pull-filter ignore comp on this VPN prevents traffic from traversing the tunnel even though it comes up. I basically don't trust it anymore.

Currently seeing if the vendor will remove the option. Prayers for a miracle will be greatly appreciated...

[hushcoden]

Unfortunately I'm not so technical, and as I'm using the client side (with Proton VPN), I'll leave it as No preference  ::)

Thanks.

[benyamin]

Unfortunately I'm not so technical, and as I'm using the client side (with Proton VPN), I'll leave it as No preference  ::)

;D

You may want to check your VPN log (at VPN: OpenVPN: Log File in the GUI) to see if the PUSH statement contains any compress or comp-lzo keywords. If so, ProtonVPN could be forcing you to use compression and you might be subject to VORACLE attacks. I doubt ProtonVPN would do this, but yYou would be well advised to check. To find any PUSH statements just type in "push" (without the quotes) in the search box at the top of the Log File page. Searching for "comp" might also be revealing.

EDIT: To show ProtonVPN do push --comp-lzo no, at least on some servers.

[hushcoden]

Nice learning, thank you  :)

I've attached both searches, "push" and "comp" and I can see that comp(ression) is there, and it means bad or good ?

Also, I don't understad why 'client1' is not listed as it's actually the only one online - client2 and client3 are for now disabled (not running)...

[benyamin]

Based on the timestamps, are the client2 & client3 messages old and perhaps from when they were enabled?

Are those two clients a different vendor, i.e. not ProtonVPN...?

As for client1, it would appear it is neither being pushed nor using compression, but perhaps peruse a screen after searching for "client1" to see what is happening.

[hushcoden]

Based on the timestamps, are the client2 & client3 messages old and perhaps from when they were enabled?

I believe so

Are those two clients a different vendor, i.e. not ProtonVPN...?

No, I use only Proton VPN: client1 is configured with UK servers, client2 with US servers and client3 for Canada servers - essentially, I switch between any of those countries depending of what I want to stream- but maybe there is a more elegant way to do so?  ::)

As for client1, it would appear it is neither being pushed nor using compression, but perhaps peruse a screen after searching for "client1" to see what is happening.

hmm the list for client1 is huge (attached firts page)

[hushcoden]

And another screenshot attached.

Is there a way to embed pictures in the actual body of the message?

[benyamin]

hmm the list for client1 is huge (attached [first] page)

You might need to restart the service for that client to regenerate some useful log entries. Perhaps first change the Verbosity Level under Advanced Configuration to 5 (very last option). This will restart the client anyway when you click Save. Being the same vendor, it will likely have the same PUSH command.

I can see that comp(ression) is there, and it means bad or good ?

US and Canada servers are definitely pushing --comp-lzo no which will alter the compression frame. The Data Channel log entry for these shows compression: 'stub', which is likely just a compatibility match for this preparation of the compression frame. Nefarious actors listening for those frames might then note your tunnel as a potential target. It doesn't mean they will get anywhere, but you could be subject to attacks.

You could try adding pull-filter ignore comp to the advanced options, but I suspect when the tunnel comes up it won't work as the server is unlikely to respect the client. Probably worth a try though...

[benyamin]

I retracted my previous comments above re renaming No Preference to None/Disabled above.

It might be better to remove any ambiguity about runtime compression options by updating the configuration page to include OpenVPN v2.5+ options and v2.6 defaults. The addition of --allow-compression in v2.5 adds an additional factor when determining resultant runtime configurations, as does the change in defaults from --allow-compression asym to --allow-compression no in v2.6.

The lack of --compress migrate in the drop-down list in the GUI could mean other undesirable options could be negotiated instead.

It's also worth noting that from OpenVPN 2.6.2 a client will now refuse a connection if pushed compression settings contradict the setting of --allow-compression as this almost always results in a non-working connection.

In OpenVPN 2.6, the combination of the default --allow-compression no and an unconfigured compression setting, i.e. No Preference, should mean no compression is requested and only a stub type option can be negotiated or pushed. However, unlike stub-v2, the stub option changes the compression frame so is equivalent to --compress in that regard.

Therefore, in the case of a server, the best option might well be a combination of the default --allow-compression no and --compress migrate; and in the case of a client, the best option might well be a combination of the default --allow-compression no and --compress stub-v2 if you want to make sure that the compression frame is undetectable (which might happen if pushed a different option).

As such, relying on the v2.6 default of --allow-compression no might mean an additional GUI knob is not required; and there is an argument to remove the No Preference option (the counter-argument is that this option is useful between trusted peers).