tecnologia Tor e Hidden Service Protocol - Explicando tecnicamente a "Deep Web"

[☢|EXPL01T3R|☣ 50]

[h=1]Introdução[/h]

Primeiramente, gostaria de deixar claro que Deep Web no título está entre aspas, porque a considero como um conceito, e não algo totalmente tangível, como ela é divulgada por aí.

 

Mas fato é, que grande parte de blogs, portais e sites que falam sobre essa tal de "Deep Web", referem-se, na verdade, aos Hidden Services. Podemos identificar isso quando vemos que os endereços para os sites da "Deep Web" terminam com o subdomínio ".onion".

 

O Hidden Service Protocol é um protocolo criado pelo projeto Tor, e funciona com base na Tor Network.

 

O objetivo do Hidden Service Protocol é bem claro: Dar a possibilidade de uma pessoa disponibilizar um serviço dentro da rede Tor, sem que o IP do servidor que mantém esse serviço (ou seja, IP do servidor) esteja exposto para quem o acessa.

 

Nos próximos capítulos vou tentar explicar o funcionamento do cliente Tor e como funciona o Hidden Service Protocol. Não coloquei detalhes muito técnicos porque ainda estou me aprofundando no assunto e não quero explicar alguma coisa de maneira muito bagunçada. Mas deixo no final alguns links interessantes para quem quiser mais detalhes.

 

Deixo claro desde já, que este artigo é completamente teórico, porém, caso a comunidade ache o tema interessante, pretendo escrever outro artigo com uma abordagem mais prática. Ou seja, mostrando a configuração de um cliente Tor e de um Hidden Service.

 

Apesar da configuração deles ser algo bem simples, tem muitos detalhes que podem facilitar a vida de quem está usando estes serviços. :)

[h=1]Cliente Tor - Funcionamento básico[/h]

O cliente Tor tem o objetivo de garantir seu anonimato na Internet. Este software trabalha redirecionando seu tráfego de Internet através da rede Tor, antes que ele chegue ao seu destino final.

 

A rede Tor é um conjunto de servidores que funcionam retransmitindo seu tráfego de Internet. Estes servidores são chamados de relay's. Atualmente, existem cerca de 3.000 relay's disponibilizados por voluntários em todas as partes do mundo.

 

O primeiro passo do cliente Tor quando ele é iniciado, é buscar em um Directory Server uma lista de endereços de todos os relay's Tor disponíveis.

 

Tendo posse desta lista, ele escolhe 3 relay's randomicamente. Estes relay's serão usados para a criação de um túnel virtual que vai ligar o cliente Tor até o seu destino. Ou seja, quando o cliente Tor mandar uma mensagem qualquer, esta mensagem não será encaminhada direto pro seu destino.

 

Ela será enviada primeiramente para o PRIMEIRO_RELAY_TOR (relay de entrada), que vai entregar a mensagem para o SEGUNDO_RELAY_TOR, e que por sua vez vai entregar a mensagem para o TERCEIRO_RELAY_TOR (relay de saída). E então, é o TERCEIRO_RELAY_TOR que entregará a mensagem para o destino final.

 

Depois de definido quais serão os três relay's que formarão o circuito, o cliente Tor vai até eles e negocia com cada um deles, separadamente, uma chave pública diferente para a encriptação dos dados.

 

Tendo certeza que o relay só vai conseguir descriptografar e ver a mensagem que foi criptografada com a sua própria chave pública, nós garantimos que nenhum dos relay's vai conseguir ver o caminho todo percorrido pela mensagem.

 

