Yes, there is an HTTP Host header. Yes, responses vary by
the *value* but not by the *structure*. As far as Apache
is concerned, for instance, I would imagine it's doing a
string compare without counting or considering dots. By
discussing an arbitrary number of components, that
paragraph implies that HTTP cares about the *structure* of
the name, when it does not (although some implementations
might kludge this with
www.domain
= domain).
And I'll just hasten to add that now between you and
Richard there are two interpretations of what the text in
the document means. All I am suggesting is a bit of
clarity, please.
Hi Eliot,
I am one of the authors of this draft, and I would like to
spell out the concern which was raised to us, and which we
sought, with this paragraph to try and address.
Onion addresses are much closed to (say) dotted quads (or
other layer-3 addresses) than to domain names, albeit that to
denote them there is the label ".onion" affixed in the place
where one would expect to find a TLD.
Where the analogy between onion addresses and IP addresses
breaks down is that the following is illegal (or, at least, has
never been functionally viable):
...whereas the following *is* viable:
In some hypothetical alternate universe where we were all
using IP addresses rather than DNS to connect to endpoints, it
might be cute to support <subdomain>.<ipaddress> and
let the "Host" header (and/or the HTTPS SNI) disambiguate the
intent, though doubtless this would also lead to some kind of
disaster.
In the Onion world, the canonical representation of an onion
address is:
sixteencharlabel.onion (compare representations: 192.168.1.1,
[::1], etc)
...and in the outline we sketched of how Onions work, we
sought to describe them properly in their role as layer-3
analogues, mechanically generated hashes of a randomly generated
certificate, beyond human choice except for brute-force mining.
However, the Tor software has a party trick, that (as Richard
has explained) given an "onion" label for surety, it's happy to
parse-out the "sixteencharlabel" label and use that for
connection establishment, ignoring any other labels leftwards of
that, if any.
Of course using (say) "ssh" to connect to
www.sixteencharlabel.onion will
not be beneficial, because SSH supports neither "Host" header
nor SNI; but a web browser using HTTP/S will pass a Host header,
and thus we may effect virtual hosting over a single ".onion"
address.
In pursuit of "clarity", having had this explained, I would
welcome a better and more succinct phrasing, if you can offer
one and yet not bury the reader in unnecessary detail, or in
technical detail which might become inaccurate as
implementations improve whilst the outline remains largely
unchanged.
-a
--
Alec Muffett
Security Infrastructure
Facebook Engineering
London