URL Dark Web

Anatomy of an Onion URL: Structure and TLD Specifications

The technical format for version 3 (v3) onion addresses is crucial for understanding how the Tor network operates. Modern v3 onion service addresses consist of exactly 56 characters, encoded in base32, followed by the .onion suffix. This encoding is derived from a 32-byte Ed25519 public key, which provides significant security improvements over previous formats (2).

To break it down further, the structure of a v3 onion address includes:

• 56-character base32-encoded string: This represents the Ed25519 public key.

• 2-byte checksum: This helps verify the integrity of the address.

• 1-byte version field: This indicates the address format version.

The transition from the deprecated version 2 (v2) format, which used a 16-character string derived from a weak 1024-bit RSA key, occurred due to security vulnerabilities. The v2 format was completely disabled across the Tor network by late 2021 (5).

One of the key features of .onion addresses is their self-authenticating nature. The cryptographic public key is embedded directly in the address, eliminating the need for traditional DNS infrastructure and centralized registrars (1). This self-authentication mechanism enhances security by binding the connection directly to the address's public key (4).

When configuring a hidden service, you will need to edit the torrc configuration file. This includes specifying the HiddenServiceDir for storage and mapping a HiddenServicePort to your local service (6). Following operational security best practices is vital; for instance, you should set strict file permissions on the HiddenServiceDir to protect sensitive files (6).

In summary, understanding the technical format of v3 onion addresses and their underlying mechanisms is essential for anyone looking to navigate the Tor network securely.

How the Tor Network Resolves .onion Links Without DNS

The Tor network uses a decentralized directory service and a distributed hash table (DHT) to resolve .onion links. Unlike traditional DNS, which relies on centralized servers, Tor clients interact with a network of relays to fetch service descriptors securely (3). This process protects user privacy by avoiding queries that could be intercepted by public DNS resolvers.

When a user wants to access a hidden service, the first step is for the Tor client to find the corresponding service descriptor. This descriptor contains information about the hidden service, including its public key and its introduction points. The client queries the DHT, which is formed by Tor relays that hold the HSDir flag. These relays store the service descriptors, allowing clients to retrieve them without exposing their requests to external networks (3).

Rendezvous Points and Introduction Points

The connection process involves two key components: introduction points and rendezvous points.

1. Introduction Points: These are servers that the hidden service chooses to use for incoming connections. The hidden service informs the DHT of its introduction points, which are then used by clients to connect to it. The hidden service sends messages through these points, allowing for secure communication without revealing its location.

2. Rendezvous Points: After the client retrieves the service descriptor, it creates a circuit to a rendezvous point. This point acts as an intermediary for the client and the hidden service, enabling them to communicate anonymously. The client and hidden service both connect to the same rendezvous point, allowing them to exchange data while keeping their identities hidden.

This method of routing ensures that neither the client nor the hidden service needs to know each other's IP addresses. Instead, they rely on the Tor network's circuit-based routing to maintain privacy and security.

For those hosting a hidden service, it is essential to configure the torrc file correctly. You must define the HiddenServiceDir and map a HiddenServicePort to your service (6). Following operational security practices, such as setting strict file permissions on the HiddenServiceDir, is crucial to protect sensitive cryptographic files (6).

By utilizing these mechanisms, the Tor network effectively resolves .onion links without traditional DNS, ensuring anonymity for both users and services.

Configuring a Tor Daemon for Hidden Services (.onion Setup)

To set up a hidden service on the Tor network, you must configure the torrc file correctly. This involves specifying the directory for your hidden service and mapping its associated port to a local service. Follow these steps to configure your Tor daemon.

1. Locate the torrc File: The torrc file is typically found in /etc/tor/torrc on Unix systems or in the Tor installation directory on Windows. You will need administrative privileges to edit this file.

2. Define HiddenServiceDir: This directive specifies the directory where Tor will store the hidden service's keys and hostname. For example:

   HiddenServiceDir /var/lib/tor/hidden_service/
   

3. Map HiddenServicePort: This directive maps the hidden service port to a local service. For instance, if you want to expose a web service running on port 80, add:

   HiddenServicePort 80 127.0.0.1:8080
   

   In this command, port 80 is the port for the hidden service, and 127.0.0.1:8080 is the local address and port of your application.

4. Set File Permissions: It is crucial to secure the HiddenServiceDir to protect sensitive files. Use the following command to set strict permissions:

   chmod 700 /var/lib/tor/hidden_service/
   

   This ensures that only the Tor process can access the directory and its contents (6).

5. Restart the Tor Service: After making these changes, restart the Tor service to apply the new configuration:

   sudo systemctl restart tor
   

6. Retrieve the .onion Address: Once Tor is restarted, check the hostname file within the HiddenServiceDir. This file contains your new .onion address, which will look like a 56-character base32 encoded string followed by the .onion suffix (2).

Example Configuration

Here’s a simplified example of what your torrc entries might look like:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:8080

Important Considerations

• Ensure that your application is listening on the specified local address and port.

• Regularly check logs for any connection attempts or errors.

• Consider implementing client authorization for enhanced security if required (6).

By following these steps, you can successfully configure a Tor daemon for your hidden service, allowing it to operate securely within the Tor network.

Verifying Onion Service Authenticity and Cryptographic Handshakes

Client-side authorization protocols are essential for ensuring the security of interactions with onion services. These protocols help verify the authenticity of the service you are connecting to, mitigating the risk of man-in-the-middle (MITM) attacks.

Public Key Pinning

Public key pinning is a technique that allows clients to associate a specific public key with an onion service. This ensures that even if an attacker tries to impersonate the service, the client can verify the public key against the pinned one. To implement public key pinning:

1. Obtain the Public Key: Extract the public key from the .onion address. For v3 onion services, this key is embedded directly in the address itself, ensuring self-authentication (1).

2. Store the Public Key: Save the public key in a secure location within your application or client configuration. This key should be associated with the specific .onion address you are accessing.

3. Verify on Connection: When connecting to the onion service, compare the received public key with the stored version. If they do not match, terminate the connection to prevent potential security breaches.

Verifying Cryptographic Identities

To further enhance security, clients can verify the cryptographic identities of onion endpoints. This process involves:

• Using the .onion Address: Since the address is derived from the Ed25519 public key, the client can independently verify the identity of the service without relying on third-party Certificate Authorities (4).

• Checking Service Descriptors: When a client resolves a .onion link, it retrieves a service descriptor from the Tor network. This descriptor contains the public key and information about the service, which the client can verify before establishing a connection (3).

• Implementing Client Authorization: Advanced configurations of v3 onion services allow for client authorization through predefined public keys stored in the authorized_clients directory. This restricts access to only those clients that possess the correct keys, adding an extra layer of security (6).

Best Practices

• Always pin the public key of the onion service to prevent MITM attacks.

• Regularly update and verify the stored public keys for all services you access.

• Use strong operational security practices, such as restricting file permissions on sensitive directories (6).

By following these protocols, you can effectively verify the authenticity of onion services and protect your communications within the Tor network.

Network Security Risks and Protocol-Level Vulnerabilities

Navigating the Tor network involves several security risks, primarily related to traffic analysis, timing attacks, and node compromises. Understanding these vulnerabilities is crucial for maintaining anonymity and security while accessing .onion services.

Traffic Analysis

Traffic analysis can expose user activities even within the Tor network. Adversaries can monitor entrance and exit nodes to correlate traffic patterns. For example, if a user consistently accesses a specific .onion service, an observer at the entry node may notice an increase in traffic to that service. This correlation could potentially lead to identifying the user or the service.

End-to-End Timing Attacks

End-to-end timing attacks exploit the latency differences in the Tor network. An attacker can measure the time it takes for a packet to travel between the client and the server. By comparing timings from various nodes, they may deduce the identities of both parties. For instance, if an attacker notices that packets sent to a particular .onion address consistently arrive faster than others, they can infer the connection is likely between those two nodes.

Exit and Entry Node Compromise

Compromised nodes pose a significant risk. If an exit node is controlled by an attacker, they can monitor unencrypted traffic leaving the Tor network. This is particularly concerning for services that do not use HTTPS, as sensitive data can be intercepted. Similarly, an attacker controlling an entry node can manipulate traffic entering the Tor network, potentially leading to information leaks.

TCP-Level Leaks and Protocol Misconfigurations

TCP-level leaks can occur when applications fail to properly configure their network settings. For example, improperly set DNS queries may expose users' real IP addresses. It is essential to ensure that applications interacting with .onion services do not attempt DNS lookups, as specified in RFC 7686 (7). Misconfigurations in the torrc file can also lead to vulnerabilities. Ensuring that the HiddenServiceDir has strict permissions (chmod 700) protects sensitive cryptographic files (6).

Recommendations

To mitigate these risks:

• Always use HTTPS for .onion services to encrypt data.

• Regularly audit your torrc configurations for potential vulnerabilities.

• Avoid using applications that do not natively support Tor, as they may expose your IP address (7).

• Implement operational security best practices to safeguard sensitive files and configurations.

By understanding these vulnerabilities and implementing best practices, you can enhance your security while navigating the Tor network.

Network Hardening: Firewall Rules for Tor Daemons

To secure your Tor daemon and prevent host system compromise, you can implement network namespaces, iptables, and SELinux/AppArmor profiles. These tools help isolate the Tor daemon from the host system, reducing the risk of vulnerabilities.

Network Namespaces

Using network namespaces allows you to create a separate network stack for the Tor daemon. This means the Tor process operates in its own environment, isolated from the host. To set up a network namespace:

1. Create a Namespace: Use the following command to create a namespace named tor-net.

   ip netns add tor-net
   

2. Run Tor in the Namespace: Start the Tor daemon within this namespace.

   ip netns exec tor-net tor
   

3. Configure Virtual Network Interfaces: Assign virtual interfaces to the namespace to manage traffic effectively.

iptables Configuration

iptables is crucial for controlling incoming and outgoing traffic. Set rules to restrict access to the Tor daemon:

1. Allow Local Traffic: Permit traffic from the localhost to the Tor daemon.

   iptables -A INPUT -i lo -j ACCEPT
   

2. Restrict External Access: Block all other incoming connections.

   iptables -A INPUT -p tcp --dport 9050 -j DROP
   

3. Log and Monitor: Consider adding logging rules to monitor traffic.

   iptables -A INPUT -j LOG --log-prefix "Tor Input: "
   

SELinux/AppArmor Profiles

Using SELinux or AppArmor can further harden your Tor setup. These tools enforce access controls on the Tor process.

1. SELinux Configuration: Create a policy that restricts Tor's access to only necessary files.

   semodule -i tor_policy.pp
   

2. AppArmor Profiles: Define a profile for Tor that limits its permissions.

   /etc/apparmor.d/usr.bin.tor
   

Best Practices

• Regularly update your iptables rules and security policies.

• Monitor logs for unauthorized access attempts.

• Test your configuration using tools like nmap to ensure only intended ports are open.

By implementing these strategies, you can effectively isolate the Tor daemon and enhance the security of your system while navigating the Tor network.

Common Configuration Pitfalls in Onion Routing Deployments

When deploying onion routing services, several common configuration pitfalls can undermine security and functionality. Addressing these issues helps ensure that your hidden services operate correctly and securely.

Clock Skew Issues

Time synchronization is crucial for the proper functioning of Tor services. Clock skew between the server and clients can lead to authentication failures. Ensure that both your server and clients synchronize their clocks using NTP (Network Time Protocol). A drift of more than a few seconds can cause connection problems, as timestamps are integral to the cryptographic processes involved in the Tor network.

Improper File Permissions

File permissions on sensitive directories and files must be strictly controlled. The HiddenServiceDir should be set to chmod 700, allowing only the Tor process to access it. This prevents unauthorized users from reading the private key files, such as hs_ed25519_secret_key, which are crucial for the operation of your hidden service (6).

Application-Layer Leaks

Applications interacting with .onion services can inadvertently leak information through various means. Two notable risks include:

1. WebRTC Leaks: If your application uses WebRTC, it may expose the user's real IP address. Ensure that any browser or application settings disable WebRTC when accessing .onion services.

2. IPv6 Leaks: If your network supports IPv6, ensure that your Tor configuration is set to avoid IPv6 traffic. This can be done by editing the torrc file to disable IPv6, as it may leak your actual IP address.

Conclusion

By addressing these common pitfalls—clock skew issues, improper file permissions, and application-layer leaks—you can enhance the security and reliability of your onion routing deployments. Regular audits of your configurations and adherence to best practices will help mitigate these risks effectively.

Summary and Next Steps

• Keep your server clocks synchronized using NTP to avoid authentication failures caused by time drift.

• Set strict file permissions on your hidden service directories to protect sensitive cryptographic keys (6).

• Isolate your Tor daemon using network namespaces and iptables rules to reduce host system risks.

• Always use HTTPS for .onion services to encrypt your data streams and prevent interception.

To continue setting up your routing infrastructure safely, review the Exploring Dark Web Servers: How They Function.