When people first encounter Tor Onion Services, one detail often seems almost paradoxical:<\/p>\n\n\n\n
\nHow can a server be reachable from anywhere on the Internet if users do not know its IP address?<\/p>\n<\/blockquote>\n\n\n\n
On the ordinary Internet, a public server normally has to reveal where it is.<\/p>\n\n\n\n
A website such as:<\/p>\n\n\n\n
example.com\n<\/code><\/pre>\n\n\n\nis usually resolved through DNS:<\/p>\n\n\n\n
example.com\n \u2193\nDNS\n \u2193\n203.0.113.10\n \u2193\nWeb Server\n<\/code><\/pre>\n\n\n\nThe client eventually connects toward the server\u2019s IP address.<\/p>\n\n\n\n
An Onion Service works very differently.<\/p>\n\n\n\n
Instead of publishing a server IP address, Tor allows a service to publish a cryptographic identity and establish connections entirely through the Tor network.<\/p>\n\n\n\n
This is the basic idea behind what is sometimes informally called an Onion server<\/strong>.<\/p>\n\n\n\n
\n\n\n\n1. \u201cOnion Server\u201d Is Not a Special Kind of Hardware<\/h2>\n\n\n\n
There is no special physical machine called an Onion server.<\/p>\n\n\n\n
An Onion Service can run on an ordinary computer:<\/p>\n\n\n\n
\n
- Linux server<\/li>\n\n\n\n
- VPS<\/li>\n\n\n\n
- desktop computer<\/li>\n\n\n\n
- Raspberry Pi<\/li>\n\n\n\n
- virtual machine<\/li>\n\n\n\n
- container host<\/li>\n\n\n\n
- home server<\/li>\n<\/ul>\n\n\n\n
The machine itself can be completely ordinary.<\/p>\n\n\n\n
What makes it an Onion Service is the presence of Tor software configured to publish a local service through the Tor network.<\/p>\n\n\n\n
For example, a machine might already have a web application running locally:<\/p>\n\n\n\n
127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nWithout Tor, that service is only accessible from the same machine.<\/p>\n\n\n\n
With an Onion Service:<\/p>\n\n\n\n
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion\n \u2193\n Tor Network\n \u2193\n Tor Service\n \u2193\n 127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nNow a Tor user can reach that local application from anywhere.<\/p>\n\n\n\n
The web application itself does not need to understand Tor.<\/p>\n\n\n\n
It may simply be:<\/p>\n\n\n\n
\n
- Nginx<\/li>\n\n\n\n
- Apache<\/li>\n\n\n\n
- Caddy<\/li>\n\n\n\n
- a Python application<\/li>\n\n\n\n
- Node.js<\/li>\n\n\n\n
- a self-hosted web interface<\/li>\n<\/ul>\n\n\n\n
Tor provides the anonymous transport layer around it.<\/p>\n\n\n\n
\n\n\n\n2. The Server Does Not Publish Its Public IP Address<\/h1>\n\n\n\n
This is one of the most important differences from ordinary hosting.<\/p>\n\n\n\n
A traditional public website usually exposes a chain such as:<\/p>\n\n\n\n
Domain\n \u2193\nDNS\n \u2193\nPublic IP\n \u2193\nRouter \/ Firewall\n \u2193\nServer\n<\/code><\/pre>\n\n\n\nIf a website is hosted at home, the architecture may look like:<\/p>\n\n\n\n
Internet\n \u2193\nPublic IP\n \u2193\nHome Router\n \u2193\nPort Forwarding\n \u2193\nInternal Server\n<\/code><\/pre>\n\n\n\nAnyone connecting to the server can normally determine the public IP address.<\/p>\n\n\n\n
An Onion Service changes the model:<\/p>\n\n\n\n
Tor Client\n \u2193\nTor Network\n \u2193\nOnion Service\n \u2193\nLocal Application\n<\/code><\/pre>\n\n\n\nThe client does not need to know the server\u2019s public IP.<\/p>\n\n\n\n
Instead, both sides communicate through Tor circuits.<\/p>\n\n\n\n
This creates a very unusual property:<\/p>\n\n\n\n
\nA service can have a stable public address without publishing its physical network location.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n3. The
.onion<\/code> Address Is the Service Identity<\/h1>\n\n\n\nOn the ordinary web, a domain name and a server are conceptually separate.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
example.com\n<\/code><\/pre>\n\n\n\nis registered through the domain-name system and later configured to point toward a server.<\/p>\n\n\n\n
An Onion Service does not work that way.<\/p>\n\n\n\n
Modern Onion Services use a cryptographic key pair.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Private Key\n \u2193\nPublic Key\n \u2193\nEncoded identity information\n \u2193\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion\n<\/code><\/pre>\n\n\n\nThe
.onion<\/code> address is therefore closely related to the cryptographic identity of the service.<\/p>\n\n\n\nThere is no conventional process equivalent to:<\/p>\n\n\n\n
Buy domain\n\u2193\nRegister domain\n\u2193\nConfigure authoritative DNS\n\u2193\nPoint DNS record to IP\n<\/code><\/pre>\n\n\n\nInstead:<\/p>\n\n\n\n
Generate Onion Service keys\n\u2193\nDerive .onion address\n\u2193\nPublish service through Tor\n<\/code><\/pre>\n\n\n\nThis is why
.onion<\/code> addresses are long and apparently random.<\/p>\n\n\n\nThey are not primarily human-readable names.<\/p>\n\n\n\n
They represent cryptographic identities.<\/p>\n\n\n\n
\n\n\n\n4. There Is No Ordinary DNS Lookup<\/h1>\n\n\n\n
Suppose a Tor Browser user enters:<\/p>\n\n\n\n
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion\n<\/code><\/pre>\n\n\n\nThe browser does not send that address to:<\/p>\n\n\n\n
Google DNS\nCloudflare DNS\nISP DNS\nDNS Root Servers\n<\/code><\/pre>\n\n\n\nThe normal DNS hierarchy is not responsible for
.onion<\/code>.<\/p>\n\n\n\nInstead, Tor uses its own Onion Service discovery system.<\/p>\n\n\n\n
This means the question is not:<\/p>\n\n\n\n
\n\u201cWhat IP address corresponds to this hostname?\u201d<\/p>\n<\/blockquote>\n\n\n\n
The question is closer to:<\/p>\n\n\n\n
\n\u201cHow can a Tor client establish a secure anonymous connection with the service that owns this cryptographic identity?\u201d<\/p>\n<\/blockquote>\n\n\n\n
That distinction is fundamental.<\/p>\n\n\n\n
\n\n\n\n5. The Onion Service First Creates Introduction Points<\/h1>\n\n\n\n
An Onion Service needs some way for clients to begin contacting it.<\/p>\n\n\n\n
But it cannot simply publish:<\/p>\n\n\n\n
Onion address \u2192 Server IP\n<\/code><\/pre>\n\n\n\nThat would immediately reveal the server.<\/p>\n\n\n\n
Instead, the Onion Service establishes Tor circuits to several relays called:<\/p>\n\n\n\n
\nIntroduction Points<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Introduction Point A\n \/\nOnion Server \u2500 Introduction Point B\n \\\n Introduction Point C\n<\/code><\/pre>\n\n\n\nMore accurately:<\/p>\n\n\n\n
Onion Service\n \u2502\n \u251c\u2500\u2500 Tor circuit \u2500\u2500 Introduction Point A\n \u2502\n \u251c\u2500\u2500 Tor circuit \u2500\u2500 Introduction Point B\n \u2502\n \u2514\u2500\u2500 Tor circuit \u2500\u2500 Introduction Point C\n<\/code><\/pre>\n\n\n\nThe introduction points do not need to know the real-world identity of the service.<\/p>\n\n\n\n
They simply act as controlled contact points inside the Tor network.<\/p>\n\n\n\n
\n\n\n\n6. The Service Publishes a Descriptor<\/h1>\n\n\n\n
The Onion Service then creates information describing how clients can initiate contact.<\/p>\n\n\n\n
This information is called an:<\/p>\n\n\n\n
\nOnion Service Descriptor<\/strong><\/p>\n<\/blockquote>\n\n\n\n
The descriptor contains information related to the service\u2019s introduction mechanism.<\/p>\n\n\n\n
It does not simply publish the server\u2019s public IP address.<\/p>\n\n\n\n
The descriptor is stored on selected Tor relays that perform the role of:<\/p>\n\n\n\n
\nHSDir \u2014 Hidden Service Directory<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Onion Service\n \u2502\n \u2502 publish descriptor\n \u25bc\n HSDir Relays\n<\/code><\/pre>\n\n\n\nThese directories form part of a distributed system.<\/p>\n\n\n\n
This is somewhat analogous to a directory service, but it is fundamentally different from ordinary DNS.<\/p>\n\n\n\n
\n\n\n\n7. A Client Finds the Service Without Learning Its IP<\/h1>\n\n\n\n
When Tor Browser receives an Onion address, it uses information derived from that address and the Tor network state to locate the appropriate service descriptor.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Tor Browser\n \u2502\n \u2502 .onion address\n \u25bc\nTor Network\n \u2502\n \u25bc\nHSDir\n \u2502\n \u25bc\nService Descriptor\n<\/code><\/pre>\n\n\n\nThe descriptor tells the client enough to begin communicating with the Onion Service.<\/p>\n\n\n\n
Crucially, the descriptor does not need to reveal:<\/p>\n\n\n\n
Server public IP\n<\/code><\/pre>\n\n\n\nThe client learns how to contact the service through Tor<\/strong>, rather than where the server physically exists on the Internet.<\/p>\n\n\n\n
\n\n\n\n8. The Client Does Not Connect Directly to the Server<\/h1>\n\n\n\n
This is the most elegant part of the Onion Service architecture.<\/p>\n\n\n\n
The client chooses another Tor relay to become a:<\/p>\n\n\n\n
\nRendezvous Point<\/strong><\/p>\n<\/blockquote>\n\n\n\n
The client creates a Tor circuit toward it:<\/p>\n\n\n\n
Client\n \u2502\n \u2502 Tor Circuit\n \u25bc\nRendezvous Point\n<\/code><\/pre>\n\n\n\nThe client then sends information through one of the service\u2019s Introduction Points indicating where it would like the service to meet.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Client\n \u2502\n \u25bc\nIntroduction Point\n \u2502\n \u25bc\nOnion Service\n<\/code><\/pre>\n\n\n\nThe Onion Service then independently creates its own Tor circuit toward the Rendezvous Point.<\/p>\n\n\n\n
Eventually:<\/p>\n\n\n\n
Client\n \u2502\n \u2502 Tor Circuit\n \u25bc\nRendezvous Point\n \u25b2\n \u2502 Tor Circuit\n \u2502\nOnion Service\n<\/code><\/pre>\n\n\n\nThe two parties meet inside the Tor network.<\/p>\n\n\n\n
Neither side needs to establish a direct Internet connection to the other.<\/p>\n\n\n\n
\n\n\n\n9. There Is No Tor Exit Relay<\/h1>\n\n\n\n
This is another major difference between ordinary Tor browsing and Onion Services.<\/p>\n\n\n\n
When accessing a normal public website through Tor:<\/p>\n\n\n\n
Client\n \u2193\nTor Guard\n \u2193\nTor Relay\n \u2193\nTor Exit\n \u2193\nNormal Website\n<\/code><\/pre>\n\n\n\nEventually traffic must leave Tor and enter the ordinary Internet.<\/p>\n\n\n\n
That requires an Exit Relay<\/strong>.<\/p>\n\n\n\n
With an Onion Service:<\/p>\n\n\n\n
Client\n \u2193\nTor\n \u2193\nRendezvous\n \u2191\nTor\n \u2191\nOnion Service\n<\/code><\/pre>\n\n\n\nThe communication remains inside the Tor network.<\/p>\n\n\n\n
There is no conventional Tor exit.<\/p>\n\n\n\n
This brings several important consequences:<\/p>\n\n\n\n
\n
- the server does not see the client\u2019s real IP;<\/li>\n\n\n\n
- the client does not see the server\u2019s real IP;<\/li>\n\n\n\n
- no exit relay is needed;<\/li>\n\n\n\n
- communication is protected by the Onion Service protocol;<\/li>\n\n\n\n
- both sides communicate through Tor circuits.<\/li>\n<\/ul>\n\n\n\n
This is why Onion Services are sometimes described as providing anonymity to both ends<\/strong> of the connection.<\/p>\n\n\n\n
\n\n\n\n10. Why Port Forwarding May Be Unnecessary<\/h1>\n\n\n\n
This is one of the most practical consequences of the architecture.<\/p>\n\n\n\n
Consider a normal server behind a home router.<\/p>\n\n\n\n
Its internal address might be:<\/p>\n\n\n\n
192.168.x.x\n<\/code><\/pre>\n\n\n\nThe server cannot normally accept connections directly from the Internet because NAT separates the private network from the public Internet.<\/p>\n\n\n\n
Traditional hosting therefore requires something like:<\/p>\n\n\n\n
Internet\n \u2193\nPublic IP\n \u2193\nRouter\n \u2193\nPort Forwarding\n \u2193\n192.168.x.x:443\n<\/code><\/pre>\n\n\n\nThe router must explicitly allow inbound traffic.<\/p>\n\n\n\n
An Onion Service does not work this way.<\/p>\n\n\n\n
The server itself establishes outbound Tor connections<\/strong>.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Home Server\n \u2502\n \u2502 outbound connection\n \u25bc\nTor Network\n<\/code><\/pre>\n\n\n\nA remote client also connects outbound into Tor:<\/p>\n\n\n\n
Remote Client\n \u2502\n \u25bc\nTor Network\n<\/code><\/pre>\n\n\n\nThe Tor network then brings the two sides together.<\/p>\n\n\n\n
So the architecture becomes:<\/p>\n\n\n\n
Tor Network\n \/ \\\n \/ \\\n Tor Client Home Server\n \u2502\n Local Service\n<\/code><\/pre>\n\n\n\nThe home router does not necessarily need to accept a direct public inbound connection to the application.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
\nAn Onion Service can often expose a service globally without traditional port forwarding.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
This is particularly useful behind:<\/p>\n\n\n\n
\n
- NAT<\/li>\n\n\n\n
- carrier-grade NAT<\/li>\n\n\n\n
- changing public IP addresses<\/li>\n\n\n\n
- restrictive inbound firewalls<\/li>\n<\/ul>\n\n\n\n
provided outbound Tor connectivity is available.<\/p>\n\n\n\n
\n\n\n\n11. Dynamic Public IP Addresses Become Much Less Important<\/h1>\n\n\n\n
Traditional self-hosting often depends heavily on a public IP address.<\/p>\n\n\n\n
If the address changes:<\/p>\n\n\n\n
Old IP\n \u2193\nDisconnected\n \u2193\nNew IP\n \u2193\nUpdate Dynamic DNS\n<\/code><\/pre>\n\n\n\nThis is why many home servers use Dynamic DNS.<\/p>\n\n\n\n
An Onion Service is different.<\/p>\n\n\n\n
Its identity is based on cryptographic keys rather than the current public IP address.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
Public IP changes\n \u2193\nTor reconnects\n \u2193\nSame Onion Service identity\n \u2193\nSame .onion address\n<\/code><\/pre>\n\n\n\nAs long as the Onion Service retains its private key, the Onion address can remain the same.<\/p>\n\n\n\n
This effectively separates:<\/p>\n\n\n\n
\nservice identity<\/strong><\/p>\n<\/blockquote>\n\n\n\n
from:<\/p>\n\n\n\n
\nnetwork location<\/strong><\/p>\n<\/blockquote>\n\n\n\n
That is a major architectural difference from conventional Internet hosting.<\/p>\n\n\n\n
\n\n\n\n12. A Stable Address Without a Stable Location<\/h1>\n\n\n\n
This property is worth emphasizing.<\/p>\n\n\n\n
Traditional hosting typically assumes:<\/p>\n\n\n\n
Stable service\n \u2193\nStable DNS\n \u2193\nKnown network destination\n<\/code><\/pre>\n\n\n\nTor allows:<\/p>\n\n\n\n
Stable service identity\n \u2193\nStable .onion address\n \u2193\nChanging or hidden physical network location\n<\/code><\/pre>\n\n\n\nA server could theoretically:<\/p>\n\n\n\n
\n
- change ISP;<\/li>\n\n\n\n
- move to another network;<\/li>\n\n\n\n
- obtain another public IP;<\/li>\n\n\n\n
- move behind another router;<\/li>\n\n\n\n
- move from one machine to another;<\/li>\n<\/ul>\n\n\n\n
while retaining the same Onion Service identity, provided the necessary Onion Service private keys are transferred securely.<\/p>\n\n\n\n
From the client’s perspective, the Onion address remains unchanged.<\/p>\n\n\n\n
\n\n\n\n13. The Application Can Listen Only on Localhost<\/h1>\n\n\n\n
Another useful security property is that the actual application does not necessarily need to listen on a public network interface.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Web Application\n127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nTor can be configured conceptually as:<\/p>\n\n\n\n
.onion:80\n \u2193\n127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nThe application remains bound to localhost:<\/p>\n\n\n\n
Internet \u2500\u2500X\u2500\u2500> 127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nbut Tor can reach it locally:<\/p>\n\n\n\n
Tor Process \u2500\u2500\u2500\u2500\u2500> 127.0.0.1:8080\n<\/code><\/pre>\n\n\n\nThis provides a clean separation:<\/p>\n\n\n\n
External world\n \u2193\nTor\n \u2193\nLocal service\n<\/code><\/pre>\n\n\n\ninstead of:<\/p>\n\n\n\n
External world\n \u2193\nOpen firewall port\n \u2193\nPublicly listening web server\n<\/code><\/pre>\n\n\n\nIt does not eliminate the need for normal application security, but it can significantly reduce direct network exposure.<\/p>\n\n\n\n
\n\n\n\n14. An Onion Service Does Not Have to Be a Website<\/h1>\n\n\n\n
The word \u201cserver\u201d often creates the impression that Onion Services are only web servers.<\/p>\n\n\n\n
That is not true.<\/p>\n\n\n\n
Tor transports TCP connections, so many TCP-based services can potentially be exposed through Onion Services.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Onion Service\n\u251c\u2500 HTTP website\n\u251c\u2500 HTTPS website\n\u251c\u2500 SSH\n\u251c\u2500 chat server\n\u251c\u2500 file transfer service\n\u251c\u2500 custom API\n\u2514\u2500 custom TCP application\n<\/code><\/pre>\n\n\n\nFor example:<\/p>\n\n\n\n
xxxxxxxx...onion:22\n \u2193\n Tor\n \u2193\n127.0.0.1:22\n \u2193\n SSH\n<\/code><\/pre>\n\n\n\nThe Onion Service acts as an anonymous network-access layer.<\/p>\n\n\n\n
The underlying application may remain almost completely unaware that Tor exists.<\/p>\n\n\n\n
\n\n\n\n15. Client Anonymity and Server Anonymity Are Different Problems<\/h1>\n\n\n\n
Ordinary Tor browsing mainly protects the client.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Client\n \u2193\nTor\n \u2193\nExit\n \u2193\nexample.com\n<\/code><\/pre>\n\n\n\nThe website is public and its infrastructure can generally be located.<\/p>\n\n\n\n
Tor hides the client from the website.<\/p>\n\n\n\n
An Onion Service protects both sides differently:<\/p>\n\n\n\n
Anonymous Client\n \u2193\n Tor\n \u2193\nAnonymous Service\n<\/code><\/pre>\n\n\n\nThe client does not need to know the server\u2019s IP.<\/p>\n\n\n\n
The server does not need to know the client\u2019s IP.<\/p>\n\n\n\n
This creates a symmetrical architecture that ordinary web hosting does not provide.<\/p>\n\n\n\n
\n\n\n\n16. The Server Is Hidden, but Not Magically Invulnerable<\/h1>\n\n\n\n
Hiding the network location does not make the application secure by itself.<\/p>\n\n\n\n
An Onion Service can still contain:<\/p>\n\n\n\n
\n
- vulnerable software;<\/li>\n\n\n\n
- weak passwords;<\/li>\n\n\n\n
- application bugs;<\/li>\n\n\n\n
- misconfigured permissions;<\/li>\n\n\n\n
- outdated dependencies;<\/li>\n\n\n\n
- information leaks;<\/li>\n\n\n\n
- identifying metadata.<\/li>\n<\/ul>\n\n\n\n
For example, an application might accidentally display:<\/p>\n\n\n\n
internal hostname\npublic hostname\nemail address\nsoftware paths\nserver metadata\n<\/code><\/pre>\n\n\n\nor make separate outbound connections outside Tor.<\/p>\n\n\n\n
Such mistakes can reveal information independently of the Onion protocol.<\/p>\n\n\n\n
Therefore:<\/p>\n\n\n\n
\nNetwork-location anonymity and application security are separate problems.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Tor protects the transport architecture.<\/p>\n\n\n\n
The service still needs normal security engineering.<\/p>\n\n\n\n
\n\n\n\n17. An Onion Service Is Not a VPN Tunnel<\/h1>\n\n\n\n
It is also useful to distinguish Onion Services from VPNs.<\/p>\n\n\n\n
A VPN typically creates:<\/p>\n\n\n\n
Device\n \u2193\nEncrypted Tunnel\n \u2193\nVPN Server\n \u2193\nInternet\n<\/code><\/pre>\n\n\n\nThe VPN server acts as a network gateway.<\/p>\n\n\n\n
An Onion Service instead creates a service endpoint inside Tor:<\/p>\n\n\n\n
Client\n \u2193\nTor Network\n \u2193\nRendezvous\n \u2191\nTor Network\n \u2191\nService\n<\/code><\/pre>\n\n\n\nThere is no requirement for a single central gateway that knows both endpoints.<\/p>\n\n\n\n
The architecture and trust model are fundamentally different.<\/p>\n\n\n\n
\n\n\n\n18. Why This Architecture Is Unusual<\/h1>\n\n\n\n
Traditional Internet architecture often exposes location as part of communication.<\/p>\n\n\n\n
To connect to something, a client usually needs to know where it is.<\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
Identity\n \u2193\nAddress\n \u2193\nLocation\n \u2193\nConnection\n<\/code><\/pre>\n\n\n\nTor Onion Services break this relationship.<\/p>\n\n\n\n
They allow:<\/p>\n\n\n\n
Identity\n \u2193\nCryptographic Onion Address\n \u2193\nAnonymous Rendezvous\n \u2193\nConnection\n<\/code><\/pre>\n\n\n\nThe physical server location does not have to be revealed as part of service discovery.<\/p>\n\n\n\n
This can be summarized as:<\/p>\n\n\n\n
\nConnect to an identity instead of connecting to a location.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
That is perhaps the most important conceptual difference between an Onion Service and an ordinary Internet server.<\/p>\n\n\n\n
\n\n\n\n19. Ordinary Hosting and Onion Hosting Compared<\/h1>\n\n\n\n
Property<\/th> Ordinary Internet Server<\/th> Onion Service<\/th><\/tr><\/thead> Address<\/td> Domain name<\/td> .onion<\/code> address<\/td><\/tr>Name system<\/td> DNS<\/td> Tor Onion Service mechanism<\/td><\/tr> Address registration<\/td> Usually required for domain<\/td> Not required<\/td><\/tr> Public IP normally exposed<\/td> Yes<\/td> No<\/td><\/tr> Server location discoverable<\/td> Usually<\/td> Designed to be hidden<\/td><\/tr> Port forwarding behind NAT<\/td> Often required<\/td> Often unnecessary<\/td><\/tr> Static public IP required<\/td> No, but useful<\/td> Not required<\/td><\/tr> Dynamic DNS useful<\/td> Often<\/td> Usually unnecessary<\/td><\/tr> Client knows server IP<\/td> Normally yes<\/td> No<\/td><\/tr> Server knows client IP<\/td> Normally yes<\/td> No<\/td><\/tr> Tor exit relay required<\/td> N\/A or yes when reached through Tor<\/td> No<\/td><\/tr> Cryptographic service identity<\/td> Usually certificate-based<\/td> Built into Onion identity<\/td><\/tr> Works behind NAT<\/td> With forwarding or tunneling<\/td> Often directly via outbound Tor<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The important difference is not simply encryption.<\/p>\n\n\n\n
It is the network architecture itself.<\/p>\n\n\n\n
\n\n\n\n20. The Deeper Idea: Separating Identity From Location<\/h1>\n\n\n\n
The ordinary Internet tightly couples several concepts:<\/p>\n\n\n\n
Domain\n \u2193\nIP address\n \u2193\nNetwork\n \u2193\nPhysical server\n<\/code><\/pre>\n\n\n\nAn Onion Service deliberately weakens those relationships.<\/p>\n\n\n\n
Cryptographic identity\n \u2193\n .onion address\n \u2193\n Tor\n \u2193\nHidden network location\n<\/code><\/pre>\n\n\n\nThe address represents who the service cryptographically is<\/strong>, not simply where the server currently resides<\/strong>.<\/p>\n\n\n\n
This is why Onion Services can provide capabilities that initially appear surprising:<\/p>\n\n\n\n
\n
- a server can be globally reachable without publicly advertising its IP address;<\/li>\n\n\n\n
- it can operate behind NAT without conventional inbound port forwarding;<\/li>\n\n\n\n
- its public IP can change without changing its Onion identity;<\/li>\n\n\n\n
- both client and server can avoid directly learning each other’s IP addresses;<\/li>\n\n\n\n
- no conventional DNS registration is necessary;<\/li>\n\n\n\n
- the entire connection can remain inside the Tor network.<\/li>\n<\/ul>\n\n\n\n
An \u201cOnion server\u201d is therefore not really a special server at all.<\/p>\n\n\n\n
It is an ordinary service placed behind an extraordinary addressing and routing architecture.<\/p>\n\n\n\n
The most important idea can be reduced to one sentence:<\/p>\n\n\n\n
\nAn Onion Service allows the Internet to reach a service by cryptographic identity rather than by directly exposing its physical network location.<\/strong><\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"
When people first encounter Tor Onion Services, one detail often seems almost paradoxical: How can a server be reachable from anywhere on the Internet if users do not know its IP address? On the ordinary Internet, a public server normally has to reveal where it is. A website such as: …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[120],"tags":[245],"class_list":["post-6152","post","type-post","status-publish","format-standard","hentry","category-1s3b6h7r2zay02x","tag-tor"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6152","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/comments?post=6152"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6152\/revisions"}],"predecessor-version":[{"id":6153,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6152\/revisions\/6153"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6152"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}