Exigir que cada usuário do Tor seja um retransmissor ajudaria a dimensionar a rede para atender todos os nossos usuários, e administrar um retransmissor Tor pode ajudar no seu anonimato. Contudo, muitos usuários do Tor não podem ser bons retransmissores — por exemplo, alguns clientes do Tor operam por trás de firewalls restritivos, conectam-se via modem, ou então não estão em posição de poder retransmitir tráfego. Fornecer serviço a esses clientes é uma parte crítica do fornecimento de anonimato efetivo para todos, uma vez que muitos usuários do Tor estão sujeitos a essas ou outras restrições semelhantes e incluir esses clientes aumenta o tamanho do conjunto de anonimato.

Dito isso, nós realmente queremos incentivar os usuários do Tor a executarem relés, então o que realmente desejamos é simplificar o processo de configurar e manter um relé. Fizemos muito progresso com configuração fácil nos últimos anos: o Tor é bom em detectar automaticamente se está acessível e quanta largura de banda pode oferecer.

Existem quatro etapas que precisamos abordar antes de conseguirmos fazer isso, no entanto:

• Primeiro, ainda precisamos melhorar a estimativa automática da quantidade certa de largura de banda a ser permitida. Pode ser que mudar para um transporte UDP seja a resposta mais simples aqui — o que, infelizmente, não é uma resposta muito simples de forma alguma.

• Em segundo lugar, precisamos trabalhar na escalabilidade, tanto da rede (como parar de exigir que todos os retransmissores do Tor possam se conectar a todos os retransmissores do Tor) quanto do diretório (como parar de exigir que todos os usuários do Tor conheçam todos os retransmissores do Tor ). Mudanças assim podem ter um grande impacto no anonimato potencial e real. Veja a Seção 5 do artigo Desafios para mais detalhes. Novamente, o transporte UDP ajudaria aqui.

• Em terceiro lugar, precisamos entender melhor os riscos de permitir que o invasor envie tráfego por meio de sua retransmissão enquanto você também inicia seu próprio tráfego anônimo. Três diferentes artigos de pesquisa descrevem maneiras de identificar os relés em um circuito executando tráfego através de relés candidatos e procurando quedas no tráfego enquanto o circuito está ativo. Esses ataques de obstrução não são tão assustadores no contexto do Tor, desde que os retransmissores também nunca sejam clientes. Entretanto, se estamos tentando incentivar mais clientes a também ativarem a funcionalidade de retransmissor (seja como retransmissores ponte ou como retransmissores normais), precisamos entender melhor essa ameaça e aprender a amenizá-la.

• Em quarto lugar, podemos precisar de algum tipo de esquema de incentivo para encorajar as pessoas a retransmitir o tráfego para outras e/ou a se tornarem nós de saída. Aqui estão nossos pensamentos atuais sobre os incentivos do Tor.

Por favor, ajude em tudo isso!

Seria bom permitir que os operadores de retransmissão digam coisas como reject www.slashdot.org em suas políticas de saída, em vez de exigir que eles aprendam todo o espaço de endereço IP que pode ser coberto pelo site (e também bloquear outros sites em esses endereços IP).

Há dois problemas, no entanto. Primeiro, os usuários ainda podem contornar esses bloqueios. Por exemplo, eles podem solicitar o endereço IP em vez do nome do host ao sair da rede Tor. Isso significa que as operadoras ainda precisam aprender todos os endereços IP dos destinos em questão.

O segundo problema é que permitiria que invasores remotos censurassem sites arbitrários. Por exemplo, se um operador do Tor bloqueia www1.slashdot.org e, em seguida, algum invasor envenena o DNS do retransmissor do Tor ou altera esse nome de host para resolver o endereço IP de um site de notícias importante, de repente esse retransmissor do Tor está bloqueando o site de notícias .

Não, você não pode confiar na rede para escolher o caminho. Retransmissões maliciosas podem encaminhá-lo através de seus amigos em conluio. Isso daria a um adversário a capacidade de observar todo o seu tráfego de ponta a ponta.

Isso seria útil por vários motivos: Isso tornaria o Tor mais capaz de lidar com novos protocolos como VoIP. Isso poderia resolver toda a necessidade de colocar aplicativos em socksificar. Relés de saída também não precisariam alocar muitos descritores de arquivo para todas as conexões de saída.

Estamos indo nessa direção. Alguns dos problemas difíceis são:

1. Os pacotes IP revelam as características do sistema operacional. Ainda precisaríamos fazer a normalização de pacotes no nível IP, para impedir coisas como ataques de impressão digital TCP. Dada a diversidade e complexidade das pilhas TCP, juntamente com os ataques de impressão digital de dispositivos, parece que nossa melhor aposta é enviar nossa própria pilha TCP de espaço de usuário.

2. Os fluxos no nível do aplicativo ainda precisam ser depurados. Ainda precisaremos de aplicativos do lado do usuário como o Torbutton. Portanto, não será apenas uma questão de capturar pacotes e torná-los anônimos na camada IP.

3. Certos protocolos ainda vazarão informações. Por exemplo, devemos reescrever os pedidos de DNS para que sejam entregues a um servidor DNS não vinculado em vez do servidor DNS do provedor de serviços de Internet de um usuário; assim, devemos entender os protocolos que estamos transportando.

4. O DTLS (datagram TLS) basicamente não tem usuários, e o IPsec é realmente abrangente. Depois de escolhermos um mecanismo de transporte, precisamos projetar um novo protocolo Tor de ponta a ponta para evitar ataques de marcação e outros possíveis problemas de anonimato e integridade, agora que permitimos descartes, reenvios, etc.

5. Políticas de saída para pacotes IP arbitrários significam construir um Sistema de Detecção de Intrusão (IDS) seguro. Nossos operadores de nós nos dizem que as políticas de saída são um dos principais motivos pelos quais estão dispostos a executar o Tor. Adicionar um IDS para lidar com políticas de saída aumentaria a complexidade de segurança do Tor e provavelmente não funcionaria de qualquer forma, como evidenciado por todo o campo de artigos sobre IDS e contra-IDS. Muitos possíveis problemas de abuso são resolvidos pelo fato de que o Tor transporta apenas fluxos TCP válidos (em oposição ao IP arbitrário, incluindo pacotes malformados e inundações de IP). As políticas de saída se tornam ainda mais importantes à medida que nos tornamos capazes de transportar pacotes IP. Também precisamos descrever de forma compacta as políticas de saída no diretório Tor, para que os clientes possam prever quais nós permitirão a saída de seus pacotes. Os clientes também precisariam prever todos os pacotes que desejam enviar em uma sessão antes de escolher o nó de saída!

6. Os espaços de nomes internos do Tor precisariam ser redesenhados. Oferecemos suporte a endereços ".onion" do serviço onion, interceptando os endereços quando eles são passados para o cliente Tor. Fazer isso no nível do IP exigirá uma interface mais complexa entre o Tor e o resolvedor de DNS local.