The SNI extension is optional, so you don't have to send the literal
value. Indeed quite some number of apps do not send it. Browsers
currently can't know if the SNI is required by the origin servers and
usually send this, but there could be some signal to not send it. One
example could be a HTTP header to tell the browser that SNI should be
send and if it isn't present then no SNI is send. Unfortunately this
would break current sites but still it can be done the other way around
e.g. send a header to not send SNI.
Regards,
Roland
Am 10.05.2017 um 19:28 schrieb Hubert Kario:
Yes, encrypted SNI was discussed and ultimately rejected.
But do we really have to send the literal value? Don't we need to just make
sure that the client and server agree on the host that the client wants to
connect?
Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
the salt and the resulting hash, making the server calculate the same hash
with each of the virtual host names it supports and comparing with the client
provided value?
(apologies if that was already proposed and rejected)
_______________________________________________
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
