Hex string in TLS SNI field

Question

I'm looking at packet captures of TLS traffic, and I see TLS-encrypted connections where the SNI field contains a long hex string (a sequence of 64 hex nibbles) -- not a domain name.

What might trigger this? I'm used to HTTPS clients putting a domain name in the SNI field (the domain name of the web server they're trying to contact). Is there a TLS extension that suggests putting a hex string or hash fingerprint in the SNI field? Or is there some non-HTTPS protocol that uses TLS and puts a hex string or fingerprint in the SNI field?

The SNI spec (RFC 6066) doesn't say anything about this. It provides for SNI to carry a hostname, not any other type of value. I haven't been able to find any TLS extension that would explain this.

Answer 1

Looks like bending the rules

The IANA TLS extension registry says RFC6066 is the current defining document for the "server_name" extension.

And the RFC6066 section on SNI 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).

There is no such RFC update. None is listed in the registry. (Also no such "updated by" is listed in the RFC's first page top left corner.)

And a bit further down, there's this:

TLS MAY treat provided server names as opaque data and pass the names and types to the application.

I read this to mean "whenever we invent a new type, we may do this but now with the current DNS hostnames, we won't".

So if somebody still puts just anything in there, then I'd say they're in a grey area/bending the rules.