Closed sftcd closed 9 months ago
sayrer
commented
2 years ago FWIW, I'm not convinced the Topologies section deserves such prominent placement. It's barely mentioned in the text, and sort of borders on being implementation advice for client-facing servers. I think it might be better to move it down near sections 10-11, where it is mentioned a few times.
chris-wood
commented
9 months ago I think the intent here is to say that there's basically three keys floating around: (1) the ECH private keys, (2) the client-facing server public_name private key, and (3) the backend server private key. Is that correct? If so, I don't think this is unique to split mode, as these three keys still need to exist in shared mode. I'm inclined to keep the document as-is on that observation, and given how much time has elapsed here, I'm going to close as this having been overcome by events. However, please do reopen and surface on the mailing list if you feel like this still warrants a text change.
(This doesn't need any action for esni-draft-13, we can come back to it or ignore it after people have played some more with deployments of that.)
TL;DR - maybe split-mode should be described as involving three possibly independent private key holders rather than described as involving two entities (client-facing and backend) - my initial haproxy split-mode implementation maps better to the former.
I did some initial work to integrate my ECH-capable OpenSSL build with haproxy. Shared-mode had nothing much interesting about it (mostly similar to nginx, apache, lighttpd) but split-mode threw up what was for me a new thing. (My notes on that are here.)
The main thing is that, in split-mode, haproxy will decrypt the ECH fine and can then pass on the inner CH and allow the TLS h/s to continue between client and backend, but haproxy can't act as the server for the public_name as it goes out of its way to avoid being a web server. That wasn't a hard problem to handle though as I just route e.g. all non-decrypted TLS sessions to yet another external web server instance, that has the private key corresponding to ECHConfig.public_name, and which is only ECH-special in that it has to be able to answer GREASEd CH's. (But it is a bit ECH special in answering GREASE while not being a full shared-mode instance which needed a few tweaks in my server code to handle having an ECHConflg but no private key.)
So all that worked ok, and isn't really visible to the client, but if other deployments are similar we might want to recast the description of split mode to note this three-way aspect. In particular, I guess this kind of setup allows for a situation where we have could have many different public_name values for one or a small number of ECH public_key values, independent of the size of the anonymity set of will-be-encrypted SNI names protected via the ECH public_key values. I guess that's not likely what a CDN might want to do (as it probably only wants/needs to use one or a few public_name values) but maybe it'd be useful for some reason, not sure. (Looking at the mega-flexibility of the haproxy config, I'm guessing haproxy has already been deployed in many unexpected ways;-)
The three-way thing might also be relevant for security analyses, not sure.
Lastly, that three-way aspect means that we'd better not change the protocol in any way that assumes that the ECH private key holder has access to information only known to the public_name private key holder. So far that's fine and will likely stay so, but it's a maybe non-obvious invariant we should keep.