Anonimato numa Internet Policiada. Segurança e considerações usando redes alternativas – Versão 2.1

Olá a todos,

Hoje decidi repescar um post meu sobre redes anónimas alternativas.

O que é uma rede anónima? É uma rede que permite comunicação, anti-delação, acesso e partilha de conteúdos censurados e proibidos.
Muito infelizmente têm sido usadas para operações menos licitas, mas o seu valor é inestimável quando a liberdade de informação e de comunicação se encontra ameaçada.

Estas redes, podem e parcialmente conseguem garantir liberdade de informação em ambientes fortemente censurados, como os que tem estado a surgir recentemente pelo mundo.
É importante sublinhar que existem riscos no seu uso, riscos que abordo no post mais a frente, mas é importante que exista a noção que o risco existe e é bem presente.
Este tipo de tecnologia  de privacidade tem vindo a assumir um papel contra-sistema, de combate a situações em que algumas pessoas (e muitos governos) gostariam de vos fazer acreditar, que quem não deve não teme.

Tem tal impacto esta linha de pensamento, que tem surgido redes sociais alternativas, sistemas de partilha de informação e delação (como por exemplo o Wikileaks ou o GAB) que tentam trazer para a luz o que se esconde nas trevas.

A desconfiança do que é dito e publicado já em 2009, fez-me procurar e descobrir o projeto I2P feito por uma comunidade extremamente ativa com as mesmas preocupações.

Na semelhança da Freenet e do TOR, o I2P é um projeto interessante com suporte direto a SMTP, POP3, IRC, MTM, etc, com a possibilidade acrescida de ser um protocolo aberto, com código aberto.
Tem um comportamento aplicativo de infraestrutura, ou seja, necessita de uma aplicação que se comporta como um router para aceder a rede I2P em si.

Da parte do opensource herdaram o conceito de abertura que por si permite a validação exaustiva do código e a construção é possível dos vossos próprios plugins para as vossas aplicações, com resultados muito interessantes em termos de segurança e anonimato.

O crescimento deste tipo de redes tem sido amplamente alimentado pelo aparecimento de governos absolutistas e a distribuição e concentração dos nodes é resultado disto, conforme indicado em estudos recentes:

Os pontos fortes deste encapsulamento são:

I2P is an anonymizing network, offering a simple layer that identity-sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties.

Many applications are available that interface with I2P, including mail, peer-peer, IRC chat, and others.

The I2P project was formed in 2003 to support the efforts of those trying to build a more free society by offering them an uncensorable, anonymous, and secure communication system. I2P is a development effort producing a low latency, fully distributed, autonomous, scalable, anonymous, resilient, and secure network. The goal is to operate successfully in hostile environments. even when an organization with substantial financial or political resources attacks it. All aspects of the network are open source and available without cost, as this should both assure the people using it that the software does what it claims, as well as enable others to contribute and improve upon it to defeat aggressive attempts to stifle free speech.

Anonymity is not a boolean – we are not trying to make something “perfectly anonymous”, but instead are working at making attacks more and more expensive to mount. I2P is a low latency mix network, and there are limits to the anonymity offered by such a system, but the applications on top of I2P, such as Syndie, I2P mail, and I2PSnark extend it to offer both additional functionality and protection.

I2P is still a work in progress. It should not be relied upon for “guaranteed” anonymity at this time, due to the relatively small size of the network and the lack of extensive academic review. It is not immune to to attacks from those with unlimited resources, and may never be, due to the inherent limitations of low-latency mix networks.

I2P works by routing traffic through other peers, as shown in the following picture. All traffic is encrypted end-to-end. For more information about how I2P works, see theIntroduction.

O diagrama de como o protocolo funciona é baseado no conceito do TOR mas levaram a ideia um passo mais a frente:

 

endToEndEncryption

endToEndEncryption

Legenda:

In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their local router. They each have a pair of 2-hop inbound tunnels per destination (labeled 1,2,3,4,5 and 6), and a small subset of each of those router’s outbound tunnel pool is shown with 2-hop outbound tunnels. For simplicity, Charlie’s inbound tunnels and Dave’s outbound tunnels are not shown, nor are the rest of each router’s outbound tunnel pool (typically stocked with 5-10 tunnels at a time). When Alice and Bob talk to each other, Alice sends a message out one of her (pink) outbound tunnels targetting one of Bob’s (green) inbound tunnels (tunnel 3 or 4). She knows to send to those tunnels on the correct router by querying the network database, which is constantly updated as new leases are authorized and old ones expire.

If Bob wants to reply to Alice, he simply goes through the same process – send a message out one of his outbound tunnels targetting one of Alice’s inbound tunnels (tunnel 1 or 2). To make things easier, most messages sent between Alice and Bob are garlic wrapped, bundling the sender’s own current lease information so that the recipient can reply immediately without having to look in the network database for the current data.

To deal with a wide range of attacks, I2P is fully distributed with no centralized resources – and hence there are no directory servers keeping statistics regarding the performance and reliability of routers within the network. As such, each router must keep and maintain profiles of various routers and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability needs of the users, as described in the peer selection page.

