On 5 December 2015 at 21:31, Eric Rescorla <e...@rtfm.com> wrote: > > > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter <t...@ritter.vg> wrote: >> >> On 5 December 2015 at 12:32, Eric Rescorla <e...@rtfm.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
