Subject: Re: [TLS] About encrypting SNI

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 20 May 2014 17:17:17 +0000

On 4/25/14, Martin Rex <[email-masked]> wrote:
> Russ Housley wrote:
>> > I think Rich Salz has outlined very compelling reasons not to support
>> > SNI.
>>
>> While I might quibble with a detail here or there, I do agree with the
>> conclusion.  If you need to protect SNI, then TOR or to a lesser extent
>> TLS-in-TLS can be used.
>
> I agree.  If you need TOR, you should use TOR.
>

This is curious - what specific property do you think you need from Tor?

To protect from information leaks in TLS or other protocols? If so,
sure, use Tor.

One doesn't need the anonymity of Tor or the censorship circumvention
of Tor per se - rather, this is basically compensating for a protocol
that leaks plaintext information.

However - I wonder why not fix the (transport layer security) protocol
to not have such an information leak? Then we can say: If you need
anonymity, use Tor. If you need Transport Layer Security (and thus
confidentiality), use TLS!

This is also a conundrum for Tor I might add - we use TLS on the wire
and as a result, we generate random stuff for say, the hostname
embedded in various bits of the TLS connection. It would be nice if we
could remove such distinguishers from the TLS protocol entirely. It
would help Tor which is also useful, if as you say, you want people to
use it when they need it.

