Re: [TLS] About encrypting SNI

[Brian Sniffen <[e-mail]>]

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?

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

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies