[tor-dev] Proposal 274: A Name System API for Tor Onion Services
jeremyrand at airmail.cc
Sat Oct 8 01:47:12 UTC 2016
> So here, the browser thinks it is connecting to debian.zkey (the URL bar
> says "debian.zkey"). But Tor is really connecting to sejnfjrq6szgca7v.onion
> in the background. What name does the browser put in its Host header? It
> can't be the onion name, because there's no feedback from the naming
> module back to the user application layer. It must be "debian.zkey"
> then. If that is a petname, then it just got leaked to the server. I can
> imagine this might also cause a problem with some virtual hosting setups
> (though I suppose those are not very common for onion services). If the
> user uses HTTPS, e.g. https://facebook.zkey/, then they'll get a TLS
> name mismatch error, even if https://facebookcorewwwi.onion/ exists and
> has a valid certificate--so using the naming system is not a transparent
> replacement for memorizing the onion address. Maybe non-HTTP protocols
> will also have problems.
In Namecoin's case, that's working as intended: if Facebook sets up a
Namecoin domain name, then they should create a TLS certificate with
their .bit domain on the SAN list, that TLS certificate should be listed
in their Namecoin name as a TLSA record, and it should be served when
the SNI header asks for the .bit domain. It's unclear to me whether
that is problematic for other naming systems. It's also unclear to me
whether this will be problematic if Facebook wants to get an EV
CA-issued cert to cover their .bit domain name, due to the political
issues around the P2P names proposal at IETF.
I'm aware that Alec Muffett isn't at Facebook anymore, but perhaps he
would be able to offer feedback on what issues might be likely to come
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the tor-dev