Deep web underground

An Architectural Overview of Onion Routing

Onion routing is a technique used by the Tor network to provide anonymity. It employs a multi-layer encryption mechanism to encapsulate data packets, ensuring that they are securely transmitted through the network.

When a user sends data over Tor, the data packet is wrapped in successive layers of encryption. Each layer corresponds to a different node in the network: entry, relay, and exit nodes. This process is akin to peeling an onion, where each layer is decrypted by a specific node along the route to the destination.

1. Entry Node: The first node in the circuit receives the data packet. It decrypts the outermost layer, revealing the next destination (the relay node) but not the original sender’s identity.

2. Relay Node: The second node further decrypts the packet, revealing the next node in the chain (the exit node) while maintaining the anonymity of both the entry and the sender.

3. Exit Node: The final node decrypts the last layer and sends the original data to the intended destination. The exit node can see the data being sent but does not know the sender's identity.

This multi-layered approach helps protect against traffic analysis attacks. Adversaries controlling strategic Autonomous Systems (ASes) can attempt to correlate timing and data patterns to de-anonymize users, but the layered encryption complicates this process significantly (3).

Tor's protocol specifications enforce fixed-size data cells of 512 bytes, ensuring consistent packet structure. This design mitigates traffic shape observation and structural packet fingerprinting, enhancing user privacy (4).

In 2021, Tor deprecated legacy version 2 onion services, fully transitioning to version 3 architecture. This change improved security by eliminating vulnerabilities associated with key enumeration (5). Each version 3 onion service uses an asymmetric public-private key pair generated with the Ed25519 elliptic-curve algorithm for robust encryption (6).

For system administrators configuring hidden services, it is crucial to ensure that directory permissions are set correctly. The service will not start if permissions are looser than 0700 (2). Avoid running a public relay on the same server as an onion service, as this can facilitate traffic correlation and fingerprinting (7).

Understanding the architecture of onion routing is essential for effectively utilizing the Tor network and maintaining anonymity while navigating the deep web.

Deep Web vs. Dark Web: Technical Distinctions

The deep web and dark web are commonly confused, but they differ significantly in structure and accessibility.

The deep web refers to all parts of the internet that are not indexed by traditional search engines. This includes databases, password-protected websites, and other resources that require authentication. For example, academic databases or private corporate intranets fall into this category. These resources are not hidden; they simply require specific access credentials to view.

In contrast, the dark web is a subset of the deep web that is intentionally hidden and inaccessible through standard web browsers. It requires specific software, such as Tor or I2P, to access. The dark web utilizes overlay networks that allow users to remain anonymous. For instance, the Tor network employs onion routing to encapsulate data packets, providing anonymity through multiple layers of encryption.

Onion services, specifically version 3, are a prominent feature of the dark web. Each version 3 onion service address is 56 characters long and encoded in Base32, utilizing a public key and a checksum for security (1). These services rely on a master identity key generated using the Ed25519 elliptic-curve algorithm (6).

The architecture of the Tor network includes:

1. Entry Node: The first point of contact, which knows the user's IP address but not the final destination.

2. Relay Node: This node further obscures the user's identity by only knowing the previous and next nodes.

3. Exit Node: This node decrypts the final layer and sends data to the intended destination, exposing the data but not the sender's identity.

Different from Tor, the Invisible Internet Project (I2P) uses unidirectional tunnels, creating separate paths for inbound and outbound traffic, which can strengthen anonymity (8).

For system administrators, ensuring proper configuration of hidden services is crucial. This involves setting directives in the /etc/tor/torrc file and maintaining strict directory permissions (2). It is advised not to host a public Tor relay on the same server as an onion service to prevent traffic correlation vulnerabilities (7).

Understanding these distinctions is essential for navigating the complexities of the deep and dark webs effectively.

Underground Network Topologies and .Onion Services

Version 3 onion services utilize advanced cryptographic techniques and innovative network topologies to enhance security and anonymity. Each onion service employs a master identity key, which is an asymmetric public-private key pair generated using the Ed25519 elliptic-curve algorithm. This method provides robust encryption and secures communications between users and services (6).

The addresses for version 3 onion services are 56 characters long. They are encoded in Base32 and consist of the public key, a 2-byte truncated SHA3-256 checksum, and a protocol version byte (1). This design ensures that the address is both unique and secure, reducing the risk of key enumeration attacks.

In the context of onion routing, rendezvous points play a crucial role. These points are established using distributed hash tables (DHT), which allow users to connect without revealing their IP addresses. When a user wants to access an onion service, they send a request to the rendezvous point, which helps facilitate the connection while maintaining anonymity.

Key components of version 3 onion services include:

1. Public-Key Cryptography: Ensures secure communication between the user and the onion service.

2. Rendezvous Points: Utilize DHT to connect users and services without exposing IP addresses.

3. Traffic Analysis Mitigation: The architecture is designed to resist timing correlation attacks, making it difficult for adversaries to de-anonymize users (3).

System administrators must follow best practices when configuring hidden services. Proper configuration involves defining the HiddenServiceDir and HiddenServicePort directives in the core configuration file /etc/tor/torrc (2). Additionally, strict file system permissions are enforced; the service will not start if the private key storage permissions are less than 0700 (2).

Avoid running a public Tor relay on the same physical instance as an onion service to prevent traffic correlation issues (7). By adhering to these guidelines, you can enhance the security of your onion services and maintain user anonymity effectively.

Traffic Analysis and De-anonymization Vectors

Traffic analysis poses significant risks to anonymity within overlay networks like Tor. Various attack vectors can be exploited to de-anonymize users. Understanding these vectors is crucial for system administrators and network engineers.

End-to-End Timing Attacks

