On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter <t...@ritter.vg> wrote: > 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. >
Fair enough. This seems easily solved by requiring the internal ClentHello to enclose a digest of the external ClientHello in some extension. 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? No, that's not the current plan. See: http://www.ietf.org/mail-archive/web/tls/current/msg18118.html > (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. > Well the client sends shares for A, B, and C (it is required to append the new share to the list, not replace it) for exactly this reason. So, as long as the server would prefer A or B given A, B, and C, you don't end up with C. However, as I said, we are not planning to restart the handshake hash. >> 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? Well, this isn't what would happen. You would get a response in something other than an A record that contained "here is the DNS name of the gateway". That's the only thing that can work because you need to solicit the ServerConfig from the gateway in any case. I don't see how to make this work without a channel richer than just an IP, since the client needs to know how to do Encrypted SNI. -Ekr > -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
