Hacker News Reader

Comment by Lt_Riza_Hawkeye | Hacker News Reader

> if SNI is not needed, than the ip address is neccesarily unique

I think your are confused about what SNI does. SNI is not part of the request, and it does not indicate to the server which website is being requested (this is the HTTP Host header, still in use as a pseudo-header in HTTP/2 and HTTP/3).

SNI is part of the response from the server back to the client. The idea is that if an attacker somehow poisoned your DNS to point the domain of one legitimate site (for example, paypal.com) to another (let's say pastebin.org) - your browser would notice the mismatch and refuse to load the page or send any potentially sensitive data to the server.

Furthermore - there is no need for it to be sent in the clear. Cloudflare in particular has thrown their weight behind a proposal/protocol extension called ESNI (Encrypted SNI), in an effort that truly turned around my opinion of the company.

View on HN

This is largely incorrect. SNI is used to tell the server which domain it needs to send a certificate for (i.e. to securely prove it owns that domain). You are right that it is separate from the HTTP host header, but in practice they are always the same because (in lieu of other information) the client wants assurance that the server owns a valid certificate for the HTTP host it is requesting to.

What makes SNI complicated to secure is that until the client has securely established the server's identity, it could be a MITM. But to prove the identity to the client, the server needs to know which proof the client needs.

Alternative solutions like "send certificates for all domains" have other issues such as performance, scalability and trivially leaking to anyone the full list of domains served.

ESNI is clever, but more complex to deploy. It's only in recent years that HTTPS has become widely used at all, and that's mainly thanks to deployment becoming largely trivial via ACME and free via Let's Encrypt.

> SNI is not part of the request ... SNI is part of the response from the server back to the client.

SNI is sent by the client, in the request, at the TLS layer.

It's purpose is to let the server know which certificate it should use to respond to the request.

Not in the request but as part of connection establishment (ClientHello). At that point in time the protocol (eg http/1 or /2 or something completely different) isn’t even determined - and so no [http] request exists yet.

> SNI is part of the response from the server back to the client. The idea is that if an attacker somehow poisoned your DNS to point the domain of one legitimate site (for example, paypal.com) to another (let's say pastebin.org) - your browser would notice the mismatch and refuse to load the page or send any potentially sensitive data to the server.

Others have mentioned that this is incorrect - i just wanted to say i think the confusion came in here because the acronym SNI (Server name indicator) is very close to the acronym SAN (subject Alt Name), which is probably what you were thinking of.

Computer people and our acronyms are impossible to keep straight.

According to Wikipedia, SNI is sent by the client to the server:

https://en.wikipedia.org/wiki/Server_Name_Indication

Reply on news.ycombinator.com