Re: [tor-dev] Domain Fronting, Meek, Cloudflare, and Encrypted SNI...

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Mon, Sep 24, 2018 at 01:46:10PM -0400, Nathaniel Suchy wrote:
> What this means:
> Effectively domain fronting works by sending a different SNI and host header.
> CDN providers like Cloudflare started double checking to make governments
> happy, scratch that line, I mean to protect their customers from fraud and
> abuse. They seem to of backtracked now. Encrypted SNI means that a firewall or
> coffee shop owner won’t be able to use SNI to see the real origin of TLS
> traffic.

What we would need in order for meek to used encrypted SNI would be
either:
 1) support for encrypted SNI in Go's crypto/tls package; or
 2) support for encrypted SNI in the Firefox that ships with Tor
    Browser, which meek-client could use through its TLS camouflage
    helper support.

IMO (2) is less desirable because I'd like to get rid of the TLS
camouflage helper support and replace it with a Go-level TLS camouflage
library: https://github.com/refraction-networking/utls. The TLS helper
works, but its complexity is a pain to deal with and leads to problems
like https://bugs.torproject.org/12774 https://bugs.torproject.org/25405.

Note, however, that a transport based on encrypted SNI doesn't have to
be meek per se. I use "meek" to refer to a specific combination of
domain fronting and a certain (fairly stupid and inefficient) HTTP/1.1
serialization of a bidirectional byte stream. It's conceptually
straightforward to simply replace the "domain fronting" part with an
"encrypted SNI" part. But it's possible to do better: if you're willing
to abandon HTTP/1.1 compatibility and require HTTP/2, you can use the
"server push" feature to implement a serialization that's much more
efficient than the current one in meek. It may even be better to start
over with a new codebase, it's not like meek's code is that large.

But tjr's point stands: I think it's best not to push anything like this
out until after encrypted SNI has seen some level of adoption by
browsers.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev