Can we know a DNS for the normal HTTP of a hidden service? If the onion hidden name cannot reach from outside of Tor then maybe use that?
________________________________ From: Jesse Victors jvictors@jessevictors.com To: tor-dev@lists.torproject.org Cc: Ming Li ming.li@usu.edu Sent: Tuesday, 29 July 2014 6:03 PM Subject: [tor-dev] DNS proposal for Tor hidden services
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hello everyone,
I have a proposal for Tor hidden services, which if it's a good idea and workable I may be writing my Master's thesis on. My description here is very early, and I would like to run it by you guys before I continue further. I have already run it past Tor developers, but have seen limited response, so I'm opening it up to a wider audience. Basically, I propose integrating Namecoin into supporting Tor relays, so as to provide a secure DNS service for .onion sites within Tor itself. The result is that a human-readable address can be translated into its .onion counterpart, analogous to a domain name resolving into an IP address on the regular Internet, a square of Zooko's Triangle conjecture.
Namecoin has a nearly identical codebase to Bitcoin, but instead of currency its primary focus is holding information, with a focus in DNS. Domains in Namecoin have the .bit extension, and registrations are secured with hashes in a blockchain. Anyone with the Namecoin blockchain can look up information in it, and indeed there are already Namecoin-supporting DNS servers that use the Namecoin blockchain to look up registrations in it. These basic premises are at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address for the DuckDuckGo hidden service, but it's hard to remember: even worse than a traditional IP address. Under my idea, a user could type in duckduckgo.tor, would see a secure translation to 3g2upl4pq6kufc4m.onion transparently and with masking, increasing the usability and popularity of hidden services significantly.
My plan is in the context of Tor, to use the .tor domain, so as to not conflict with existing Namecoin registrations. The .onion address is a hash of the hidden service's public key, so if I own the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign something (perhaps the Namecoin public DSA key) to prove my ownership and set duckduckgo.tor.bit to point to 3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network as usual, (this costs 0.01 Namecoin) so that it becomes integrated into the blockchain. So now duckduckgo.tor.bit points to 3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it. Global DNS propagation may take less than 15 minutes. Namecoin domain registrations expire after 36,000 blocks (about 200 days) so a registration would have to be renewed occasionally for it to still remain. This is free to do, but ensures that domains don't endure indefinitely.
It's impractical for Tor users to download the Namecoin blockchain in order to use this system, (even with Merkle trees) so instead supporting Tor relays can hold a copy and the Tor client can send out queries to them. At startup, Tor clients build several circuits through the network in preparation for use. Now let's say the user wants to look up duckduckgo.tor. To avoid spoofing attacks from a malicious relay, Tor clients will query multiple relays and gain a consensus. To do this, the Tor client generates three nonces, N1, N2, and N3. It then picks three random relays, possible trusted relays like guards, R1, R2, and R3. These relays have public RSA keys K1, K2, and K3, respectively. For each of the three relays, the Tor client takes the request for duckduckgo.tor, nonce Nj, and encrypts the pair with the relay's public key Kj. Along with a special new Tor flag specifying the use of this protocol, it then sends the trio through the circuit to the middle relay. The middle relay then queries the three relays. Each relay decrypts the request using its private key, checks the blockchain for duckduckgo.tor.bit, finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the nonce, and sends it back, signing the result. The client receives the answers, checks the signatures, decrypts the responses from the three relays using the nonces, and compares the response. If all three match, it then looks up 3g2upl4pq6kufc4m.onion in the traditional way. If two or less match, it restarts with a different set of three relays. If all three relays return that duckduckgo.tor can't be found, it throws the standard DNS error message.
So I am simply building on top of the existing Tor hidden service infrastructure, not modifying it. I can write up a proposal for torspec.git once I have more details. I've already taken Tor 0.2.5.6-alpha code, installed Tor from source, and used Chutney to set up a mini Tor network on localhost of 5 authorities, 10 relays, and 1 client. That seems a good platform for development on this.
What do you guys think about my proposal? Is this a good idea, and feasible? Anything I should watch out for as I go forward? What security threats exist that I should specifically defend against?
Thank you for your time.
- -- Jesse V. /CS, Network Security/ /Utah State University/
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev