Re: [TLS] Encrypted SNI

[Tom Ritter <[e-mail]>]

On 5 December 2015 at 21:31, Eric Rescorla <[e-mail]> wrote:
>
>
> On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <[e-mail]> wrote:
>>
>> On 5 December 2015 at 12:32, Eric Rescorla <[e-mail]> wrote:
>> > Subject: SNI Encryption Part XLVIII
>>
>> A small concern that probably is "No, that can't happen", but I would
>> want to be sure that a normal (non-encrypted SNI) ClientHello would be
>> unable to be wrapped in a new ClientHello to a gateway by a MITM
>> (without being detected.)
>
>
> That would certainly be consistent with the proposed design. Why is that
> bad?

It doesn't seem safe that a MITM can actively change the way a
handshake occurs and is processed by the other side without being
detected. It's like asking for some sort of more complex attack. We
don't allow a MITM to change other parts of the handshake.

A trivial, though contrived, example could be a CDN that supports
eSNI. All requests it receives from... Turkmenistan[0] use eSNI. Seems
good? Actually the government blocks all client-originated eSNI
requests and re-wraps them so to the outside world it appears less
censored than it is. Could be done state-wide or (if god forbid we had
a fallback) to individual clients.

Something analogous is not allowing an attacker to inject a
HelloRetryRequest.We shouldn't allow that, either I think. I looked at
#104 - it seems like the current plan _is_ to restart the handshake
hash in the event of HelloRetryRequest but that a server cookie must
be replayed? (Theorizing the cookie is an HMAC containing the client
ip and some other things?) I think there's an attack on that if an
attacker can forge packets from a client. (HelloRetryRequest is not
signed by the server, right?)

Client supports SecureA, SecureB, and InsecureC. Server supports
SecureA, SecureB, and InsecureC. Client sends a ClientHello with
KeyShares for A & B. <Pause> Attacker forges a packet from the
client's IP with support for C and RandomD and KeyShares for RandomD.
Server replies with a HelloRetryRequest with a cookie for that client
IP. Attacker forges a HelloRetryRequest from the server, copying the
cookie, and saying "I only support InsecureC." <Unpause> The attacker
sends the forged HelloRetryRequest to the client. Client makes a
KeyShare for InsecureC and sends it along with the cookie, which the
server recognizes as being from it for the IP, and everything proceeds
using InsecureC undetectably.   I think.

>> Also, I'm a little confused about what the client is supposed to put
>> in the outer SNI (for the gateway). Is this blank? Some constant?
>
> Whatever SNI you would use to talk to the gateway ordinarily. Otherwise
> you would have a distinguisher.

But... what is that?  If I look up example.com (over my new private
DNS link) and get an IP back to a CDN (which I wouldn't even know)...
how would I know what the "normal gateway SNI" is?

-tom

[0] To use a real-world example of a heavily censored national internet.