David Fifield: > 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 up here? Cheers, -Jeremy
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev