On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote: > > On May 10, 2017, at 1:28 PM, Hubert Kario <hka...@redhat.com> wrote: > > > > 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) > > There in many cases way too many virtual host names for the server to test.
if you have tens of thousands of websites you either have a farm of servers, so you can solve that with sharding, or the websites don't get much traffic so it's not a performance problem > On the other hand, the attacker with fast hashing silicon can perform the > same computation very quickly. But it does make simple keyword matching on hostname much harder or impossible. > The virtual hosts supported by the remote > server are likely not much a secret in most cases. that's argument for not spending too much resources on the encryption/ obfuscation, not that we shouldn't do it. But in general, I wonder if we didn't approach the SNI from the wrong side - as I said, we may not need to encrypt it, we just make sure that client and server agree on the virtual host the connection is going to. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
