[tor-project] US congress wrote a letter to Google and Amazon on domain fronting
yawning at schwanenlied.me
Thu Jul 19 05:26:21 UTC 2018
For what it's worth, I agree with Alec.
From a technical standpoint, rejecting SNI/Host header mismatches is a
perfectly rational thing to do, because it defeats the purpose of having
a SNI block in the first place.
From a business standpoint, not wanting to be the conduit for abuse, or
jeopardize the rest of their paying customers, who are the involuntary
collateral in domain fronting's collateral freedom is also perfectly
On 07/18/2018 11:20 PM, Kate Krauss wrote:
> Aha, this is news to me. Could you possibly Explain Like I'm 5: Why is
> SNI not good, why is TLS 1.3 controversial, and why is it not good to
> have domain fronting as a tactic we use until we figure out a better one
> (or preserve it as part of an evolving toolkit)? We could reach a lot of
> censored users if we had it. I'm assuming this relates to "anonymity
> loves company" but I don't understand how (literally).
SNI is not good because it is one of, if not the main TLS leaks
regarding the intended destination to external observers.
As a gross simplification, the problem SNI exists to solve (when not
being intentionally malformed for the purpose of misuse) is thus:
It is common to want lots of separate sites to be hosted behind a
common endpoint. For example, a hosting provider may be responsible
for "yawning.example", "alec.example", and "kate.example".
The mechanism for doing so is the HTTP `Host` header, which is carried
encrypted. (eg: A browser would include `Host: yawning.example` as
part of it's request for content.)
Hypothetically, suppose that a hosting provider uses the IP address of
192.0.2.23 to host those three domains. Without SNI, that host has no
way of determining which web server a connection is intended to go to
without terminating TLS (as the Host header is encrypted) forcing the
hosting provider to do something like this:
(Image courtesy of the United States National Security Agency)
This precludes each hosted site using their own TLS certificate, and
additionally is computationally expensive at the ingress point into
hosting provider's network.
The SNI solution to the problem it sets out to solve, is for each TLS
connection to include a SNI block that contains the final destination
host, un-encrypted in the clear, visible to everybody.
SNI is why, even if you are using TLS, the domain name of the site you
are using is visible to the entire world (eg: A SNI block indicates that
a otherwise encrypted connection to `kate.example` is destined for
`kate.example` rather than `alec.example`).
The benefit of SNI is that, the final destination of the request is
visible without doing cryptographic operations (yes, this is the same as
the downside). By doing so, there is no need to decrypt anything till
the final destination, allowing for greater security/privacy (due to
being able to implement true end-to-end encryption, rather than
end-to-the-edge-of-their-network encryption) and scalability/performance.
I am of the opinion that as bad as SNI is, not having something like
SNI, or SNI being unreliable due to lying clients is far worse.
> Also, I'm troubled by Google and Amazon's willingness to make a
> unilateral decision that negatively affects human rights. It is a bad
Attempting to compel entities to reverse a perfectly rational technical
and business decision with violence (ie: State power) is beyond disturbing.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the tor-project