This would be handy for a number of reasons:
It would make Tor better able to handle new protocols like VoIP.
It could solve the whole need to socksify applications.
Exit relays would also not need to allocate a lot of file descriptors for all the exit connections.
We're heading in this direction. Some of the hard problems are:
Os pacotes IP revelam as características do sistema operacional.
We would still need to do IP-level packet normalization, to stop things like TCP fingerprinting attacks.
Given the diversity and complexity of TCP stacks, along with device fingerprinting attacks, it looks like our best bet is shipping our own user-space TCP stack.
Os fluxos no nível do aplicativo ainda precisam ser depurados.
We will still need user-side applications like Torbutton.
So it won't become just a matter of capturing packets and anonymizing them at the IP layer.
Certos protocolos ainda vazarão informações.
For example, we must rewrite DNS requests so they are delivered to an unlinkable DNS server rather than the DNS server at a user's ISP; thus, we must understand the protocols we are transporting.
DTLS (datagram TLS) basically has no users, and IPsec sure is big.
Once we've picked a transport mechanism, we need to design a new end-to-end Tor protocol for avoiding tagging attacks and other potential anonymity and integrity issues now that we allow drops, resends, et cetera.
Exit policies for arbitrary IP packets mean building a secure Intrusion Detection System (IDS).
Our node operators tell us that exit policies are one of the main reasons they're willing to run Tor.
Adding an IDS to handle exit policies would increase the security complexity of Tor, and would likely not work anyway, as evidenced by the entire field of IDS and counter-IDS papers.
Many potential abuse issues are resolved by the fact that Tor only transports valid TCP streams (as opposed to arbitrary IP including malformed packets and IP floods.)
Exit policies become even more important as we become able to transport IP packets.
We also need to compactly describe exit policies in the Tor directory, so clients can predict which nodes will allow their packets to exit.
Clients also need to predict all the packets they will want to send in a session before picking their exit node!
The Tor-internal name spaces would need to be redesigned.
We support onion service ".onion" addresses by intercepting the addresses when they are passed to the Tor client.
Fazer isso no nível do IP exigirá uma interface mais complexa entre o Tor e o resolvedor de DNS local.
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.
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.
That said, we do want to encourage Tor users to run relays, so what we really want to do is simplify the process of setting up and maintaining a relay.
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.
There are four steps we need to address before we can do this though:
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.
See Section 5 of the Challenges paper for details.
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.
Three different research papers describe ways to identify the relays in a circuit by running traffic through candidate relays and looking for dips in the traffic while the circuit is active.
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 .