Exemplo: Supondo que você vai enviar uma mensagem para um destino qualquer usando o Tor, sendo que o circuito (o túnel virtual passando pelos três relay's) já está definido e o Tor já tem as chaves públicas desses três relay's:

• O primeiro passo do Tor é pegar o pacote original e criptografá-lo usando a chave pública do TERCEIRO_RELAY_TOR. Note que, no corpo do pacote, existe a informação que está sendo trafegada (vamos supor que seja um HTTP request) e no Header, entre outras informações, tem o destino original dessa mensagem (que pode ser um site qualquer). Ou seja, a mensagem que contém o destino original vai estar criptografada quando sai de sua máquina e enquanto passa pelos relay 1 e 2. Apenas o terceiro relay vai conseguir descriptografar a mensagem para saber o destino!
  
• Após a primeira encriptação, o Tor pega essa mensagem criptografada e cria um pacote tendo ela como conteúdo, adiciona o endereço do TERCEIRO_RELAY_TOR no Header e criptografa novamente, agora usando a chave pública SEGUNDO_RELAY_TOR. Isto garante que o endereço do relay de saída (ou seja, o terceiro relay) estará criptografado quando sair de sua máquina, e quando passar pelo primeiro relay. O único que precisa saber o endereço do TERCEIRO_RELAY_TOR é o SEGUNDO_RELAY_TOR, que vai ficar responsável por encaminhar a mensagem para ele.
  
• Essa mensagem que já foi criptografada duas vezes, agora vai ser criptografada novamente junto com o endereço do SEGUNDO_RELAY_TOR no header, só que agora, com a chave pública do PRIMEIRO_RELAY_TOR. Isso dá uma segurança a mais, caso a comunicação entre seu cliente Tor e o primeiro relay seja interceptada.
  

 

Para facilitar o entendimento do esquema de criptografia em camadas, vamos tomar uma perspectiva mais prática:

1. Quando a mensagem chegar no primeiro relay e ele a descriptografar, esse relay vai encontrar duas informações: um pacote de dados criptografados e o endereço do segundo relay do circuito. Ele a envia.
   
2. Quando o primeiro relay entregar a mensagem para o segundo relay e ele descriptografar, o conteúdo que ele vai ter acesso vai ser: um pacote de dados criptografado e o endereço desse terceiro relay. E então, ele entrega a mensagem ao terceiro relay.
   
3. O terceiro relay vai descriptografar e vai encontrar a mensagem original (o HTTP request) e o endereço do destino final, e faz o HTTP request.
   

 

Obs.: No Header dos pacotes TCP, existe o campo "source address". Logicamente, neste campo, vai ter o endereço do TERCEIRO_RELAY_TOR, e não do cliente.

 

[h=1]Para entender melhor[/h]A representação abaixo esquematiza como o redirecionamento de tráfego funciona quando o cliente_TOR tenta conectar-se a um destino qualquer:

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

Note que:

• O TOR_relay_1 "sabe" apenas o endereço do cliente_TOR e o endereço do TOR_relay_2;
  
• O TOR_relay_2 "sabe" apenas o endereço do TOR_relay_1 e do TOR_relay_3;
  
• O TOR_relay_3 "sabe" apenas o endereço do TOR_relay_2 e do Destino;
  
• O IP que chega ao Destino, é o do TOR_relay_3.
  

 

Como notamos acima, o cliente não envia os pacotes diretamente para o destino, assim como o site também não recebe pacotes vindos diretamente do cliente. Isso garante a privacidade de dois modos:

1. Não é possível descobrir para ONDE o cliente está enviando pacotes. E graças a esse aspecto, muitas pessoas que vivem em países que promovem a CENSURA podem acessar a Internet livremente;
   
2. O site não sabe por QUEM ele está sendo acessado, algo muito interessante para quem não quer ser identificado quando está usando a Internet.
   

 

Pode ser usado também por quem acredita estar sendo monitorado por algum tipo de sniffer de rede. Como o tráfego até o TOR_relay_3 vai ser criptografado, alguém que esteja "sniffando" sua rede local não vai conseguir nenhuma informação dos dados que estão sendo trafegados e nem para ONDE eles estão sendo enviados.

 

[h=1]Hidden Service Protocol[/h]

O cliente TOR nos permite acessar serviços mantendo nosso IP oculto, porém, graças a uma implementação do Hidden Service Protocol na rede Tor, nós podemos também oferecer serviços dentro da rede Tor mantendo nosso IP oculto.

 

O Hidden Service Protocol permite a disponibilização de serviços, como publicação de páginas, serviços de mensagens, e-mails, SSH, entre outros tipos de serviços dentro da rede Tor, sem que nosso IP seja exposto em momento algum.

 

Ou seja, com este protocolo você pode, por exemplo, montar um servidor para publicar um site, e o IP desse servidor permanecerá oculto dentro da rede TOR. Ninguém que acessa o site, vai conhecer o IP de seu servidor. :)

 

