The MASQUE Proxy

2.1. Protection from Web Servers

Connecting directly to Web servers allows them to access the public IP address of the user. There are many privacy concerns relating to user IP addresses [IP-PRIVACY]. Because of these, many user agents would rather not establish a direct connection to web servers. They can do that by running their traffic through a MASQUE Proxy. The web server will only see the IP address of the MASQUE Proxy, not that of the client.¶

2.2. Protection from Network Providers

Some users may wish to obfuscate the destination of their network traffic from their network provider. This prevents network providers from using data harvested from this network traffic in ways the user did not intend.¶

2.3. Partitioning

While routing traffic through a MASQUE proxy reduces the network provider's ability to observe traffic, that information is transfered to the proxy operator. This can be suitable for some threat models, but for the majority of users transferring trust from their network provider to their proxy (or VPN) provider is not a meaningful security improvement.¶

There is a technical solution that allows resolving this issue: it is possible to nest MASQUE tunnels such that traffic flows through multiple MASQUE proxies. This has the advantage of partitioning sensitive information to prevent correlation [PARTITION].¶

Though the idea of nested tunnels dates back decades [TODO], MASQUE now allows running HTTP/3 end-to-end from a user agent to an origin via multiple nested CONNECT-UDP tunnels. The proxy closest to the user can see the user's IP address but not the origin, whereas the other proxy can see the origin without knowing the user's IP address. If the two proxies are operated by non-colluding entities, this allows hiding the user's IP address from the origin without the proxies knowing the user's browsing history.¶

2.4. Obfuscation

The fact that MASQUE is layered over HTTP makes it much more resilient to detection. To network observers, the unencrypted bits in a QUIC connection used for MASQUE are indistinguishable from those of a regular Web browsing connection. Separately, if paired with a non-probable HTTP authentication scheme [UNPROMPTED-AUTH], any Web server can also become a MASQUE proxy while remaining indistinguishable from a regular Web server. It might still be possible to detect some level of MASQUE usage by analyzing encrypted traffic patterns, however the cost of performing such an analysis at scale makes it impractical.¶

This allows MASQUE to operate on networks that disallow VPNs by using a combination of protocol detection and blocklists.¶

3.1. OHTTP

Oblivious HTTP [OHTTP] uses a cryptographic primitive [HPKE] that is more lightweight than TLS [TLS], making it a great fit for decorrelating HTTP requests. In traditional Web browsing, the user agent will often make many requests to the same origin (e.g., to load HTML, style sheets, images, scripts) and those requests are correlatable since the origin can include identifying query parameters to join separate requests. In such scenarios, MASQUE is a better fit since it operates at the granularity of a connection. However, there are scenarios where a user agent might want to make non-correlatable requests (e.g., to anonymously report telemetry); for those, OHTTP provides better efficiency than using MASQUE with a separate connection per request. While OHTTP and MASQUE are separate technologies that serve different use cases, they can be colocated on the same HTTP server that acts as both a MASQUE Proxy and an OHTTP Relay.¶

3.2. DoH

DNS over HTTPS [DoH] allows encrypting DNS traffic by sending it through an encrypted HTTP connection. Colocating a DoH server with a MASQUE IP proxy provides better performance than using DNS over port 53 inside the encrypted tunnel.¶