ESNI as obfs proxy

[Hans-Christoph Steiner]

Hey all,

I wanted to introduce myself to this list in order to make some contacts
about some work that Guardian Project is kicking off. We're working on
some full stack prototypes of Pluggable Transports, so that means taking
an Android app and building a prototype based on that app that provides
a working censorship circumvention tool built in.

We're currently thinking about using TLS 1.3 Encrypted SNI (ESNI) as the
"pluggable transport" for this prototype. I say ESNI as Pluggable
Transport because we'll have to treat it like any other Pluggable
Transport until it becomes a deployed standard, like TLS 1.3. The
really nice thing about ESNI is that it is on the path towards becoming
a real standard that is implemented by default in TLS stacks.

Part of this work is also polishing up our library offerings (NetCipher
and Android Pluggable Transports) to make it easy for apps to include
traffic obfuscation. So even if ESNI is not the best way in the end,
other methods like obfs4 and snowflake can also be easily integrated.

So we're looking for feedback, ideas, comments, etc. for all this as we
start this work.

.hc

--
PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

[David Fifield]

On Tue, Nov 27, 2018 at 10:47:52PM +0100, Hans-Christoph Steiner wrote:
> I wanted to introduce myself to this list in order to make some contacts
> about some work that Guardian Project is kicking off. We're working on
> some full stack prototypes of Pluggable Transports, so that means taking
> an Android app and building a prototype based on that app that provides
> a working censorship circumvention tool built in.
>
> We're currently thinking about using TLS 1.3 Encrypted SNI (ESNI) as the
> "pluggable transport" for this prototype. I say ESNI as Pluggable
> Transport because we'll have to treat it like any other Pluggable
> Transport until it becomes a deployed standard, like TLS 1.3. The
> really nice thing about ESNI is that it is on the path towards becoming
> a real standard that is implemented by default in TLS stacks.
>
> Part of this work is also polishing up our library offerings (NetCipher
> and Android Pluggable Transports) to make it easy for apps to include
> traffic obfuscation. So even if ESNI is not the best way in the end,
> other methods like obfs4 and snowflake can also be easily integrated.
>
> So we're looking for feedback, ideas, comments, etc. for all this as we
> start this work.

I think ESNI is hugely promising. A few points:

I wrote an essay of sorts on implications of ESNI circumvention in
general:
https://groups.google.com/d/msg/traffic-obf/UyaLc9jPNmY/ovNImK5HEQAJ

It's conceptually simple to take the existing meek software, and just
replace the domain fronting step with an ESNI step. All the other
components ought to work without further changes. And in fact, using the
headless Firefox helper (I realize this doesn't help for Android), it
should be almost trivial, but I haven't tried it yet. I outlined a plan
for testing that here:
https://bugs.torproject.org/28168

But, if I were to implement a new ESNI transport from scratch, which I'm
planning to do, I think I would avoid the meek HTTP request–response
protocol because of its inefficiency. Instead, I want to try using
exclusively HTTP/2 and its server push feature in order to avoid the
need for polling by the client. I might be missing some details, but my
intuition is that we can use HTTP/2 with server push pretty much just as
a socket.
https://lists.torproject.org/pipermail/tor-dev/2018-September/013456.html

I don't know of any client implementation of ESNI other than Firefox's.
Support for TLS 1.3 (prerequisite for ESNI) just landed in Go a few
weeks ago:
https://github.com/golang/go/issues/9671#issuecomment-437431164
And currently "there are no plans for encrypted SNI":
https://github.com/golang/go/issues/9671#issuecomment-439561672
The actual ESNI parts themselves don't seem too hard to implement; what
I'm less sure of is the difficulty of integrating them into an existing
TLS implementation.

My understanding from following IETF discussions is that there are going
to be changes relative to https://tools.ietf.org/html/draft-ietf-tls-esni-02.
There are some issues and discussion here:
https://github.com/tlswg/draft-ietf-tls-esni/issues
In particular, it seems like they're likely to change from TXT to an
ESNI-specific RRtype, and stop base64 encoding.