Subject: [Masque] HTTPT: A Probe-Resistant Proxy

From: David Fifield <[email-masked]>
Date: Tue, 1 Sep 2020 10:46:30 -0600

This is a summary of a paper that I believe is relevant to this group,
from the recent Free and Open Communications on the Internet (FOCI)
workshop. It's a proxy hidden behind HTTPS, undetectable except to
authenticated clients. A normal CONNECT proxy doesn't cut it in this
regard, because unauthenticated clients get a 407 status code and know
that there is a proxy running, even if they may not access it. The
authors had previously written a probe-resistant CONNECT module
(https://github.com/caddyserver/forwardproxy), but it only worked with
Caddy and not other web servers. One insight of the current work is that
WebSocket reverse proxying, which most web server support by default,
provides equivalent functionality, with better compatibility.

HTTPT: A Probe-Resistant Proxy
Sergey Frolov, Eric Wustrow
https://censorbib.nymity.ch/#Frolov2020b
https://www.usenix.org/conference/foci20/presentation/frolov (video and slides)
https://github.com/sergeyfrolov/httpt

The paper describes HTTPT, a probe-resistant proxy design built on
HTTPS. Probe-resistant proxy servers defeat active probing attacks
(https://ensa.fi/active-probing/) by requiring the client to prove
knowledge of a secret before revealing their proxy functionality. Most
contemporary probe-resistant proxies, like obfs4 and Shadowsocks, use a
randomized protocol and respond to authentication failures by remaining
silent, which is conceptually sound, but somewhat uncommon in the
universe of protocols and tricky to do right (https://github.com/net4people/bbs/issues/26).
HTTPT, in comparison, uses HTTPS as its carrier protocol, and responds
to unauthenticated client requests not by remaining silent, but by
replying the way a non-proxy-capable web server would. HTTPS offers a
number of nice features for implementing a proxy: it is a common
protocol with many diverse implementations; TLS itself is resistant to
replay-based probing; TLS adds only a small amount of framing overhead;
and it is possible to co-locate a proxy with exiting HTTPS services.

An HTTPT client authenticates itself by requesting a secret URL path.
This unguessable path is known only to legitimate clients and is the
only means of accessing the web server's hidden proxy functionality.
Unauthenticated clients are therefore unable to probe it. The web server
is configured to forward requests for the secret path as if it were
forwarding a WebSocket connection (e.g., https://www.nginx.com/blog/websocket-nginx/),
transforming the HTTPS connection into a two-way TLS-protected stream
between the client and the HTTPT proxy backend. This WebSocket trick
enables broad compatibility for HTTPT, as all major web servers have the
ability to do WebSocket forwarding, without a custom plugin. (The paper
tests with Apache, Nginx, and Caddy.) Once forwarded, the remainder of
the connection does not even have to conform to the WebSocket protocol,
which means there is no overhead beyond what is added by TLS.

The ideal situation for HTTPT deployment is to install a proxy on an
established HTTPS web site. Unauthenticated active probers will only
find whatever the web site normally serves, while authenticated clients
who know the secret path can access the proxy. An established web site
already has a reasonable TLS fingerprint and a valid certificate. The
client still has to take care about its TLS fingerprint, using uTLS
(https://github.com/refraction-networking/utls) or something similar.
A deployment not connected to any existing web server is also possible,
but requires some thought towards what to return on an authentication
failure. Section 3.2 of the paper covers some options, which include
returning an error page or transparently proxying some other web site
are all possibilities. According to a Censys survey
(https://censys.io/ipv4/report?field=443.https.get.status_line.raw),
returning an error page is not unusual: about half of actual HTTPS
servers respond with a 4xx or 5xx status code when probed.

---

From: David Schinazi <[email-masked]>
Date: Tue, 1 Sep 2020 11:18:05 -0700

Hi David,

Thanks for sharing, this was an interesting read!
>From a technology perspective, this looks very similar
to the first version of MASQUE written in February 2019:
https://tools.ietf.org/html/draft-schinazi-masque-00
MASQUE has since evolved to encompass more use-cases,
but hiding a MASQUE proxy behind an HTTPS server
is still an important feature of MASQUE. I do think there
is value in collaboration here, as the MASQUE WG is
currently focusing on adding additional types of proxying
(CONNECT-UDP, IP proxying) but there is value in
developing better obfuscation techniques in parallel.

Cheers,
David

On Tue, Sep 1, 2020 at 9:46 AM David Fifield <[email-masked]> wrote:

> universe of protocols and tricky to do right (
> https://github.com/net4people/bbs/issues/26).
> forwarding a WebSocket connection (e.g.,
> https://www.nginx.com/blog/websocket-nginx/),
> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 7 Sep 2020 22:24:20 -0700

David Schinazi wrote on 2020-09-01 11:18:
> ...
> ...

the history of obfuscation techniques is that anything which scales well 
enough to pose a threat to political controls gets serious, draconian, 
outsized attention. before we adopt more layers of obfuscation, do we 
have an end in sight? that is, are we joining Tor's forever war, such 
that our grandchildren's grandchildren are expected to need our help 
with frameworks and taxonomies for their decade-by-decade games of 
one-up-manship? or are we solving the problem in our own time, either 
knowing that nothing will change across generations, or participating in 
some kind of self-deception where we pretend that won't happen?

(asking for a me.)

vixie