Home » Articles » How We Talk to Hidden Services?
Click Here To Hide Tor

How We Talk to Hidden Services?

It’s true that networking protocols and technologies have changed drastically through the years; from Arpanet, Hubs, BBS and even serial cable WAN connections spanning states and even countries. It is also true that the popular and standard communication protocols have changed quite a bit as well: ATM, Frame Relay, X.25 and eventually TCP/IP. All of these changes have been the result of some problem needing solved or some process needing improved. With the exception of IPv6, IP addressing hasn’t evolved as quickly as other technological paradigms; and the same could be said about domain names. Up until recently there has been very little change to the foundations of the domain since its introduction in the 80s. Recently ICANN (The International Corporation for Assigned Names and Numbers) released a slew of new top level domain extensions bringing some major variety to the internet destinations we visit.

We are no longer limited to the traditional .com, .ca, .uk, .org, .edu, .gov and .net domains (to name a few). You will now see all sorts of wild domain names like .eat, .game, .mom and .space – in fact there reportedly at least 1000 out there. The decision has moved a mostly unchanged part of the tech world into the 21st century. Though this is big news for many it’s certainly not the most noteworthy development in online names. As we all know, Hidden Services have changed the way we used the internet in a drastic way. Although, this is not technically a change to the traditional domain name system, it certainly runs parallel to it.

There may be many out there wondering how Hidden Services work and how they differ from the normal Domain Name System. Well, if you are one of those people, you’re in luck; I am going to quickly explain how DNS (Domain Name System) works and then explore how Hidden Services compare.  In reality, domain names are meaningless and largely exist to make our lives easier. When you browse to CNN.com, you’re not going to “CNN.com”, you’re going to Similarly, when you make your way to Google.com, you’re not actually going to “Google.com”, you’re going to or one of their many other public IP addresses. You see, we communicate with network destinations (whether public or private) on a number made up of 4 octets – this is only a half truth as ipv6 addresses are hexadecimal and made up of 8 hextets, but we’re going to leave that alone today and stick with IPv4. We use 4 octets because of the role binary plays in computing. You could really say that IPv4 is a more memorable way to remember and understand binary numbers, just as DNS is a memorable way to remember IPv4 addresses. Remember CNN.com at Well, you’re really going to 10011101.10100110.11100010.00011010. Google.com is much easier to remember than, which in turn is much easier to remember than 10101100.11011001.00000001.01101110. But, this is not a lesson in subnetting or binary – we want to talk about DNS and more importantly Hidden Services.

The Domain Name System exists for a few reasons: it provides us with common domains that can be used to group together or “workgroup” computers. Domains are also useful for setting up common email addresses in Exchange or non-Microsoft email equivalents. Perhaps most importantly, DNS provides us with a memorable way to reach websites, servers and other online destinations. As mentioned, every network device must have an IP address. Your private IP address is locally significant on your LAN and will be translated to a single public IP as it leaves your home or office. So when and how does the name translation occur?

Let’s say I’m sitting on my computer with IP address and I want to visit Google.com. My network doesn’t know how to get there yet, but it does know that my way to the internet is through my gateway My gateway has been preconfigured with DNS servers, which are likely owned and operated by my ISP. My request is routed to the primary DNS server, still using IP addresses. My ISP’s DNS server will either have a record for Google.com, or it will forward the lookup to another DNS server and possibly many more consecutive DNS servers until the record is located and an IP is sent back to my PC. My PC is now sending a session to, or whichever Google.com IP is accepting the next connection. If you open a command prompt or terminal and execute the command nslookup reddit.com, you will notice that it returns a long list of IPs. This is common for busy sites, which will use some form or load balancing (such as round robin) to spread the load across multiple servers. This used to be the case with Google as well, but today it’s only returning one single IP A few months ago, it was returning the IP (as seen in FIGURE A), which perfectly illustrates why it is necessary to query external DNS servers. If all sites used one single IP that never changed, we could save them all in a local hosts file on our PCs, but with Network Address Translation and massive Server Farms, IPs are always changing. Corporations and offices quite often have their own local DNS servers, used to save time and bandwidth, but these are always pointing to at least 1 or 2 external DNS sources for unknown or outdated lookups.

FIGURE A – Typical Home DNS Lookup


So now that everyone has a basic understanding of DNS we can ask the question: If Hidden Services are ‘hidden’ then how do we find them? This is where things start to stray from the normal operation of DNS. First, because Hidden Services are hidden, they are not stored in massive DNS databases the same way Clearnet sites are. Originally, there was no way to even find reference to a TOR Hidden Service without actually using TOR, but lately there has been much squawking over lists and directories of TOR sites being available on the Clearnet – This is pretty irrelevant because simply knowing a Hidden Services address doesn’t make It ‘known’ although it may find its way on LEA’s radar more quickly.

Above I mentioned that the latest big change to happen to domains was the release of hundreds of new top level domain extensions. Ironically, there is only one on TOR, likely because it is virtually meaningless (yes, much more meaningless than DNS). All TOR Hidden Services sites end with the domain extension .onion. Names and extensions mean so much less on TOR – to the point that many people have to save their favorite market addresses or check them on somewhere like Deepdotweb.com. Another key difference between normal web servers using DNS and TOR Hidden Services: public IP addresses. For a Clearnet server to be reachable on the internet, it must have a public IP defined in DNS, which is then translated to the internal private IP. Because Hidden Services use circuits built through the TOR software you don’t need to use your public IP in any step of the process. That’s not to say that your public IP isn’t being used to facilitate the communication, but it does not have to be presented to the outside world as the destination for your Hidden Service. This increases security and makes it so that TOR Hidden Services can be operated behind a firewall on private IPs. I’m sure you are all wondering what I once wondered: If no DNS entry is required and no domain name is bought, then where does the .onion URL come from? TOR actually generates the URL using a shirt summary of your TOR public key.

If Hidden Services are not identifiable in DNS directories, nor public IPs used to advertise the sites then how do we know about them and next how do we find them? Unlike Clearnet sites, which have to have a manual record created to in DNS to be reachable, TOR Hidden Services will actually advertise their existence when they build circuits to completely random relays and begin using the relays as introduction points (FIGURE B).

FIGURE B – Hidden Service Intro Points

hiddens2Once the TOR user becomes aware of the Hidden Service, and makes a request to visit, a rendezvous point is initiated by the TOR User (FIGURE C):

FIGURE C – User Rendezvous Point        


The introduction circuits and rendezvous points only provide a means for the endpoints to meet somewhere in the middle to communicate. A one-time secret key is packaged with the rendezvous point location and is then delivered to the TOR Hidden Service, although this is not delivered directly but through the various ‘introduction points’ (FIGURE D). The idea is that when one node receives this kind of traffic from another, it only knows where to send it but does not know where it came from. Once this is received, the Hidden Service will connect to the rendezvous point and send back its own one-time secret to the user at which point an encrypted session is established between the two via the rendezvous point (FIGURE E). This will continue through the rendezvous point for the duration of the session (FIGURE F), but if they decide to make communication the next day the path will never be the same.

FIGURE D – Key & Rendezvous Delivery


FIGURE E – Secret Key returned to user


FIGURE F – Established Encrypted Session


I have said it before, but I will say it again: the TCP/IP model of IP addresses and domain names was never meant to be anonymous. The very foundation of our online communication is inherently public and identifiable. It’s probably for this reason (among others) that TOR Hidden Services were not built on top of the current Domain Name System but were sort of tacked on to the side finding other brilliant ways around the inevitably traceable networking systems we have ended up with. Just as TOR succeeded in bring anonymity by thinking outside the box, LEA are taking the same approach to de-anonymize TOR and its users. AT some point TOR may be broken wide open and by that time we can only hope that a whole new method of anonymous network communication has been built on top of, within or completely separate from, this tell all system we’re stuck with. In the meantime, I plan to take in the ingenuity and genius that has made TOR Hidden Services possible; if only for a short time.

Leave a Reply

Your email address will not be published. Required fields are marked *


Captcha: *