Faz pouco o lançamento da nova versão estável do Tor 0.4.4.5 foi apresentado, usado para organizar o trabalho da rede Tor anônima. Tor 0.4.4.5 é considerada a primeira versão estável do branch 0.4.4, que evoluiu nos últimos cinco meses.
A filial 0.4.4 será mantida como parte do ciclo de manutenção regular; o lançamento de atualizações será descontinuado após 9 meses (em junho de 2021) ou 3 meses após o lançamento do branch 0.4.5.x.
Além disso, um longo ciclo de suporte (LTS) também é fornecido para o branch 0.3.5, cujas atualizações serão lançadas até 1 de fevereiro de 2022. O suporte para 0.4.0.x, 0.2.9.x e 0.4.2 ramos 0.4.1.x foi descontinuado. O suporte para o branch 20.x será interrompido em 0.4.3 de maio e 15 em 2021 de fevereiro de XNUMX.
Para quem ainda não conhece o projeto Tor (O roteador Onion). Este é um projeto que tem como objetivo principal o desenvolvimento de uma rede de comunicações distribuído com baixa latência e sobreposto na internet, em que o encaminhamento das mensagens trocadas entre os usuários não revele sua identidade, ou seja, seu endereço IP (anonimato em nível de rede) e que, além disso, mantém a integridade e o sigilo das informações que por ele trafegam.
O sistema está desenhado com a flexibilidade necessária para que possa implementar melhorias, ser implantado no mundo real e resistir a diversos tipos de ataque. No entanto, ele tem pontos fracos e não pode ser considerado um sistema infalível.
Principais novos recursos do Tor 0.4.4.5
Esta nova versão do Tor vem com algumas mudanças e correções, deles destacamos os mais importantes, como algoritmo de seleção de nó sentinela aprimorado, em que o problema com o balanceamento de carga, bem como maior produtividade e segurança.
Outra grande mudança, é que a capacidade de balancear a carga dos serviços onion foi implementada. Já que um serviço baseado na terceira versão do protocolo agora pode atuar como backend para OnionBalance, que é configurado usando a opção HiddenServiceOnionBalanceInstance.
Destaca-se também que a lista de servidores de diretório sobressalentes foi atualizada, que não é atualizado desde o ano passado, e 105 dos 148 servidores continuam operacionais (a nova lista inclui 144 entradas geradas em julho).
Nos relés, é permitido trabalhar com células EXTEND2 que estão disponíveis apenas no endereço IPv6, e a expansão da cadeia sobre IPv6 também é permitida se o cliente e o relé suportarem IPv6.
Se, ao expandir as cadeias de nós, uma célula pode ser acessada simultaneamente via IPv4 e IPv6, então o endereço IPv4 ou IPv6 é escolhido aleatoriamente. A conexão IPv6 existente pode estender a cadeia. O uso de endereços IPv4 e IPv6 internos é proibido.
Também expandiu a quantidade de código que pode ser desativado ao iniciar o Tor sem suporte de retransmissão.
Além disso, também menciona-se o correto manuseio de parâmetros para a defesa DoS do serviço onion. Bem, anteriormente, os parâmetros de consenso para as defesas DoS do serviço sobrescreveriam os parâmetros definidos pelo operador do serviço por meio de HiddenServiceEnableIntroDoSDefense.
Outra correção de bug importante é o bug que estava subestimando o tráfego total do serviço cebola da rede Tor, ignorando qualquer tráfego originado de clientes.
Além disso canais que usam versões desatualizadas do handshake do Tor não podem mais ignorar as verificações canonicidade de endereços. (Este é apenas um problema menor, pois tais canais não têm como configurar chaves ed25519 e, portanto, devem ser sempre rejeitados para circuitos que especificam identidades ed25519.)
Das outras mudanças que se destacam:
- As autoridades agora recomendam versões de protocolo que são compatíveis com Tor 0.3.5 e posterior.
- Redefina o suporte para eventos de porta de controle GUARD NEW / UP / DOWN.
- Adicione suporte IPv6 para tor_addr_is_valid ().
- Adicione testes para as mudanças acima e tor_addr_is_null ().
- Permitir que clientes e retransmissões enviem células EXTEND2 de pilha dupla apenas IPv6.
- Permita que o Tor construa em plataformas onde ele não sabe relatar qual syscall causou o travamento da sandbox do Linux seccomp2.
- Permita a chamada de sistema unlinkat (), que algumas implementações Libc usam para implementar unlink ().
- Adicionados 3 novos SocksPort ExtendedErrors (F2, F3, F7) relatando um novo tipo de falhas de conexão de serviço.
Por fim, se você quiser saber mais sobre isso, pode verificar os detalhes no link a seguir