La tabella di marcia del ritiro di C tor: date di spegnimento, stato di Arti e cosa devono sorvegliare gli operatori
Il ritiro dell'implementazione originale di Tor in C è passato dal principio al calendario. Il 23 giugno 2026 il Tor Project ha annunciato l'intenzione di interrompere la compatibilità di rete per Tor 0.4.8 e tutte le versioni precedenti: dopo il 1° settembre 2026 quelle versioni "non funzioneranno più affatto in rete". L'annuncio, ancorato al progetto Arti Relay in corso, è finora il segnale pubblico più chiaro di come la transizione da C tor a Rust viene scaglionata.
Perché Tor viene riscritto in Rust
Arti è l'implementazione di nuova generazione dei protocolli Tor in Rust, descritta nel README del progetto come uno sforzo per costruire una base di codice incorporabile e di qualità produttiva. Le ragioni addotte sono pratiche, non estetiche. Il team stima che almeno la metà delle vulnerabilità di sicurezza tracciate sarebbe stata impossibile in un linguaggio memory-safe. La base in C, in sviluppo continuo dal 2002, ha accumulato quello che lo stesso documento chiama inutili relazioni a spaghetti tra componenti. E una libreria Rust può essere incorporata nelle applicazioni in modi che il progetto originario, nato come proxy SOCKS, non aveva mai previsto: gli sviluppatori contano che acceleri il lavoro futuro. Il calendario della migrazione è stato abbozzato nel febbraio 2023 da Nick Mathewson, cofondatore di Tor e uno degli architetti principali di Arti, in una discussione su tor-dev:Nel medio termine deprecheremo l'implementazione del client Tor in C. Questo non avverrà finché non sarà trascorso un certo tempo dal momento in cui Arti sarà un client tor completo con supporto per i servizi onion e con una soluzione completa di embedding/FFI/RPC.Nel lungo periodo, ha scritto Mathewson, Arti è destinato a sostituire completamente C tor, il che richiede anche relay e autorità di directory in Rust. Ha sottolineato che nessuna tempistica è stata impegnata e che qualsiasi calendario futuro apparirà fastidiosamente lungo da alcuni punti di vista e fastidiosamente breve da altri. A tre anni di distanza, la sequenza sta procedendo nelle grandi linee come descritto: prima il client, per ultimi i ruoli centrali della rete.
Cosa sa fare Arti oggi, e cosa no
Come client, Arti è in buona forma. Il README, aggiornato ad agosto 2026, lo definisce un client Tor completo, adatto all'uso generale: funziona come proxy SOCKS, si connette ai servizi onion e supporta i bridge con transport collegabili, tra cui obfs4 e Snowflake. Le release arrivano con regolarità. Arti 2.0.0 è arrivato a febbraio 2026, e la versione attuale, Arti 2.7.0, è uscita il 1° ottobre 2026 con ulteriori lavori di base su relay e autorità di directory più una serie di correzioni di sicurezza. Quel progresso sul lato client lo abbiamo approfondito nella nostra precedente copertura su Arti. Oltre il client, il quadro onesto è più magro. Far girare Arti come relay o autorità di directory non è ancora supportato, come dichiarano direttamente le note di rilascio della 2.0.0, e il README dei relay porta un avviso permanente: il supporto relay è sperimentale e "affatto pronto per un deployment generale", con la richiesta di non avviare relay Arti sulla rete pubblica. La lista interna del progetto mostra progressi reali — canali in ingresso, gestione di CREATE2 ed EXTEND2, ascolto sull'ORPort — mentre controllo della congestione, pubblicazione dei descrittori, exit policy e difese dai denial-of-service restano da fare. I servizi onion sono in una posizione simile sul lato servizio. La documentazione del progetto dice che un servizio fatto girare su Arti è adatto solo a test e sperimentazioni: mancano l'autorizzazione dei client, i relay vanguard, protezioni significative dai denial-of-service e il padding dei circuiti, con l'avvertenza che gestirlo potrebbe persino compromettere la privacy degli altri usi della stessa istanza Arti. Connettersi ai servizi onion da Arti come client fa invece parte del normale funzionamento client.Lo spegnimento di settembre, spiegato
La soglia del 1° settembre è una mossa di compatibilità, non una scadenza di sicurezza. Tor 0.4.8 ha già raggiunto la fine vita il 1° giugno 2026 secondo il calendario delle release del progetto e non riceve più aggiornamenti. Ciò che cambia dopo settembre è il comportamento del protocollo di directory: la serie 0.4.9 rimuove dai dati di directory le vecchie chiavi onion TAP e le righe family dei relay, seguendo le proposte 350 e 321, riducendo la banda client e accelerando il bootstrap per tutti. Poiché client e relay su 0.4.8 o precedente si aspettano la presenza delle chiavi TAP, smettono di funzionare quando quei campi scompaiono. Una motivazione secondaria è dichiarata apertamente: l'implementazione dell'autorità di directory di Arti presto avrà bisogno di integrazione con la rete, ed è più semplice da scrivere senza campi obsoleti. Non è nemmeno la fine di C tor in sé. Lo stesso calendario elenca la 0.4.9, dichiarata stabile a febbraio 2026, con una propria fine vita ancora da decidere, e una serie 0.5.0 la cui finestra di merge si è aperta a marzo 2026. Il team descrive la manutenzione attuale di C tor come comprendente funzionalità scelte per facilitare la transizione ad Arti. I progetti a valle che includono ancora versioni vecchie vengono contattati direttamente, con il lavoro di sensibilizzazione tracciato in un ticket network-health che accoglie anche le richieste degli operatori che hanno bisogno di più tempo.Cosa devono osservare gli operatori
- Operatori di relay: passare a 0.4.9.x prima del 1° settembre 2026; qualsiasi versione più vecchia uscirà dalla rete. Non esiste ancora un relay Arti verso cui migrare: prendete con scetticismo affermazioni contrarie e seguite il changelog di Arti.
- Operatori di servizi onion: C tor resta il modo supportato per gestire un servizio. I segnali che indicheranno la maturità di Arti come piattaforma di servizio sono i pezzi mancanti elencati sopra: restricted discovery, supporto vanguard, difese dai denial-of-service e padding dei circuiti.
- Sviluppatori di applicazioni: lo stato finale previsto è embedding e RPC, non un demone SOCKS incluso nel pacchetto. Arti 2.0.0 ha dichiarato sperimentali le API del crate arti di primo livello, mentre arti-client resta l'interfaccia supportata, e la 2.7.0 ha aggiunto il controllo della configurazione via RPC.