recentemente è stato presentato il rilascio della nuova versione stabile di Tor 0.4.4.5, utilizzato per organizzare il lavoro della rete Tor anonima. Tor 0.4.4.5 è considerata la prima versione stabile del ramo 0.4.4, che si è evoluto negli ultimi cinque mesi.
Il ramo 0.4.4 verrà mantenuto come parte del ciclo di manutenzione regolare; il rilascio degli aggiornamenti verrà interrotto dopo 9 mesi (nel giugno 2021) o 3 mesi dopo il rilascio del ramo 0.4.5.x.
Inoltre, è previsto anche un lungo ciclo di supporto (LTS) per il ramo 0.3.5, i cui aggiornamenti saranno rilasciati fino al 1 febbraio 2022. Il supporto per 0.4.0.x, 0.2.9.xe 0.4.2 branch 0.4.1.x è stato interrotto. Il supporto per il ramo 20.x verrà interrotto il 0.4.3 maggio e 15 il 2021 febbraio XNUMX.
Per coloro che sono ancora all'oscuro del progetto Tor (Il router per cipolle). Si tratta di un progetto il cui obiettivo principale è lo sviluppo di una rete di comunicazione distribuiti a bassa latenza e sovrapposti su Internet, in cui l'instradamento dei messaggi scambiati tra gli utenti non rivela la loro identità, cioè il suo indirizzo IP (anonimato a livello di rete) e che, inoltre, mantiene l'integrità e la segretezza delle informazioni che lo attraversano.
Il sistema è progettato con la flessibilità necessaria in modo da poter implementare miglioramenti, essere implementato nel mondo reale e resistere a diversi tipi di attacco. Tuttavia, ha dei punti deboli e non può essere considerato un sistema infallibile.
Principali novità di Tor 0.4.4.5
Questa nuova versione di Tor viene fornito con alcune modifiche e correzioni, di loro evidenziamo i più importanti come algoritmo di selezione del nodo sentinella migliorato, in cui il problema con il bilanciamento del carico, oltre a migliorare la produttività e la sicurezza.
Un altro cambiamento importante, è che è stata implementata la capacità di bilanciare il carico dei servizi onion. Poiché un servizio basato sulla terza versione del protocollo può ora fungere da backend per OnionBalance, che viene configurato utilizzando l'opzione HiddenServiceOnionBalanceInstance.
Si evidenzia inoltre che l'elenco dei server di directory di riserva è stato aggiornato, che non è stato aggiornato dallo scorso anno, e 105 dei 148 server rimangono operativi (il nuovo elenco include 144 voci generate a luglio).
Nei relè è consentito lavorare con celle EXTEND2 che sono disponibili solo sull'indirizzo IPv6, e l'espansione della catena su IPv6 è consentita anche se il client e il relay supportano IPv6.
Se, espandendo le catene di nodi, è possibile accedere simultaneamente a una cella tramite IPv4 e IPv6, l'indirizzo IPv4 o IPv6 viene scelto a caso. La connessione IPv6 esistente può estendere la catena. È vietato l'uso di indirizzi IPv4 e IPv6 interni.
Anche ha ampliato la quantità di codice che può essere disabilitata all'avvio di Tor senza il supporto del relè.
Inoltre, anche si parla della corretta gestione dei parametri per la difesa DoS del servizio onion. Ebbene, in precedenza, i parametri di consenso per le difese DoS del servizio sovrascriverebbero i parametri impostati dall'operatore del servizio tramite HiddenServiceEnableIntroDoSDefense.
Un altro bug fix importante è il bug che sottostimava il traffico totale dal servizio onion della rete Tor, ignorando qualsiasi traffico proveniente dai client.
a parte quello i canali che utilizzano versioni obsolete dell'handshake Tor non possono più bypassare i controlli canonicità degli indirizzi. (Questo è solo un problema minore, poiché tali canali non hanno modo di configurare le chiavi ed25519 e quindi dovrebbero essere sempre rifiutati per i circuiti che specificano identità ed25519.)
Delle altre modifiche che risaltano:
- Le autorità ora raccomandano versioni di protocollo compatibili con Tor 0.3.5 e successive.
- Reimposta il supporto per gli eventi della porta di controllo GUARD NEW / UP / DOWN.
- Aggiungi il supporto IPv6 a tor_addr_is_valid ().
- Aggiungi test per le modifiche precedenti e tor_addr_is_null ().
- Consenti a client e relay di inviare celle EXTEND2 dual-stack solo IPv6.
- Consenti a Tor di compilare su piattaforme in cui non sa come segnalare quale syscall ha causato il crash della sandbox seccomp2 di Linux.
- Consenti la chiamata di sistema unlinkat (), che alcune implementazioni Libc usano per implementare unlink ().
- Aggiunti 3 nuovi SocksPort ExtendedErrors (F2, F3, F7) che segnalano un nuovo tipo di errori di connessione del servizio.
Infine, se vuoi saperne di più, puoi controllare i dettagli nel file seguente link