«Tor», «onion», «dark web», «hidden service»: parole che girano spesso insieme e altrettanto spesso confuse. Questa scheda mette in fila i concetti che servono per capire gli howto della serie: cos'è il routing a cipolla, come funziona un indirizzo .onion, perché il DNS di tutti i giorni non lo risolve, e — onestamente — cosa protegge e cosa no. Niente misticismo: è ingegneria di rete, e si spiega.
Due termini che si confondono di continuo. Il deep web è tutto ciò che i motori di ricerca non indicizzano: la tua webmail, l'home banking dietro login, le intranet aziendali, i database privati, le pagine dietro un form. È una porzione enorme del web e del tutto normale — non c'entra nulla con Tor. Il dark web è invece una fetta piccola del deep web, raggiungibile solo con software apposito (reti overlay come Tor): sono esattamente gli onion service .onion di cui parliamo qui. Quindi, a rigore: ogni volta che diciamo «dark web» intendiamo i servizi .onion su Tor — in senso tecnico, non come sinonimo di «posto losco».
C'è però un gradino ancora più in fondo, ed è un concetto che vale la pena isolare: chiamiamolo «deep dark web». È quella fetta di onion .onion che non raggiungi nemmeno conoscendone l'indirizzo — servono una chiave privata e, di fatto, un invito. È la parte stealth del dark web: non si indicizza, non si «naviga», non la trova nessun motore. O sei nella lista di chi può entrare, o per te quel servizio non esiste. È il livello più nascosto — lo apriamo in dettaglio più avanti.
Prima di entrare nel dettaglio di Tor, un chiarimento che evita l'equivoco più diffuso: «dark web» non è sinonimo di Tor. Sono almeno quattro reti anonime diverse, parallele e separate — ognuna con i suoi indirizzi, i suoi protocolli, le sue comunità e i suoi contenuti. Non si parlano tra loro: non raggiungi un .i2p da Tor, né un .loki da I2P.
| Rete | Accesso | Indirizzi | Scala | Contenuti |
|---|---|---|---|---|
| Tor | Tor Browser / demone tor | .onion | La più grande | Marketplace, leak site, forum, news: di tutto. La più facile da usare. |
| I2P | Client I2P (i2pd) | .i2p | Media | File sharing, forum tecnici, mail, torrent. Niente exit node di serie: tutto resta dentro I2P. |
| Lokinet | Client Lokinet (Oxen) | .loki | Piccola | Pochi siti, quasi tutti vetrina o esperimento. Il grosso di Oxen passa da Session (messaggistica), non dai siti .loki. |
| Freenet / Hyphanet | Client Hyphanet | Chiavi hash (USK@…) | Piccola | Archivio distribuito: documenti, testi, file statici che restano online anche se chi li ha pubblicati sparisce. Non in tempo reale. |
Il tipo di contenuto si somiglia — leak, forum, file sharing, mercati, attivismo — ma la popolazione è diversa: Tor è il mainstream; I2P è più tecnica (sviluppatori, torrent anonimi) e non «esce» sul clearnet; Lokinet è ancora di nicchia e i gruppi ransomware non ci fanno siti (usano Session per comunicare e Tor per i leak site); Freenet/Hyphanet è un archivio a chiave, senza interazione in tempo reale.
Le proporzioni sono stime, non un censimento, ma l'ordine di grandezza è netto: Tor è la quasi totalità del «dark web» che si conosce, I2P una fetta molto più tecnica, Lokinet e Freenet insieme una nicchia. Concretamente, i data leak pubblicati con la doppia estorsione stanno su Tor — è ciò che racconta l'articolo su onionwatch. Per questo cercarsi «nel dark web» significa, quasi sempre, cercarsi su Tor — ed è di Tor che parla il resto di questa scheda. Le altre reti esistono, sono attive, ma sono ecosistemi a parte.
Una normale connessione va da te al server in linea retta: il tuo IP è scritto sul pacchetto, e chi sta in mezzo (provider, server) sa chi parla con chi. Tor spezza questo legame facendo passare il traffico attraverso tre relay scelti a caso nella sua rete:
Il nome «cipolla» viene da come è cifrato il pacchetto: il client lo avvolge in più strati di cifratura, uno per relay. Ogni nodo sbuccia il suo strato e vede solo l'indirizzo del nodo successivo. Nessun singolo relay vede contemporaneamente chi e dove: è questo il punto, ed è il motivo dei tre salti. Due non basterebbero (guard ed exit insieme potrebbero collegare i due capi); tre è il minimo per garantire che nessun nodo da solo chiuda il cerchio.
Perché il client possa costruire un circuito deve sapere quali relay esistono e di quali fidarsi. Questo elenco non è gestito da una singola azienda: una decina di directory authority (server indipendenti, gestiti da persone e organizzazioni diverse) votano a intervalli regolari sullo stato della rete e producono un documento firmato — il consenso. Il client scarica il consenso e da lì sceglie i suoi relay. Decentralizzare l'elenco è parte della difesa: non c'è un singolo punto da compromettere o da obbligare per falsare la rete.
Finora abbiamo parlato di uscire verso un sito normale. Ma Tor sa fare anche l'opposto: pubblicare un servizio raggiungibile solo dentro Tor. È l'onion service (il vecchio «hidden service»), e il suo indirizzo è quel nome lungo che finisce in .onion.
Nella versione attuale (v3) l'indirizzo .onion è lungo 56 caratteri e non è un nome arbitrario: è la chiave pubblica del servizio (una chiave ed25519) codificata in base32, con un paio di byte di checksum e versione. Conseguenza elegante: l'indirizzo autentica sé stesso. Chi si connette a quel .onion sta già verificando, matematicamente, di parlare con il titolare di quella chiave — senza certificati, senza autorità, senza TLS sopra. Il nome è l'identità.
Il meccanismo, in breve: il servizio sceglie alcuni relay come introduction point e pubblica un descrittore firmato (dove e come contattarlo); chi vuole entrare lo cerca, poi i due si danno appuntamento a un rendezvous point neutro. Il dettaglio che conta per gli howto seguenti: sia il servizio sia il client fanno solo connessioni in uscita. Nessuno apre una porta, nessuno espone un IP. È proprio questa proprietà — outbound-only — che rende un onion service raggiungibile anche dietro NAT, CGNAT o un firewall che non lascia entrare nulla.
Capita di vedere onion che cominciano con una parola sensata — per dire, un servizio di data breach il cui indirizzo parte con breachdb…. Non è un caso, ma non è neppure ciò che sembra: è un vanity address, un indirizzo «di vanità». Siccome l'indirizzo è la chiave pubblica, non lo si può scegliere; però si possono generare chiavi a raffica finché, per puro caso, ne esce una il cui indirizzo inizia come si desidera. Esistono tool apposta (per la v3 il più noto è mkp224o; per le vecchie v2 erano scallion e shallot): sfornano milioni di coppie al secondo e tengono solo quella giusta — il resto dei 56 caratteri resta casuale, è vera chiave.
Perché quasi nessuno lo fa su prefissi lunghi: il costo è esponenziale. L'alfabeto base32 ha 32 simboli, quindi ogni carattere imposto in più moltiplica il lavoro per circa 32. Un prefisso di otto lettere come breachdb significa all'incirca 32⁸ ≈ 10¹² tentativi — ore o giorni di GPU per un operatore motivato; un prefisso di quindici-venti caratteri è, in pratica, irraggiungibile. Il caso più celebre è Facebook: il suo storico facebookcorewwwi.onion (v2) uscì per metà fortuna e metà forza bruta — sembra scelto a tavolino, in realtà fu «solo» pescato tra miliardi di tentativi.
La morale è la stessa dell'auto-autenticazione, e conta: un indirizzo intero non si può falsificare — sceglierli tutti e 56 i caratteri vorrebbe dire trovare la chiave privata di qualcun altro, cioè rompere ed25519 — quindi la vanity non serve a impersonare un servizio esistente. Ma il prefisso non è una garanzia: un malintenzionato può brute-forzare lo stesso inizio breachdb… e ingannare chi guarda solo le prime lettere. Per questo un .onion va verificato per intero, non a colpo d'occhio: conta la chiave completa, non l'aspetto.
Qui va sfatato il malinteso più diffuso di tutti: installare Tor non ti mette «nel dark web», come avere un browser non ti mette dentro ogni sito del web. Quello che raggiungi col solo Tor è lo strato in chiaro del dark web: onion service che rispondono a chiunque ne conosca l'indirizzo. Non sono indicizzati dai motori normali e non si «scandagliano» (l'indirizzo è una chiave da 256 bit, non si indovina), ma gli indirizzi circolano — wiki, elenchi, link — quindi in pratica si trovano. È la parte «light», ed è quasi tutto ciò che la gente chiama «dark web».
Esiste però uno strato più sotto, e non è una suggestione: la client authorization (v3). Il servizio pubblica un descrittore cifrato per i soli client autorizzati; senza la propria chiave privata, un client non riceve nemmeno il descrittore. Conseguenza: conoscere l'indirizzo non basta. Per chi non è in lista il servizio è indistinguibile dal nulla — non «porta protetta da password», ma proprio una porta che non si manifesta. Storicamente Tor chiamava questa modalità stealth (nelle vecchie onion v2 i livelli erano due, basic e stealth); in v3 il nome ufficiale è «client authorization», ma la proprietà stealth — invisibile senza invito — è rimasta, ed è il punto. È quello che qui chiamiamo deep dark web: il nome tecnico è «client authorization» (o stealth), ma il concetto è esattamente questo — il dark web che non si manifesta senza invito.
È la differenza che quasi nessuno spiega: lo strato stealth non lo «navighi». O sei sulla lista (hai la chiave), o per te non esiste: niente elenco, niente motore di ricerca che lo raggiunga, nessun modo di «capitarci». È il livello che usa chi vuole un servizio raggiungibile solo da chi ha deciso lui — strumenti interni di un'organizzazione, canali riservati, ricerca sensibile, e sì, anche i sistemi che hanno interesse a non farsi trovare affatto. Negli howto di questa serie è esattamente il meccanismo con cui pubblichiamo un servizio che risponde solo a chi diciamo noi: lo vedi in azione quando Tor Browser ti chiede la chiave prima di mostrarti qualunque cosa.
.onionSe provi a risolvere un indirizzo .onion col DNS di sempre, non ottieni nulla: non è un dominio «registrato» da qualche parte. .onion è un dominio a uso speciale riservato (RFC 7686): i resolver, per specifica, non devono inoltrarlo nel DNS pubblico. Non esiste un record A da restituire — e sarebbe comunque inutile, perché un onion non ha un IP.
La «risoluzione» avviene dentro Tor, in modo diverso: a partire dalla chiave contenuta nell'indirizzo, il client cerca il descrittore del servizio in una tabella hash distribuita tenuta dai relay stessi (gli HSDir). È questo il «DNS di Tor»: niente nomi da tradurre in IP, ma una chiave da cui si ricava dove incontrare il servizio. Per questo, su un sistema normale, aprire un .onion richiede un client Tor che faccia quella ricerca al posto del resolver di sistema.
Tor è potente, ma non è una bacchetta magica: vale la pena essere precisi su cosa garantisce.
In sintesi: per gli howto di questa serie useremo Tor in chiave difensiva — pubblicare e raggiungere i nostri servizi senza esporli, su lab isolato e solo con i nostri indirizzi. L'anonimato «da dark web» è un altro discorso, e dove serve lo diremo chiaro.
Capito com'è fatto il dark web, resta la domanda che conta per chi difende: «si parla di me, là sotto?». È per rispondere a questa che al Dojo ho costruito onionwatch, un motore di ricerca del dark web pensato in chiave difensiva: indicizza gli onion service di Tor — e sto estendendolo a I2P, Freenet/Hyphanet e Lokinet — raggruppa i mirror, classifica i siti con una motivazione, e soprattutto cerca per entità (una tua email, un dominio, un intervallo di rete, un wallet) e mette sotto monitoraggio ciò che mi interessa, avvisandomi quando spunta qualcosa di nuovo. Non è un servizio pubblico: è uno strumento d'indagine personale, con tre paletti non negoziabili — inquadramento difensivo, disciplina sulla disclosure, mai indirizzi reali. Il dark web, con uno strumento così in mano, non è più un posto oscuro: è una rete che puoi osservare.
Riferimento: The Tor Project (documentazione del progetto). Specifica dei domini a uso speciale: RFC 7686 «The ".onion" Special-Use Domain Name». Scheda di riferimento della serie «Tor / dark web»: la richiamano gli howto dedicati.