Re: [TLS] About encrypting SNI

[Paul Lambert <[e-mail]>]

On 5/20/14, 10:17 AM, "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.
>
>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.

+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


>
>>
>> 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
>
>_______________________________________________
>TLS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tls