Re: [TLS] About encrypting SNI

[Andy Lutomirski <[e-mail]>]

On Wed, Apr 16, 2014 at 11:47 AM, Jacob Appelbaum <[e-mail]> wrote:
> On 4/16/14, Brian Sniffen <[e-mail]> wrote:
>> Andy Lutomirski <[e-mail]> writes:
>>
>>> On 04/14/2014 10:21 PM, Watson Ladd wrote:
>>>> Now, the best mechanism I can think off would be to use DNS to preload
>>>> a per-IP SNI encryption key, or have the handshake optionally involve
>>>> getting one. But I still can't figure out how to authenticate the
>>>> gotten key without a lot of complexity. The best solution is for the
>>>> client and server to do a DH, then pass the desired website (which
>>>> might get you investigated when the initial handshake is intercepted),
>>>> and have that cert sign the handled DH, then go back and do a TLS
>>>> connection. Ugh.
>>>
>>> What if it were an opt-in thing?  A hypothetical DANE extension could
>>> associate with each domain a tuple (ClientHello-protection public key,
>>> TLS version guaranteed to be supported).  Clients could resolve that
>>> essentially for free as long as they're already querying DNS, and this
>>> could prevent downgrade attacks and give an efficient way to encrypt the
>>> entire ClientHello.
>>
>> Then the censor looks to see which key is used, yes?
>
> Keys are free - names and signatures are not. The good news is that
> signatures may be regenerated at a low cost depending on the systems;
> the bad news is that names generally can't change without a lot of
> effort on both the client and the server side.
>

I'm not sure I understand what you mean.

>>
>>> There's a weak argument to be made for arranging for the actual
>>> encrypted ClientHello to be indistinguishable from random by anyone who
>>> doesn't know the private key.  This ought to be straightforward using
>>> Elligator.  Off the top of my head, it sounds cute, but I don't really
>>> see a benefit.
>>
>> Or does this protect against it?
>>
>
> I have previously hoped for a TLS (handshake, protocol,
> implementation, etc) that actually considers that an attacker will try
> to distinguish users and then treat them differently, eg: attacking
> them, even with a simple DoS.
>
> We see this often with the Tor network. We once were blocked in Iran
> because we used a specified prime from the relevant RFC - it turns out
> nearly no one else was impacted because they used another prime. We
> changed the primes on the server to be dynamically generated and the
> network was unblocked without a client side update. Fixed identifiers
> or patterns in protocols are how censors target specific users and
> protocols for censorship. The SNI in TLS is the most obvious and easy
> distinguisher and it also suggests that privacy isn't actually a
> cohesive security property of Transport Layer Security.
>
> Not every TLS service uses DNS simply because it may also use names.
> Names aren't only used in DNS. Just as there is more to the internet
> than the world wide web, there is more to naming than the DNS.

I think that my updated proposal should work for you, as long as Tor
has some other way to distribute the same data that's normally in the
DNS record.  I imagine that it could be distributed along with the IP
addresses of entry nodes.  Am I missing something here?

My proposal, as currently written, results in the encrypted form the
the TLS handshake looking like a fixed header (ClientHello TLS version
whatever, throw-away values in fixed fields, extension prefix for the
actual encrypted Clienthello) followed by data that is
indistinguishable from random due to the use of Elligator 2 /
Elligator Squared.

If non-Tor sites adopt this, then Tor traffic will look just like
everything else.

--Andy