Tor / Onion Routing
[Tor] [Onion Routing]O Tor e o Roteamento Cebola são ambos redes de proxies para anonimato, e permitem que pessoas se comuniquem por meio de tunelamento nas suas redes mix de baixa latência. As duas principais diferenças entre Tor / Roteamento-Cebola e I2P estão, novamente, relacionadas a diferenças no modelo de risco e no projeto do proxy de saída (ainda que o Tor também suporte serviços ocultos). Adicionalmente, o Tor se vale da abordagem baseada em diretórios - fornecendo um ponto centralizado para gerenciar a 'visão' global da rede, bem como para recolher e reportar estatísticas, em oposição ao banco de dados da rede I2P, que é distribuído, e a seleção de pares.
A funcionalidade de proxy de saída da/o I2P/Tor possuem algumas fraquezas substanciais contra certos atacantes - uma vez que a comunicação deixe a rede mix, adversários compassivos globais podem mais facilmente perpetrar análise de tráfego. Ademais, os proxies de saída possuem acesso ao texto puro dos dados transferidos em ambas direções, e proxies de saída são inclinados a aproveitar, levando em conta todos os outros problemas de segurança que viemos a conhecer e apreciar com o tráfego da Internet comum.
Todavia, muitas pessoas não precisam se preocupar com essas situações, haja visto que estão fora do seu modelo de risco. E está, também, fora do escopo funcional (formal) da I2P (se alguém quiser construir a funcionalidade de proxy de saída no topo da camada de comunicação, pode fazê-lo). Na verdade, alguns usuários da I2P aproveitam atualmente essa vantagem do Tor para proxy de saída.
Comparação para Terminologia de Tor e I2P
As redes Tor e I2P são semelhantes em muitos aspectos, mas muito da terminologia é diferente.
Tor | I2P |
---|---|
Célula | Mensagem |
Cliente | Roteador ou Cliente |
Circuito | Túnel |
Diretoria | NetDb |
Servidor de Diretoria | Roteador baseado em Preenchimento por Inundação |
Guardiões de Acesso | Pares rápidos |
Nodo de Entrada | Proxy de entrada |
Nodo de Saída | Proxy de saída |
Serviço Oculto | Serviço Oculto, Site ou Destino I2P |
Descritor de serviço oculto | LeaseSet |
Ponto de entrada | Ponto de entrada |
Nodo | Roteador |
Proxy Cebola | Cliente de túnel I2P (mais ou menos) |
Serviço Onion | Serviço Oculto, Site ou Destino I2P |
Retransmitir | Roteador |
Ponto de rendezvous | um pouco como Inbound Gateway + Outbound Endpoint |
Descritor do Roteador | Informação do Roteador |
Servidor | Roteador |
Benefícios do Tor sobre I2P
- Base de usuários muito maior; muito mais visibilidade nas comunidades acadêmicas e no mundo hacker; beneficiada por estudos formais de anonimia, resistência e desempenho; possui lideranças não-anônimas, visíveis, nas universidades
- Já solucionou algumas questões de escalonamento que a I2P ainda não
- Possui financiamento significativo
- Possui mais desenvolvedores, muitos dos quais recebem financiamento
- Mais resistente a bloqueios de níveis-de-estado devidos a pontes e camada de transporte TLS (a I2P tem propostas de "rotas completamente restritas", que não foram ainda implementadas)
- Grande o suficiente para que ele tenha tido que se adaptar a tentativas de bloqueio e DOS
- Projetada e otimizada para tráfego de saída, com um número enorme de nodos de saída
- Documentação melhor, com artigos e especificações formais, melhor website, muito mais traduções
- Maior eficiência no uso de memória
- Nós-clientes da rede Tor possuem sobrecarga de banda muito pequena
- Controle centralizado reduz a complexidade em cada nó e pode eficientemente contrapor-se a ataques Sybil
- Um núcleo de nós de alta capacidade proporciona taxas de transferência mais altas e latência mais baixa
- C, não Java (ewww)
Benefícios do I2P sobre Tor
- Projetada e otimizada para serviços ocultos, que são mais rápidos do que na rede Tor
- Totalmente distribuído e organização automática
- Os pares são selecionados por meio da criação contínua de perfis e classificação de desempenho, em vez de confiar na capacidade reivindicada
- Os pares de enchimento ("servidores de diretório") são variáveis e não confiáveis, em vez de codificados
- Pequeno o suficiente para que ele não tenha sido bloqueado ou DOSed muito, ou em tudo
- Amigável ponto a ponto
- Comutação de pacotes em vez de comutados por circuito
- balanceamento de carga de mensagem transparente e implícito ao longo de vários pares, ao invés de um único caminho
- resiliência a falhas ao executar vários túneis em paralelo, além de rotacionar túneis
- escalar conexões de cada cliente a O(1) ao invés de O(N) (Alice tem, por exemplo, 2 túneis de entrada que são usados por todos os pares com os quais Alice está conversando, em vez de um circuito para cada)
- Túneis unidirecionais ao invés de circuitos bidirecionais, dobrando o número de nodos que um par tem de comprometer para obter alguma informação. Contra-argumentos e maiores discussões aqui.
- Proteção contra a detecção de atividade do cliente, mesmo quando o atacante está participando do túnel, já que túneis são usados para mais do que simplesmente passar mensagens de ponta a ponta (por exemplo, netDb, gerência de túnel, teste de túnel)
- Os túneis no I2P são de curta duração, diminuindo o número de amostras que um atacante pode usar para montar um ataque ativo com, ao contrário dos circuitos em Tor, que são tipicamente de vida longa.
- As APIs da I2P são especialmente projetadas para anonimato e segurança, enquanto o SOCKs é projetado para funcionalidade.
- Essencialmente, todos os pares participam roteando para todos os demais
- O overhead de largura de banda por ser um par completo é baixo, enquanto no Tor, ao passo em que os clientes não requerem muita banda, eles não participam inteiramente na mixnet.
- Mecanismo de atualização automática integrado
- Ambos os transportes TCP e UDP
- Java, não C (ewww)
Outros benefícios do i2P mas ainda não implementados
... e talvez não sejam implementados, por isso, não conte com eles!
- Defesa conta análise de número de mensagens por meio de embrulho garlic de várias mensagens
- Defesa conta interseção de longo termo por meio da adição de atrasos em vários pulos (em que os atrasos não são discerníveis em outros pulos)
- Várias estratégias de mistura a nível de túnel (por exemplo, criar um túnel que irá lidar com 500 mensagens / minuto, onde o endpoint injetará mensagens fictícias se não há mensagens suficientes, etc)