[quesera]

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. :)

[zAy0LfpBZLC8mAC]

> 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.

[quesera]

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.

[detaro]

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"."

[quesera]

RFC6066, correct.

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.

[zAy0LfpBZLC8mAC]

> 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).

That is not "furthermore", that is what "as understood by the client" means.

> 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.

That is a fully qualified DNS hostname, by definition. You told both your server that it was a DNS FQDN it should serve and your client that it was a DNS FQDN that it should request, and so they obviously were matched exactly as required by the standard. Whether DNS is involved in the resolution process is irrelevant, especially so given that the standard nowhere specifies the DNS root to use.

> The same process (minus /etc/hosts modification) also worked for a bare (textual representation of an) IP address.

What was the name type in the certificate? That sounds like a bug in the client, and possibly in the server as well.

[quesera]

Is your argument that a name can be a DNS FQDN even if it is not in DNS?

A non-DNS hostname can be treated as fully-qualified since there's no organizational structure to qualify it in.

> What was the name type in the certificate?

The CN? Is the IP address, as specified at cert generation.

> That sounds like a bug in the client, and possibly in the server as well.

Perhaps. I'm not a standards adjudicator.

Nevertheless, it works in the web we have. Tested in nginx, OpenSSL, curl, Firefox.

[zAy0LfpBZLC8mAC]

What works fine that is not syntactically a fully qualified DNS hostname, and what could you even test about that?

[pritambaral]

> 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?

[quesera]

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.