[anti-censorship-team] The MASQUE circumvention protocol

Philipp Winter phw at torproject.org
Wed Jul 31 18:15:09 UTC 2019


I found a more extensive description of the MASQUE protocol:
<https://davidschinazi.github.io/masque-drafts/draft-schinazi-masque.html>

Here are my key take-aways after reading the draft:

* MASQUE enables circumvention by hiding a circumvention proxy behind a
  web server, similar to Sergey's httpsproxy.  Clients "unlock" the web
  server's circumvention feature by using the newly-proposed HTTP
  Transport Authentication Standard:
  <https://tools.ietf.org/html/draft-schinazi-httpbis-transport-auth-00>

  In a nutshell, clients need to send a CONNECT request with a transport
  authentication header to .well-known/masque/initial.  Crucially,
  MASQUE defends against active probing by responding with "405 Method
  Not Allowed" to failed authentication attempts -- the same response
  one would get for an unexpected CONNECT request.  This prevents
  censors from learning if a web server supports MASQUE.

* Once a client "unlocked" a MASQUE server, one can tunnel several types
  of traffic over the MASQUE server.  One can use it as an HTTP proxy,
  send DNS requests, and do both UDP and TCP proxying.

* MASQUE supports QUIC over HTTP/3 and TLS 1.3 over HTTP/2.  There is a
  fallback mechanism from HTTP/3 to HTTP/2 to provide a disincentive for
  censors to block QUIC or HTTP/3.

* MASQUE only provides obfuscation and does not provide anonymity.  The
  document suggests onion routing in Section 2.4 to work around this
  shortcoming.

* MASQUE does not defend against traffic analysis but QUIC supports
  padding, so there's a mechanism to mitigate this problem.  Traffic
  analysis defence is left for future work in Section 7.2.

* QUIC has a "connection migration" feature that allows clients to
  seamlessly switch end-to-end connections from one MASQUE server to
  another.

* Similar to onion services, MASQUE makes it possible to make available
  a server behind NAT by using a MASQUE server as a rendez-vous
  mechanism.

There's an IETF mailing list for the project:
<https://mailarchive.ietf.org/arch/browse/masque/>

MASQUE may make a good pluggable transport and we should engage early to
make this happen.  I intend to suggest this idea on their mailing list
soon.

Cheers,
Philipp



More information about the anti-censorship-team mailing list