( Also - It's Tor, not TOR. )

> Encrypted SNI comes at a huge cost, and could at best provide
> a benefit somewhere between completely negligible and absolutely none.

I'm not convinced that this is the right framing of the issue. Allow
me to turn this over:

Plaintext information leaks in TLS come at a huge cost and ensure that
TLS may be selectively and actively attacked in a targeted manner.
This is a protocol failure and we should correct it.

>
> Whether the service provider uses multiple services on a host at
> all, is up to the service provider.
>
> What name the service provider chooses is up to the service provider.
>
> Whether the content of the individual hosts is (close to) 100%
> distinguishable by its traffic patterns is up to the hosting provider,
> the service providers, the nature of their contents and the amount
> of (or lack of) cooperation/synchronization among the service providers.
>
>
> It would be crazy if any of the secret three agencies would spent
> a huge amount of protective efforts so that they could refer to
> their "secret hideout at 17, umpteen street" under the term
> "secret hideout at 17, umpteen street", instead of simply
> calling it an office or a laundry, or whatever.
>

My concern is not helping secret three agencies. My concern is that
those secret three agencies are attacking TLS. They use this
distinguisher, as well as others, to select specific traffic for
collection, as well as for censorship and other forms of exploitation.
This applies to those agencies amongst other attackers who aren't well
funded. We should consider this reality and try to defend against this
threat.

>
> The server name is simply routing information.  And it is not just
> load-balancers that may want to be able to use that information
> without having to open/terminate/participate the TLS communication,
> it's also easier and cleaner for implementations at the endpoint
> to do the server-side of TLS extension SNI "outside" of the TLS stack.
>

Sure - the server name is a distinguisher which serves as a way for
attackers to exploit other issues in common TLS deployments. We should
remove as many of the distinguishers from TLS in the client and server
as is possible. We can't solve every traffic analysis problem with TLS
but we don't need to leak the client's clock, the requested hostname,
and lots of other details merely because we've always done so.

I think that TLS in TLS is a nice idea but the outer handshake will
still have distinguishers that ensure that such handshakes will be
easy to deny selectively. The design of OTR is useful to consider. It
doesn't make sense to simply declare TLS in TLS without considering
how that would really look on the wire to an adversary with moderate
DPI capabilities.

All the best,
Jacob

---

From: Paul Lambert <[email-masked]>
Date: Tue, 20 May 2014 12:38:58 -0700

>This is a protocol failure and we should correct it.

+1

Anonymity is easiest in a crowd. The same protocol exchanges used for
everyday browsing should look identical to traffic requiring
more careful protection.  Proxied or onion routed traffic should
appear identical to traffic destined to a visible end point.

Paul

>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 20 May 2014 23:02:15 +0300

> that leaks plaintext information.

The requirement for encrypted SNI is very simple. I want to browse certain web sites such that if people knew I was browsing them it might get me in trouble. We all like the example of a gay teenager in Uganda, but it could just as well be an American browsing a website advocating Shari’a law for all western countries landing in a no-flight list.

Encrypting SNI would help if the “suspicious” web site is hosted by a hosting service, and there are multiple innocuous sites on the same IP address, and the traffic from the innocuous sites dominates the traffic to the server, and traffic for this site is not distinguishable by other means such as traffic analysis.  That’s a lot of ‘if’s up there, and if any of them fails, the adversary will know that I browsed the suspicious site. AFAIK Tor provides a far more robust protection of this kind of activity.

So I’m with Martin on this. If you need Tor, use Tor.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 20 May 2014 16:18:17 -0400

> Encrypting SNI would help if the “suspicious” web site is hosted by a hosting service, and there are multiple innocuous sites on the same IP address, and the traffic from the innocuous sites domina…

I agree that it is a lot of 'if's, and you didn't even mention DNS
privacy, or running a non-compromised web browser, or client operating
system security, or whether the "risky" services are running on
untrustworthy cloud infrastructure, or if they log user traffic via
popular analytics services which themselves could be compromised, or if
the user isn't clearing their browsing history, etc.

I'm sure we can come up with many more problems that could give away the
association between the user and the web site unrelated to either Tor or
TLS.

But the fact that other problems and constraints exist is a terrible
reason to avoid fixing the constrained problems we *can* fix in the
protocol we are responsible for.

	--dkg

---

From: Tim Bray <[email-masked]>
Date: Tue, 20 May 2014 13:24:12 -0700

On Tue, May 20, 2014 at 1:02 PM, Yoav Nir <[email-masked]> wrote:

>
> The requirement for encrypted SNI is very simple. I want to browse certain
> web sites such that if people knew I was browsing them it might get me in
> trouble. We all like the example of a gay teenager in Uganda, but it could
> just as well be an American browsing a website advocating Shari’a law for
> all western countries landing in a no-flight list.
>
> Encrypting SNI would help if the “suspicious” web site is hosted by a
> hosting service, and there are multiple innocuous sites on the same IP
> address, and the traffic from the innocuous sites dominates the traffic to
> the server, and traffic for this site is not distinguishable by other means
> such as traffic analysis.  That’s a lot of ‘if’s up there, and if any of
> them fails, the adversary will know that I browsed the suspicious site.
> AFAIK Tor provides a far more robust protection of this kind of activity.
>

Let’s assume you are correct in all your assertions.  It is still the case
that every time you increase the proportion of the attack surface which is
encrypted, you increase the difficulty for snoopers. It is not a
requirement that you make the snoopers’ task impossible; in fact, all you
can ever do is crank up the difficulty for attackers. It seems obvious that
encrypting as much of connection setup as possible would increase attacker
difficulty so, if practical, it should be done.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 20 May 2014 20:47:12 +0000

> all western countries landing in a no-flight list.

TLS is about protecting things more than websites, isn't it?  Or put
another way: the internet is more than the world wide web!

My requirement for encrypting SNI is different than yours, I suppose.
I want to stop information leaks that are used by attackers to degrade
or otherwise attack users of TLS. I also want to stop a passive
attacker from learning specific details about my TLS session. I also
want to ensure that I can detect an active attacker who wishes to
learn this information before I might disclose it. Leaking information
automatically for every connection to a passive attacker doesn't meet
those requirements.

> them fails, the adversary will know that I browsed the suspicious site.

That is largely false, I think,

There are many kinds of adversaries. As it stands, we're not even able
to defend against attackers who can just watch a handshake. They can
even perform a selective MITM before the handshake completes. We're
not even into website fingerprinting techniques, which yes, I agree
are a problem. Such fingerprinting issues are however a different
problem in a family of problems, frankly.

It is clear that TLS cannot protect you from practical realities about
information theory. It would be nice if that was actually the issue at
hand. Rather we're discussing an information leak that largely comes
from a trend of centralization. E.g: we have a lot of hostnames on one
IP address or a cluster of load balancers handling a bunch of
different sites. As a result, we need to reveal the hostname to ensure
that the server returns the correct certificate. Obviously, we need to
reveal that information somewhere, I just don't buy that we should
reveal it to the network.

TLS should protect you from this information disclosure. Users that I
have asked were surprised to learn that TLS reveals the hostname in
their TLS connection. I think a good quote is: "What does that padlock
even mean?!?" Amusing, right? Well, perhaps... but what does the
security in TLS mean anyway? If it means leaking information
everywhere so that more people are motivated to use Tor, what should
Tor use as a transport protocol when it wants confidentiality? Not
TLS? ... Argh.

> AFAIK Tor provides a far more robust protection of this kind of activity.

Tor relies on TLS and does not have the problem that say, a CDN has
with virtual hosting. And in any case, these choices in TLS will
ensure that it is harder for Tor to provide needed robust protection
for any activity. A Tor bridge, for example, is not listed in a public
directory. The TLS distinguishers are what make it easy for a passive
adversary to tag (say, with XKEYSCORE) those flows for further
analysis.

In the case of China and Iran, we see this analysis in the form of
automated detection of bridges, where the censors actively probe
suspect connections and then blackhole traffic when they feel it is
positively a Tor bridge. This does not happen for all TLS connections
and it would probably not currently scale for all TLS connections. If
we could blend in, we'd be better off. We have an obfuscated protocol
for defeating DPI but man, that is a hard road and in any case, it
makes some assumptions that are (likely) wrong. It is hard to close
that feedback loop without censorship - that is - sometimes the only
detection of surveillance (aka our friend Eve) is with censorship.

Which brings me to the case of the FVEY countries (UK, US, CA, NZ, AU)
and their other partner nations (a longer list including SE, DE, etc -
look it up) - they use XKEYSCORE to tag TLS traffic based on these
distinguishers. That data is put into databases for later uses. It is
also used for exploitation ala QUANTUM*. These TLS issues are really a
problem and they are really being actively exploited in the wild.

> So I’m with Martin on this. If you need Tor, use Tor.

And how will you get your copy of Tor, exactly? And how will you use
that on devices where there is no Tor? And when you download your copy
of Tor, what happens to the meta-data about those traffic flows? I
guess it should be easy to pick out torproject.org from the SNI
flowing across our TLS enabled website, regardless of all the other
protections we might take...

None of our TLS sessions are free (from surveillance and censorship)
until they're all free (of distinguishers)... :-)

All the best,
Jacob

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 May 2014 13:58:37 -0700

On May 20, 2014, at 1:24 PM, Tim Bray <[email-masked]> wrote:

> Let’s assume you are correct in all your assertions.  It is still the case that every time you increase the proportion of the attack surface which is encrypted, you increase the difficulty for snoopers. It is not a requirement that you make the snoopers’ task impossible; in fact, all you can ever do is crank up the difficulty for attackers. It seems obvious that encrypting as much of connection setup as possible would increase attacker difficulty so, if practical, it should be done.

The question for the WG is the "if practical" part of that sentence. Among all the proposals for encrypting SNI, there are different practicality tradeoffs (additional round trips, worse downgrade susceptibility, needing to get additional information from the DNS, ...). Different people will have different measurements of practicality, which means that any change we make here will end up making TLS 1.3 less practical for someone. Deciding who that should be will be based on the proposals themselves.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 20 May 2014 21:40:36 +0000

On Tue, May 20, 2014 at 01:24:12PM -0700, Tim Bray wrote:

> Let?s assume you are correct in all your assertions.  It is still the case
> requirement that you make the snoopers? task impossible; in fact, all you

This runs smack into the "mile-high pole" fallacy.  Quoting Bruce Schneier:

    Secure the Weakest Link

    You can't just plant a mile-high pole in front of your castle
    and hope the enemy runs right into it; you have to look at the
    whole landscape and build earthworks and a palisade.  Similarly,
    just because you're using an encryption algorithm with a 256-bit
    key doesn't mean you're secure; the enemy is likely to find
    some avenue of attack ignores the encryption algorithm completely.

In particular stronger security measures that focus on a small part
of the problem often yield no measurable benefit.  This is quite
likely the case here.  I would not want to encourage any user whose
life or well-being depended on security of TLS against traffic
analysis to even consider relying on TLS SNI encryption.  Such users
need to be substantially more cautious.

The only plausible use-case for SNI encryption is to thwart bulk
traffic analysis directed at entire populations, users likely to
be targeted MUST NOT rely on protection as feeble as an encrypted
TLS handshake might yield (yes, if it is possible at tolerable
cost to not aid the attacker AND there is a reasonably plausible
measurable benefit as a result, one should still implement the
protection).

So this boils down to whether:

      Is it in fact plausible that all the various counter-measures
      were they rolled out (over a decade or two), in multiple
      protocols and implementations, would provide the expected
      benefit by making traffic analysis measurably more difficult?

I am regrettably skeptical of this.  I think we could make more
progress by obviating the need for SNI than by attempting to encrypt
it.

For example, with DNSSEC SRV records, the TLS service endpoint for
a hosted domain can be mapped to a fixed hosting name that does
not depend on the hosted domain name, and the client could verify
the single name in the server certificate.  If we move to an SNI-free
world, the problem is eliminated from TLS.  There are still DNS
queries to protect, but these would need to be protected anyway (the
A record lookup).

Of course SNI is almost certainly not the only sensitive payload
in the handshake, and one might want to define a stripped-down
outer protocol that completes an ADH or AECDH key exchange with
channel binding first to an SNI-agnostic TLS stack at the target,
and then sub-negotiates with channel binding any additional protection
that may be desired.  Such a protocol would sport mandatory session
tickets for fast reliable resumption, with a lifetime advertised
to the client to avoid needless fallback latency to the full outer
protocol.  Resumption would begin with an outer session ticket and
an encrypted inner handshake (which might also be a resumption).
If outer resumption does fail (should be rare), the server would
elicit a new full outer handshake from the client, without requiring
the client to disconnect and retry.

This would be a dramatic change, would one still call such a beast
TLS?

-- 
	Viktor.