A última atualização desta página foi em Novembro de 2016.

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.

TorI2P
CélulaMensagem
ClienteRoteador ou Cliente
CircuitoTúnel
DiretoriaNetDb
Servidor de DiretoriaRoteador baseado em Preenchimento por Inundação
Guardiões de AcessoPares rápidos
Nodo de EntradaProxy de entrada
Nodo de SaídaProxy de saída
Serviço OcultoServiço Oculto, Site ou Destino I2P
Descritor de serviço ocultoLeaseSet
Ponto de entradaPonto de entrada
NodoRoteador
Proxy CebolaCliente de túnel I2P (mais ou menos)
Serviço OnionServiço Oculto, Site ou Destino I2P
RetransmitirRoteador
Ponto de rendezvousum pouco como Inbound Gateway + Outbound Endpoint
Descritor do Roteador Informação do Roteador
ServidorRoteador

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)