Hello,
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 rational.
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:
https://cdn.arstechnica.net/wp-content/uploads/2013/10/GOOGLE-CLOUD-EXPLOITA...
(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 precedent.
Attempting to compel entities to reverse a perfectly rational technical and business decision with violence (ie: State power) is beyond disturbing.
Regards,