| > So, this is not a discussion about whether or not you can specify IP addresses in the SNI hostname field? In fact, no. This is a discussion about whether textual representations of IP addresses can be used as inputs to tools that speak SNI, be used to specify a particular cert on the server side, and be conveniently extracted out of the sniffed network traffic comprising that handshake. As it happens, the input conversion, the processing for usage in code written for spec implementation, the network stack conversions, and the sniffer capture reconversion back to a text representation for human viewing are all manipulative of the data. But all of these manipulations are predictable and reversible, and if you want to call one of those data stages a "DNS FQDN", that's great but it isn't inherently correct, outside of the context of the spec which deigns to treat all final mapping tokens as DNS FQDNs, and to label them such -- but does not actually make them fully-qualified, nor the results of DNS queries. We might have different opinions about the context of this discussion, but I would suggest that if you were to reread the thread from the beginning, there's really not much opportunity for confusion. In any event, it's clear that this discursion is not advancing anyone's understanding of anything. Good luck in your future endeavours. |
Well, then your original description was pretty misleading. I'm just wondering why you didn't include, I dunno, street names? You can use most street names as input for the same purpose, right?
> But all of these manipulations are predictable and reversible
Nope, that's precisely the problem. You can not distinguish the hostname "1.2.3.4" from the IP address "1.2.3.4" after they have been encoded in that manner into the SNI request, hence the encoding is not reversible (and leads to collisions).
> We might have different opinions about the context of this discussion, but I would suggest that if you were to reread the thread from the beginning, there's really not much opportunity for confusion.
Well, there is, as it's trivially true and at the same completely pointless to point out that you can use any string that fits the syntactic requirements to put it into a field of a protocol message to produce a syntactically valid protocol message.
So, yes, you can put a string that was produced as a textual representation of an IP address into the SNI hostname field. It just so happens that that is essentially guaranteed to lead to certificate validation failure during connection establishment with any non-vulnerable TLS implementations.
Was that really the point that you were trying to make?