Para entendermos corretamente o modo de funcionamento do Hidden Service Protocol, vamos primeiro definir alguns personagens importantes nesse "joguinho":

• Cliente_TOR → É o cliente TOR do usuário que está tentando se conectar ao hidden service;
  
• Hidden Service → É o serviço oculto, ou seja, aquele serviço que vai estar disponível na rede TOR mantendo oculto o IP de quem está o provendo;
  
• Circuito TOR → Relembrando o que foi passado no outro capitulo, circuito Tor se constitui como a passagem do tráfego saindo do cliente_TOR e pelos 3 relays antes de chegar no destino.
  
• Ponto de introdução → É um relay aleatório que mantém um circuito aberto com quem está provendo o hidden service. Esse relay é escolhido pelo hidden service no momento que ele é iniciado.
  
• Chave pública do serviço → Todo hidden service tem uma chave pública. Importante notar, que a URL do serviço oculto, é formada pelo hash da chave pública+subdominio .onion.
   
  Exemplo:
  É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
   
  A chave pública e o hash são gerados automaticamente na primeira vez que o hidden service é iniciado.
  
• BD distribuído de hashs → Conjunto de relays que guardam informações sobre todos o hidden services disponíveis na rede. As informações que ele guarda são: Qual a chave pública do serviço e quais são seus pontos de introdução. O serviço após gerar a chave pública e escolher seus pontos de introdução, passa essas informações automaticamente para esse BD.
  
• Ponto de encontro → É um relay escolhido randomicamente pelo cliente TOR. Este relay será o ponto onde tanto o hidden service quanto o cliente TOR, vão se conectar simultaneamente para a troca de informações.
  

 

* Leia com bastante atenção, porque realmente não é uma coisa muito fácil de se entender.

 

Agora, da perspectiva prática:

1. Eu já estou com o TOR instalado e digito no Tor Web Browser, o endereço:
   É necessário se cadastrar para acessar o conteúdo.

   • Entre
   • ou
   • Cadastre-se
   ;
   
2. Cliente TOR já nota pelo "subdominio .onion" que eu quero me conectar a um hidden service, e envia o hash da chave pública que está no URL para o banco de dados de hashs;
   
3. O banco de dados de hashs procura procura pela hash que enviei, caso encontre, manda como resposta para o meu cliente uma lista de todos os pontos de introdução desse hidden service e sua chave pública completa;
   
4. O cliente TOR escolhe randomicamente na rede um relay para servir como ponto de encontro e cria um circuito até ele, após isso, o cliente envia para o ponto de encontro um código chamado de "one-time secret";
   
5. O cliente TOR, envia para o ponto de introdução do hidden service uma mensagem com o endereço do ponto de encontro, juntamente com o "one-time secret". Essa mensagem é criptografada usando a chave pública do hidden service;
   
6. O ponto de introdução, usando o circuito que já estava estabelecido, passa para o hidden service a mensagem criptografada que recebeu do cliente TOR. O hidden service, com sua chave privada, descriptografa a mensagem e descobre o endereço do ponto de encontro e o "one-time secret";
   
7. O hidden service, que já está com o endereço do ponto de encontro, abre até ele um circuito. E passa para esse ponto de encontro o one-time secret;
   
8. O ponto de encontro compara o one-time secret enviado pelo cliente TOR e pelo hidden service. Caso os dois sejam idênticos, ele notifica o cliente TOR e o hidden service que a conexão foi feita com sucesso;
   
