Re: [TLS] About encrypting SNI

[Jacob Appelbaum <[e-mail]>]

On 5/20/14, Yoav Nir <[e-mail]> wrote:
>
> On May 20, 2014, at 8:17 PM, Jacob Appelbaum <[e-mail]> wrote:
>
>> On 4/25/14, Martin Rex <[e-mail]> 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.
>
> 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.

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.

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

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