Bom dia a todos,

Neste dia da liberdade decidi recuperar e melhorar um post de 2015 onde sublinho o nosso direito a anonimidade na internet. Ao direito a não sermos considerados como criminosos pelos nossos governos só porque decididos ter direito a nossa privacidade.

Embora muitos gostariam de vos fazer acreditar que numa era onde quem não tem facebook, twitter, instagram e afins não é ninguém, existem ainda pessoas que gostam de ter alguma privacidade e anonimato.

Por privacidade não quero afirmar que quem procura privacidade é obrigatoriamente um elemento da sociedade a tentar fazer algo nefasto para a mesma. O proverbial homem de gabardina que vende relógios contrafeitos na feira da luz, ou o doente a procura de presas.

Pode simplesmente ser zeloso, paranoico ou ver demasiados filmes do 007. Pode simplesmente querer privacidade.

Descobri então o projeto I2P feito por uma comunidade extremamente ativa com as mesmas preocupações.

É 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.
Assim sendo é possível desenvolverem os vossos próprios plugins para as vossas aplicações, com resultados muito interessantes em termos de segurança e anonimato.

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:

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.

Caso não o tenham existem how-tos simples e extremamente bem constuidos aqui e aqui.

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.

Em seguida, é necessário configurar uma forma automática de rederecionar os dominios .i2p, ou .onion para o sitio certo.
A configuração acima só irá funcionar se explicitamente enviaremo trafego através do proxy. E se houverem mais máquinas em rede que queiram aceder a deepweb sem reconfigurações ao nivel do browser?
Nada mais facil. Para iniciar necessitamos de construir dois dummy domains: .i2p e .onion no nosso DNS local:

 # cat /var/lib/named/var/named/i2p.hosts
$ttl  8600
i2p.        IN      SOA     DNS. dnsmaster.voodoo.i2p. (
                        2010051405
                        10800
                        3600
                        432000
                        38400 )
                        IN      NS         ns1
                        IN      NS         ns2

ns1                             IN      A       172.16.0.149
ns2                             IN      A       172.16.0.254

*                               IN      A       172.16.69.69

# cat /var/lib/named/var/named/onion.hosts
$ttl  8600
onion.        IN      SOA     DNS. dnsmaster.voodoo.onion. (
                        2010051404
                        10800
                        3600
                        432000
                        38400 )
                        IN      NS         ns1
                        IN      NS         ns2

ns1                             IN      A       172.16.0.149
ns2                             IN      A       172.16.0.254

*                               IN      A       172.16.69.69

Com estas zonas, todas as querys efetuadas de FQDN’s a domínios .i2p e .onion serão reencaminhadas para o IP (não utilizado na nossa rede) de 172.16.69.69.

Finalmente na firewall de perímetro iremos encaminhar todo o tráfego para o 172.16.69.69 para o squid que está a fazer a ligação com o I2P e o TOR:

Ou seja, tudo o que vier da minha rede “LAN” com o destino 172.16.69.69 é reencaminhado para o proxy que está a correr na porta 3129 da firewall (onde entram as regras de squid já acima mostradas).

Nota: Para os que estão curiosos, os screenshots são já da pfSense 2.3.0. Nesta versão da pfsense / squid, o squid tem que ser colocado em intercept mode, tendo em conta que no squid 3.5, o transparent mode foi substituido pelo intercept mode.

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 isto.

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