Dear Stephen, I published a draft describing "Fake SNI" designed for the same purpose. It allows (at least in theory) to cheat those who blocks all the handshakes containing ESNI.
вс, 28 июля 2019 г., 15:25 Stephen Farrell <stephen.farr...@cs.tcd.ie>: > > Hiya, > > ESNI drafts -03 and -04 envisage that the ESNIKeys.public_name > and the TLS h/s cleartext SNI are the same. I'd expect that > they mostly will be. > > But they don't have to be. A client could provide a way to > use a client-chosen cleartext SNI when using ESNI to encrypt > the real SNI. > > For example, my openssl build allows this for s_client. I've > a colleague who's got a first build of curl using that that > also allows such a local over-ride. I think other command-line > clients might be likely to also support that kind of thing, if > for no other reason than the existence of the draft-02 version > that's deployed and has no public_name. But I guess being able > to do a local over-ride may also be generally useful, while > not being so useful for web browsers. For example, if a given > public_name value is being censored, clients might at that > point want to use something else. > > On the server side, my code also make no checks that the > cleartext SNI used was the same as the public_name. And I > don't think that causes any problems, so maybe ought be > allowed too. > > I don't think allowing this (if the WG decide to) requires > any major change to the spec, but there are a couple of > language changes needed in section 5.1.3 and I guess we > should add a sentence to the effect that using the public_name > value from ESNIKeys in the cleartext SNI is recommended > if you've no other value but is not required. > > Cheers, > S. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
