[person4268]

Not if the network blocks QUIC in its entirety to force clients to fallback to HTTP1. I'm pretty sure the network I'm currently on does this.

But, it looks like the type of fingerprinting in the article utilizes the fact that VPN connected devices are only connected to and sending data mostly to only one host, which using QUIC won't help with - you'd need to add some sort of "noisemaking" functionality involving sending bogus packets outside the tunnel, or possibly route VPN traffic across multiple nodes before forwarding to the actual vpn server ala Tor (as they propose in the conclusion).

[j4hdufd8]

> which using QUIC won't help with curious why not?

[person4268]

You're still sending packets to the same IP address. QUIC can't obfuscate that itself, all packets have to get routed over IP in the end. The paper relies on very little but that fact.

If one wanted to block VPN connections, they easily could do so by running such detection and then blocking all UDP (QUIC is built on UDP) traffic from the host to the suspected VPN server, too.

What QUIC helps with, in the context of dealing with DPI firewalls, is really just the obfuscation/encryption of as much connection info as possible, such as the SNI/Host in the context of an HTTP server, which normally is sent in plain text even with SSL/TLS (though ESNI efforts are starting to fix this)

[generalizations]

So maybe the solution is to double-send all the encrypted packets - once to the VPN endpoint, and once to the original target (but encrypted so it doesn't reach). Or maybe instead of the intended target, to some randomized selection of targets. You wouldn't get responses, but maybe that doesn't matter.