Hacker News new | ask | show | jobs
by whatthemick 3101 days ago
Headers and URI are encrypyed aswell, in a HTTPS request. Only the domain is exposed (when SNI is supported)
1 comments

Not trying to be pendantic but the entire hostname is exposed, not just the domain name. I’m assuming that’s what you meant.
The hostname is a domain name. Some domain names may not be hostnames, but all hostnames are domain names. So the entire domain name, which is also a hostname, is exposed.
These definitions are highly context-dependent, though.

Even more pedantic, but sometimes surprising: SNI reveals the full text of the final lookup query that the requester used to obtain an IP address to open a TCP connection to the server.

Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct).

In practice, certificate authorities constrain the possibilities of the lookup text (for a successful connection using the CA-signed cert), but that is not a technical limitation. And of course, a self-signed certificate has no such constraints.

With cooperation between the server owner and users, an SNI-sensitive publisher could make their site available at https://fbi.gov/. But it's probably easier just to use a meaningless domain instead. :)

> Neither the text nor the address are necessarily "correct", and the text might be formally a nodename, a hostname, a domain name, a fully-qualified domain name, or a text representation of an IP address (which, again, is not necessarily correct).

Please don't make claims about standards that you haven't read. SNI supports only DNS FQDNs.

You are incorrrect.

That's not quite what the spec says, and furthermore it is not true in practice.

Giving you the benefit of the doubt, I reread the spec, and I tested in nginx.

Works fine.

What spec?

RFC6066 (https://tools.ietf.org/html/rfc6066#section-3) says "Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document)." [snip] ""HostName" contains the fully qualified DNS hostname of the server, as understood by the client." [snip] "Literal IPv4 and IPv6 addresses are not permitted in "HostName"."

What works fine that is not syntactically a fully qualified DNS hostname, and what could you even test about that?
> SNI reveals the full text of the final lookup query that the requester used to obtain an IP address to open a TCP connection to the server.

Are you talking about something other than DNS lookups done at the client side?

Yes, that is how I tested it, but there's nothing magic about DNS either. Remember that this depends on the site owner and the users cooperating to put misleading data into the SNI, while still functioning properly. It isn't often useful, but it is sometimes convenient.

Basically, whatever the client does that results in a successful map of name to address (including the textual representation of the address, to the address) will cause the name to be sent in SNI, and will be used to select a matching cert on the server side.

If you do use DNS, your lookup might have a suffix appended automatically, depending on local nameserver config.