9. O cliente TOR e o hidden service já podem se comunicar. O ponto de encontro apenas repassa as mensagem recebidas pelo hidden service para o cliente TOR e vice-versa. Neste ponto, a conexão é completamente criptografada.
   

[h=1]É seguro?[/h]

Todos nós sabemos que não existe algo 100% seguro.

 

Sobre o uso do cliente Tor, podemos dizer que ele se torna relativamente inseguro se partirmos do principio que é POSSÍVEL que o relay de saída tenha atitudes maliciosas, como por exemplo, armazenar todo o tráfego que passa por ele.

 

Em casos de conexões onde existe criptografia nativa, como HTTPS, SSH e etc, o risco diminui já que o relay não vai ter acesso ao conteúdo original.

 

Porém, em serviços como o FTP e outros que não tem criptografia nativa, é possível que o relay malicioso pegue seu usuário e senha e tente te identificar usando essas informações. Mesmo que não exista um login no conteúdo acessado, só de saber o que você está acessando, ele já poderia tentar algumas técnicas pra te identificar.

 

Caso alguém tenha mais interesse (em inglês):

É necessário se cadastrar para acessar o conteúdo.

• Entre
• ou
• Cadastre-se

 

Outro perigo, são sites que implementam HTTPS apenas na hora do login. Neste caso, mesmo que o relay malicioso não tenha acesso à sua senha, ele vai ter acesso aos teus cookies e às informações que você está vendo.

 

Partindo destes fatos, notamos que o uso do Tor é BEM mais recomendável para uso com conexões onde existe criptografia nativa, e logo, não é recomendável para acesso à informações sensíveis onde não existe o uso de criptografia.

 

Sobre os hidden services, também existe o perigo de haver relays maliciosos no caminho. E já foram descritas técnicas que, com o uso de relay maliciosos, um hidden service poderia ser identificado (em inglês):

• É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
  

 

Pra tentar resolver (ou, pelo menos diminuir MUITO) a possibilidade de um hidden service ser identificado usando a técnica acima, os desenvolvedores do Tor Project implantaram uma solução chamada "Entry Guards". Não pretendo entrar em detalhes sobre como ela funciona, mas se tiver interesse, dê olhada no FAQ no Tor Project:

• É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
  

 

Bom, de fato, existe muita coisa "perigosa" rodando na rede Tor. Acredito que se existe alguma maneira efetiva de identificar tanto os clientes Tor como os hidden services, esta técnica, com certeza, vale ouro!

 

[h=1]Referências[/h]Todas as informações postadas aqui, foram retiradas do site oficial do projeto Tor.

 

Sobre o funcionamento do Tor:

• É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
  

 

Sobre o funcionamento dos hidden services:

• É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
  

 

Especificações do Hidden Service Protocol para desenvolvedores:

• É necessário se cadastrar para acessar o conteúdo.

  • Entre
  • ou
  • Cadastre-se
  
  

 

Então, espero que todos tenham entendido corretamente o funcionamento de Tor e do Hidden Service Protocol. Talvez seja necessário ler mais de uma vez. Eu mesmo, quando comecei a estudar isso, tive que reler a documentação oficial algumas vezes até entender.

 

No futuro pretendo abordar mais alguns temas, além de explicar a parte prática do funcionamento do Tor e dos hidden services.

Creditos: Marcelo Theodoro - VOL

 

 

 

[crazy_uchiha 1]

Muito bom o tópico levo meu thanks tinha ouvido falar de Hidden Service Protocol mas eu prefiro usar proxys aletórios mesmo estando no TorNetwork xAbraços[h=2][/h]

[galado25 0]

Nem todos os sites da deep web terminam com .onion, na verdade nem 3% dela é .onion

sites referentes a .onion são os mais "confiáveis" de serem abertos/explorados.

apenas de saber configurar seu rotiador de maneira apropriada e sem furos você consegue configurá-lo para se usado em redes proxy ou até criar uma "rede individual".

torproject é uma brincadeira de criança, mas é plausível.

acham que muitos hackers que surfam pela DeepWeb não sabem disso? você só está relativamente seguro dependendo do seu propósito.