Hello,
I’ would like to put out a question to those with more technical knowledge than myself. It seems that Proton’s “Stealth” protocol is able to access a restrictive wifi network that Mullvad’s QUIC is not. If both protocols operate on the similar notion of disguising Wireguard to look like regular internet traffic, why does one work and the other not? This is not a Proton vs Mullvad issue. They are both respectable VPN services.
ProtonVPN’s Stealth protocol is developed as a fork of wireguard-go in their repository. While there may be other enhancements, from what I can see, they are using WireGuard over TLS as their base.
As you know, MullvadVPN uses WireGuard over QUIC. In the simplest terms, this means it’s WG over TLS versus WG over QUIC.
In some networks, security gateways attempt to decrypt encrypted communications for security inspection. Since QUIC is new and traffic cannot be decrypted, network administrators may block QUIC.
In such networks, WG over QUIC may fail to connect, while WG over TLS might work. Of course, there may be other reasons as well, but many networks around me still block QUIC.
Correct. Good addition is probably that quic is TLS 1.3 wrapped in a faster, UDP‑based transport.
In practise I have actually experienced that sometimes UDP 443 isn’t filtered at all. When I was at uni i used to bypass the MAC-address whitelisting with this, so that I could go online without logging in to register my devices.
Mullvad quic is a joke. The internet slows down to a treacle. Do they even know what they’re doing.
Yeah, QUIC makes TLS1.3 mandatory. But, it isn’t “faster” across the board. QUIC connections, unlike TCP, can roam over networks and routers, which makes it popular on mobile devices.
QUIC implementations hate IP fragmentation, and may refuse to work properly. When this happens, it may appear as if some router/gateway on the connection path was censoring QUIC. Also, QUIC won’t work on devices/gadgets behind interfaces or misconfigured routers/gateways with MTU less than 1280 bytes.
But QUIC disguises the traffic to look like http traffic, so how are network admins able to “block QUIC”? And how would they know that the underlying Wireguard traffic is encrypted?
But QUIC disguises the traffic to look like http traffic,
QUIC protocol does not disguise as the HTTP protocol.
With WireGuard-over-QUIC, a QUIC connection is first established to enable HTTP/3 communication. The HTTP/3 connection is then used to establish the WireGuard VPN connection, which allows it to bypass WireGuard protocol blocks.
Therefore, if QUIC protocol is blocked, WireGuard-over-QUIC will not function because establishing QUIC connection is a prerequisite.
so how are network admins able to “block QUIC”?
Most network administrators are probably unaware of the technical specifics behind blocking QUIC protocol. Modern firewall products include protocol classification features that allow administrators to permit or deny communication for a given protocol with just a few clicks, so this is not something they need to be aware of.
I’m also not familiar with the exact detection method, but it seems possible to identify QUIC protocol heuristically based on characteristics in its header structure, such as the version number field.
And how would they know that the underlying Wireguard traffic is encrypted?
QUIC protocol incorporates TLS 1.3 and encrypts payload and header information wherever possible. Therefore, there is no need to check whether traffic using QUIC protocol is encrypted; simply block it.
Thanks for the great explanation. So which of the multiple Wireguard obfuscation methods that Mullvad offers do you has the best chance of being able to hide my VPN use from my ISP?
Also, how does Mullvad QUIC even obfuscate at all when my ISP will know I’m connecting to the ip address of a Mullvad QUIC server, of which there are very few?
