[tor-project] US congress wrote a letter to Google and Amazon on domain fronting

[Yawning Angel]

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-EXPLOITATION1383148810.jpg

   (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,

-- 
Yawning Angel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20180719/beec0e81/attachment.sig>