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.