The network itself makes use of a significant number of cryptographic techniques and altorithms – a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, 1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to station authentication, and ElGamal / AES+SessionTag.

Content sent over I2P is encrypted through three or four layers – end to end encryption (absolutely no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport uses AES256 with ephemeral keys):

End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; end-to-end (garlic) encryption (I2P client router to I2P server router) from Alice’s router “a” to Bob’s router “h” remains. Notice the different use of terms! All data from a to h is end-to-end encrypted, but the I2CP connection between the I2P router and the applications is not end-to-end encrypted! A and h are the routers of alice and bob, while alice and bob in following chart are the applications running atop of I2P.

Contudo do que nos serve toda esta tecnologia se a não podemos integrar com a nossa rede atual?

A ideia será que todos os pedidos de i2p saiam automaticamente pela rede i2p, e por exemplo tudo o que seja para o facebook saia pela rede TOR sem recurso a alterar configurações de browsers e proxies.

Convém como é óbvio terem ambos os serviços já implementados.
No meu caso especifico, ambos estão na mesma VPS (tor & i2p), mas foi necessário criar um ip alias (segundo IP) pois o squid que tenho como transparent proxy necessita de ips diferentes para parent caches diferentes.

A configuração seguinte é para colocar no squid.conf, e após a mesma não se esqueçam de fazer reload ao daemon para assumir as novas configurações.

cache_peer 10.0.0.1 parent 4444 7 no-query no-digest no-netdb-exchange
cache_peer 10.0.0.2 parent 8118 7 no-query no-digest no-netdb-exchange
cache_peer_domain
10.0.0.1 .i2p .to i2p.net
cache_peer_domain
10.0.0.2 .4chan.org
neighbor_type_domain
10.0.0.1 parent .i2p last.fm .to .i2p.net
neighbor_type_domain
10.0.0.2 parent .4chan.org

acl i2p-servers dstdomain .i2p .apple.com
acl tor-servers dstdomain .4chan.org

never_direct allow i2p-servers
never_direct allow tor-servers

A legenda é:

cache_peer 10.0.0.1 parent 4444 7 no-query no-digest no-netdb-exchange
cache_peer 10.0.0.2 parent 8118 7 no-query no-digest no-netdb-exchange

Estas linhas indicam os IP’s peers-parent que contem os acessos do router por software I2P e o TOR.
O 10.0.0.1 contem o i2p e o 10.0.0.2 contem o tor.
Ambos foram configurados para permitir acesso externo aos motores de proxy.Pf verifiquem junto da documentação de ambos os softwares como permitir isto.

cache_peer_domain 10.0.0.1  .i2p last.fm .to .i2p.net .apple.com
cache_peer_domain 10.0.0.2  .4chan.org
neighbor_type_domain 10.0.0.1  parent .i2p last.fm .to .i2p.net
..apple.com
neighbor_type_domain 10.0.0.2  parent .4chan.org

Estas linhas indicam o que mandar para que proxy.
Se repararem, estou a enviar os dominios .i2p, .i2p.net, e last.fm através do cache_peer 10.0.0.1.
Estou ainda a enviar os acessos do .4chan.org através do tor cujo proxy está no ip 10.0.0.2

acl i2p-servers dstdomain .i2p
acl tor-servers dstdomain .4chan.org

never_direct allow i2p-servers
never_direct allow tor-servers

Finalmente estas linhas indicam os acls das redes.
As acls estão defindidas da seguinte forma: acl i2p-servers, tor-servers, e é definido aqui o dominio parent .i2p last.fm .to .i2p.net e microsoft.com
Os acessos da ACL tor-servers indicam acessos para dominios com .4chan.org.

Finalmente, o que cai nas acl’s  é obrigado a nunca ir directamente aos acessos e sair pelo proxy com a directiva never_direct.

É fácil compreender através destas linhas como adicionar novos domínios para forcar saídas pelos proxy’s de privacidade diversos.

No entanto nem tudo é dourado com esta tecnologia.

Como é um sistema de direct peering, irá ser necessário manterem uma maquina sempre em execução com o i2p router.

Se toda a rede for abaixo, todos os pares próximos terão de ser rê-descobertos. E uma redescoberta que garanta utilidade no sistema demora umas horas a dar frutos.

Outro issue é a forma não controlada que certos conteudos utilizam para se mostrem (por exemplo flash’s e javas).

Nestes casos, é necessário garantir que o dispositivo que está a se ligar via i2p/tor não tem acesso direto á net (regra de deny na firewall de perimetro ou não routeamento da gama onde o dispositivo se encontra.
Desta forma, mesmo que um java ou flash entre em execução não conseguirá comunicar com o destino sem sair pela rede privada que é o que procuramos aqui.

Como notas finais, recomendo que experimentem esta tecnologia.
Em termos de lifecycle este software é extremamente ativo, com support & bug releases muito activos pelo que bugs ou falhas de segurança descobertos levam a correções muito rapidas.
Pode não ser o futuro, mas será certamente nesta direção que o estado da arte irá progredir.

Caso tenham duvidas ou sugestões sabem onde me encontrar.

Abraço,
Nuno