User Controls
How does TOR handle DNS queries for hidden services?
-
2015-07-01 at 10:20 AM UTCI read that normally the exit node queries the DNS server which sends the resolved host back through the network. But how does this work with .onion domains?
-
2015-07-01 at 1:40 PM UTCThis is actually pretty complicated, I'll see if I can remember it all.
In short, there's no DNS, and a .onion address is not a domain, but a 16 character string derived from the hidden service's public key.
When a hidden service comes online, it builds circuits to several relays and sends them its public key, which tells the relays it wants to use them as introduction points.
It then creates a hidden service descriptor and uploads it to Tor's distributed hash table, which is spread across all relays with the HSDir flag. The descriptor contains the service's public key and information about its introduction points, and is signed by its private key.
Once a client knows the .onion address of the service, it connects to the DHT to retrieve the hash, and learns about the service's public key and introduction points.
The client builds a circuit to another relay, which it will use as a rendezvous point, and tells it a one time secret. It then creates an introduce message containing the one time secret and information about the rendezvous point, and signs it with the service's public key. It sends this message to the introduction point, which then forwards it to the service.
The service decrypts the introduce message with its private key, creates a rendezvous message containing the one time secret, and sends it to the rendezvous point.
The rendezvous point tells the client that a connection has been established, and they procede to communicate over separate Tor circuits. Few people realize that connecting to a hidden service involves 6 hops instead of 3, which is one of the reasons they tend to be so slow and time out often.
Also worth noting that the key pair used for authentication is only 1024 bit RSA, which is a pretty major criticism of hidden service security. I'm not really sure if I trust them anymore given that the implementation hasn't been updated in years. -
2015-07-01 at 2:29 PM UTC
This is actually pretty complicated, I'll see if I can remember it all.
In short, there's no DNS, and a .onion address is not a domain, but a 16 character string derived from the hidden service's public key.
When a hidden service comes online, it builds circuits to several relays and sends them its public key, which tells the relays it wants to use them as introduction points.
It then creates a hidden service descriptor and uploads it to Tor's distributed hash table, which is spread across all relays with the HSDir flag. The descriptor contains the service's public key and information about its introduction points, and is signed by its private key.
Once a client knows the .onion address of the service, it connects to the DHT to retrieve the hash, and learns about the service's public key and introduction points.
The client builds a circuit to another relay, which it will use as a rendezvous point, and tells it a one time secret. It then creates an introduce message containing the one time secret and information about the rendezvous point, and signs it with the service's public key. It sends this message to the introduction point, which then forwards it to the service.
The service decrypts the introduce message with its private key, creates a rendezvous message containing the one time secret, and sends it to the rendezvous point.
The rendezvous point tells the client that a connection has been established, and they procede to communicate over separate Tor circuits. Few people realize that connecting to a hidden service involves 6 hops instead of 3, which is one of the reasons they tend to be so slow and time out often.
Also worth noting that the key pair used for authentication is only 1024 bit RSA, which is a pretty major criticism of hidden service security. I'm not really sure if I trust them anymore given that the implementation hasn't been updated in years.
That's pretty interesting, i was also wondering via what potocol this all transpires. Normal DNS goes via UDP but since there is no DNS involved is it safe to assume this all transpires via TCP? Sorry if it's a silly question but my knowledge of networking is pretty limited as of yet.
-
2015-07-01 at 3:08 PM UTCAll TCP. Tor doesn't handle UDP yet.
-
2015-07-01 at 3:28 PM UTC
All TCP. Tor doesn't handle UDP yet.
Not yet? Will it do so in the future to your knowledge? -
2015-07-01 at 11:15 PM UTCAlso what's the benefit of enabling UDP together with TCP on TOR, when both are layer 4 and TCP is generally considered to be more reliable?
-
2015-07-01 at 11:57 PM UTCIt's listed as a very long term milestone.
https://trac.torproject.org/projects/tor/ticket/7830
It would be nice to have UDP support because it works better for certain programs where performance and lower latency are desired, for example VoIP clients. -
2015-07-02 at 5:51 AM UTC
It's listed as a very long term milestone.
https://trac.torproject.org/projects/tor/ticket/7830
It would be nice to have UDP support because it works better for certain programs where performance and lower latency are desired, for example VoIP clients.
My nigga'. Thanks for the insightful responses. -
2019-08-13 at 5:43 AM UTCIdklol
