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.
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"."
The "as understood by the client" is very important, apparently.
Furthermore, the name does not need to be in DNS. There is no single source of true DNS anyway (though of course the ~whole world uses the same root servers).
Try it. I just set up a remote server for "snitest", added the IP address to /etc/hosts only, generated a cert for that name only, and got the correct cert via SNI in a local browser.
The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.
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.