Adversaries can execute end-to-end timing attacks by controlling strategic Autonomous Systems (ASes) or Internet Exchange Points (IXPs). This method involves correlating the timing of incoming and outgoing traffic. If an attacker can observe both ends of a communication, they may determine the origin and destination of the traffic, compromising user anonymity (3).

Malicious Exit Node Sniffing

Exit nodes are the final relay points in the Tor network. They decrypt the data before sending it to the intended destination. If a malicious actor operates an exit node, they can inspect the unencrypted traffic. This scenario is especially problematic for users who do not employ end-to-end encryption. It is essential to use secure protocols, such as HTTPS, to mitigate this risk.

Active Probing Against Misconfigured Server Daemons

Misconfigured server daemons can be targeted through active probing. Attackers can send crafted requests to identify weaknesses or misconfigurations in the server setup. For example, if a hidden service does not properly validate incoming connections, an attacker might exploit this vulnerability to gain information about the service or its users. Proper configuration of hidden services is critical. System administrators should ensure that directives in the /etc/tor/torrc file are correctly set (2).

Mitigation Strategies

1. Use of End-to-End Encryption: Always use HTTPS for sensitive communications to protect against exit node sniffing.

2. Regular Server Audits: Conduct regular audits of hidden service configurations to identify and fix vulnerabilities.

3. Avoid Running Public Relays on the Same Instance: This practice helps reduce the risk of traffic correlation and fingerprinting attacks (7).

By understanding these traffic analysis vectors and implementing effective mitigation strategies, you can enhance user anonymity and security within the Tor network.

Secure Infrastructure Configuration for Onion Services

To ensure the security of onion services, system administrators should follow specific engineering guidelines. Proper configuration is crucial for hardening a hidden service daemon and protecting against various threats.

Hardening the Hidden Service Daemon

1. Define Core Directives: In the core configuration file /etc/tor/torrc, set the HiddenServiceDir and HiddenServicePort directives. These parameters specify where the service's private keys are stored and which ports to use for incoming connections (2).

2. Set Directory Permissions: Ensure that the directory where the private keys are stored has strict permissions. The permissions must be set to 0700 or stricter. If the permissions are looser, the daemon will refuse to start (2).

3. Disable Non-Essential Modules: Turn off any unnecessary features or modules in the Tor daemon. This reduces the attack surface and limits potential vulnerabilities.

Network Namespace Isolation

Isolating network namespaces can further enhance security. By running the onion service in a separate network namespace, you can limit exposure to the broader network environment. This isolation helps mitigate risks from traffic analysis and potential attacks originating from other services on the same server.

Configuration of torrc Parameters

1. Use Version 3 Onion Services: Ensure the use of version 3 onion services, which utilize an asymmetric public-private key pair generated with the Ed25519 elliptic-curve algorithm. This enhances security and eliminates vulnerabilities associated with legacy version 2 services (6) (5).

2. Implement Traffic Analysis Countermeasures: Configure parameters to minimize the risk of traffic analysis. For example, ensure that your service does not reveal identifiable patterns in the data it sends and receives. This can involve adjusting packet sizes and using consistent timing for responses.

3. Avoid Running Public Relays on the Same Instance: It is advised not to run a public Tor relay on the same physical instance or IP address as an onion service. Doing so can facilitate traffic correlation and fingerprinting, compromising user anonymity (7).

By adhering to these guidelines, administrators can significantly enhance the security of onion services. Proper configuration and isolation practices are essential for maintaining anonymity and protecting against potential threats in the Tor network.

Protocol-Level Comparison: I2P, Freenet, and Tor

Comparing garlic routing in I2P and circuit-based onion routing in Tor reveals distinct differences in packet size, transport layer protocols, and threat models, particularly for self-hosted underground nodes.

Packet Size

Tor employs fixed-size data cells of 512 bytes, which are transported over TLS. This standardization helps mitigate traffic shape observation and structural packet fingerprinting (4). In contrast, I2P utilizes garlic routing, allowing multiple messages to be bundled together in a single packet. This can lead to variable packet sizes, enhancing anonymity by making traffic patterns less predictable.

Transport Layer Protocols

Tor primarily relies on TCP for its transport layer, ensuring reliable delivery of packets. It uses a set of directory authorities to maintain a verified list of active relays, which facilitates stable connections (9). I2P, however, supports both TCP and UDP, enabling greater flexibility in routing. The ability to use UDP can improve performance for certain applications, but it may also expose users to different vulnerabilities.

Threat Models

The threat models for both networks differ significantly. Tor's architecture is susceptible to end-to-end timing correlation attacks, especially if adversaries control key Autonomous Systems (ASes) or Internet Exchange Points (IXPs) (3). This risk is compounded by the centralized nature of its directory authorities. Conversely, I2P’s unidirectional tunnels create separate inbound and outbound paths, making timing attacks more challenging to execute (8).

For self-hosted underground nodes, these differences mean that I2P may offer a more resilient infrastructure against certain types of traffic analysis. However, Tor’s established ecosystem and user base provide robust support and resources, which can be beneficial for administrators configuring hidden services.

In summary, choosing between I2P and Tor depends on specific use cases and threat assessments. Understanding the protocol-level distinctions will help you tailor configurations to enhance security and anonymity effectively.

Summary and Actionable Steps

1. Enforce Strict Permissions: Verify that your private key directory permissions are set to 0700 to allow the daemon to launch securely (2).

2. Isolate Relays: Keep your onion services separate from public Tor relays to prevent traffic correlation risks (7).

3. Use Modern Standards: Rely on version 3 onion services with Ed25519 key pairs for enhanced cryptographic protection (6) (5).

4. Define Core Directives: Properly configure your HiddenServiceDir and HiddenServicePort parameters inside the core configuration file (2).

Review the Topic Links 3.0 Onion resource to continue optimizing your network architecture and hardening your services.