Hi Peter,

I am definitely not in Erik's class in terms of OpenVPN understanding but I have had a review of the material and here are my inputs and conclusions.

It looks to me that the primary target is going to be related to VPN server providers. The attacker has to have a connection to the same OpenVPN server as the victim is connected to.

There are two phases to the attack methodology. First a parallel connection that uses the Port Shadowing issue that has been identified to de-anonymise the victim. Then with this information the attacker can set up an OpenVPN Client to man in the middle attack. With this they then can use a recently disclosed attack (Tolley 2021) against OpenVPN servers. This allows the victim to be sent to an attacker controlled server. For this to provide something usable apparently the victim must have been trying to access a plaintext http server or the attacker has a compromised SSL/TLS certificate.

For the IPFire situation then the OpenVPN server is restricted to the people from the organisation that is running that IPFire instance. So the pool of attackers is much reduced, as is the pool of clients for the attacker to focus on.

However it still could occur in principle.

The issue occurs due to the way that netfilter and its use in NAT has been built. It is not a bug per se but an artefact of how it was built, if I understand it correctly. The paper has the following statement:

"A comprehensive fix to this vulnerability would entail somehow modifying the notions of garbage collection, connection direction, connection status, and simultaneous open in NAT implementations to be more consistent with the security and privacy requirements of VPNs."

However the simplest mitigation seems to be to create a firewall rule for the OpenVPN server that prevents the port the OpenVPN service is listening on from being used as a source port by clients. This use of the same port is what gives the Port Shadowing effect, allowing the de-anonymisation of a client.

My conclusion is that it could happen with an OpenVPN server but the opportunity is restricted compared to commercial VPN providers.

A fix is either for people to create this firewall rule themselves or we could add it into the standard rules applied by IPFire unless that rule has other consequences.

It would be good to have Erik's or other peoples input to confirm that my interpretation of the material is correct but at least here is a first input on this.

Regards,

Adolf.

On 09/09/2021 22:41, Peter Müller wrote:

Hello Erik, hello *,

https://www.openwall.com/lists/oss-security/2021/09/08/3 crossed my path the other day, but I did not yet have time to read it comprehensively.

Since you being the OpenVPN guru around here (no offense intended :-) ): Are you aware of this? Is this something we are affected by?

Thanks, and best regards, Peter Müller