Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
CENTRO DE INSTRUÇÃO DE GUERRA ELETRÔNICA
1º Ten Com VICTOR TORRES KUMM
EFICÁCIA DA UTILIZAÇÃO DA REDE TOR PARA O ANONIMATO E A
CONFIDENCIALIDADE DAS COMUNICAÇÕES NA INTERNET
Brasília
2016
1º Ten Com VICTOR TORRES KUMM
EFICÁCIA DA UTILIZAÇÃO DA REDE TOR PARA O ANONIMATO E A
CONFIDENCIALIDADE DAS COMUNICAÇÕES NA INTERNET
Trabalho de Conclusão de Curso
apresentado ao Centro de Instrução de
Guerra Eletrônica como requisito para a
obtenção do grau de especialista em
Guerra Cibernética.
Orientador: Cap Com FELIPE RODRIGUES DE VASCONCELLOS
Brasília
2016
1º Ten Com VICTOR TORRES KUMM
EFICÁCIA DA UTILIZAÇÃO DA REDE TOR PARA O ANONIMATO E A
CONFIDENCIALIDADE DAS COMUNICAÇÕES NA INTERNET
Trabalho de Conclusão de Curso
apresentado ao Centro de Instrução de
Guerra Eletrônica como requisito para a
obtenção do grau de especialista em
Guerra Cibernética.
Aprovado em: _______ /___________________/ ________
COMISSÃO DE AVALIAÇÃO
_________________________________________________
ANDERSON LELLIS ALVES MOURA – Maj Com Presidente
CENTRO DE INSTRUÇÃO DE GUERRA ELETRÔNICA
_____________________________________________________
FELIPE RODRIGUES DE VASCONCELLOS – Cap Com Membro
CENTRO DE INSTRUÇÃO DE GUERRA ELETRÔNICA
_________________________________________________
VINICIUS LUIS PALUDETO – 1º Ten Com Membro
CENTRO DE INSTRUÇÃO DE GUERRA ELETRÔNICA
AGRADECIMENTOS
Ao grande criador deste universo, Deus, pois “Posso enfrentar qualquer coisa
com a força que Cristo me dá.” (Filipenses 7, 13).
A minha família pelo exemplo de amor, carinho e união.
Ao meu orientador, Cap Com Felipe Rodrigues De Vasconcellos, pela
orientação, compreensão e esforço dedicado.
Ao 1º Ten Com Scherer pela ajuda, dedicação, disponibilidade, paciência e
interesse como amigo e profissional nesse período de aperfeiçoamento.
Ao 1º Ten Com Gadioli pelos ensinamentos compartilhados, fundamentais para
o prosseguimento deste trabalho e do curso de forma geral.
Ao companheiro da ABIN João Pincovski pelo interesse em ajudar o próximo e
pelo exemplo de profissionalismo dado.
Ao Maj Aviador Wagner pelos ensinamentos sobre anonimato compartilhado,
bem como pronta resposta aos questionamentos levantados.
Ao Fábio, da Bóson Treinamentos, por todos os ensinamentos compartilhados.
A todos que de alguma forma ajudaram para a realização deste estudo.
RESUMO
Resumo: No presente estudo, analisou-se a eficácia da utilização da rede TOR para
o anonimato e a confidencialidade das comunicações na internet, detalhando o seu
funcionamento. Foi apresentado os conceitos de ataques man-in-the-middle (MITM) e
de Bitcoin. Realizou-se a criação de um nó de saída na rede TOR. Realizou-se testes
de captura de tráfego no nó de saída configurado por meio do programa tcpdump. Por
fim, concluiu-se quanto a validade da criação de um nó de saída institucional na rede
TOR a fim de evitar ataques MITM.
PALAVRAS-CHAVE: rede TOR, nó de saída, ataque MITM.
ABSTRAC
Abstract: This study examined the effectiveness of using the TOR network for
anonymity and the confidentiality of internet communications detailing its operation. It
was presented the concepts of Man-in-the-middle attacks (MITM) and Bitcoin. There
was the creation of a real Exit node on the TOR network. It was conducted traffic
analysis tests on the Exit node through the tcpdump program. Finally, it was concluded
about the validity of creating an institutional TOR output node in the network to avoid
MITM attacks.
KEY WORDS: TOR Network, Exit Node, MITM attack.
LISTA DE TABELAS
Tabela 1: Estrutura de uma célula ................................................................................................... 30
Tabela 2: Estrutura de células Relay .............................................................................................. 31
Tabela 3: Estatísticas da rede TOR ................................................................................................ 50
LISTA DE FIGURAS
Figura 1: Protocolo SOCKS no modelo OSI .............................................................. 18 Figura 2: Ilustração do funcionamento da rede TOR ................................................. 20 Figura 3: Localização dos Servidores Autoritativos ................................................... 23 Figura 4: Obtenção de endereços Bridges ................................................................ 25 Figura 5: Exemplo de circuito na rede TOR .............................................................. 27 Figura 6: Exemplo de Política de Saída .................................................................... 27 Figura 7: Comparação de conexões TLSv1.2 ........................................................... 29 Figura 8: Comparação de suítes criptográficas ......................................................... 32 Figura 9: Sequência para cálculo de chave simétrica na rede TOR .......................... 33 Figura 10: Sequência para extensão de circuitos na rede TOR ................................ 34 Figura 11: Extensão de circuito na rede TOR ........................................................... 35 Figura 12: Uso da camada de aplicação na rede TOR ............................................. 36 Figura 13: Fluxo de dados da camada de aplicação ................................................. 36 Figura 14: Fluxo de dados na rede TOR ................................................................... 37 Figura 15: Hidden Service 1 ...................................................................................... 39 Figura 16: Hidden Service 2 ...................................................................................... 39 Figura 17: Hidden Service 3 ...................................................................................... 40 Figura 18: Hidden Service 4 ...................................................................................... 40 Figura 19: Hidden Service 5 ...................................................................................... 41 Figura 20: Configuração do TOR Browser ................................................................ 44 Figura 21: Sistema Operacional Tails ....................................................................... 45 Figura 22: Utilização do Whonix gateway ................................................................. 46 Figura 23: Qubes ....................................................................................................... 47 Figura 24: Orbot e Orfox ........................................................................................... 48
Figura 25: Utilização do ProxyChains ....................................................................... 51 Figura 26: Ataque MITM ............................................................................................ 52 Figura 27: Electrum ................................................................................................... 53 Figura 28: Bitmixer .................................................................................................... 54 Figura 29: Teste "http://www.pudim.com.br" ............................................................. 55 Figura 30: Teste "http://www.webs.com/s/login/relogin" ............................................ 56
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 10
1.1 Antecedentes do Problema .......................................................................... 10
1.2 Problema ........................................................................................................ 13
1.3 Hipóteses ....................................................................................................... 13
1.4 Objetivos ........................................................................................................ 13 1.4.1 Objetivo geral .......................................................................................... 13 1.4.2 Objetivos específicos ............................................................................. 13
1.5 Justificativa e Relevância para as Ciências militares ................................ 14
1.6 Estado da Arte ............................................................................................... 14
1.7 Procedimentos Metodológicos .................................................................... 15 1.7.1 Delineamento da pesquisa ..................................................................... 15 1.7.2 Procedimentos para a revisão da literatura .......................................... 15 1.7.3 Sequência das ações .............................................................................. 16
2 REDE TOR ......................................................................................................... 18
2.1 Protocolo SOCKS .......................................................................................... 18
2.2 Funcionamento geral do TOR ...................................................................... 19
2.3 Detalhamento ................................................................................................. 22 2.3.1 Diretórios Servidores.............................................................................. 22 2.3.2 Servidores Autoritativos ........................................................................ 23 2.3.3 Consensus ............................................................................................... 24 2.3.4 Bridges ..................................................................................................... 25 2.3.5 Escolha Do Circuito ................................................................................ 26 2.3.6 Construção do Circuito .......................................................................... 28 2.3.7 Camada de Aplicação ............................................................................. 36 2.3.8 Hidden Service ........................................................................................ 38 2.3.9 Arquivo torrc ........................................................................................... 42
2.4 Formas de acessar o TOR ............................................................................ 43 2.4.1 Tor Browser ............................................................................................. 43 2.4.2 Tails .......................................................................................................... 45 2.4.3 Whonix ..................................................................................................... 46 2.4.4 Qubes ....................................................................................................... 47 2.4.5 Orbot e Orfox ........................................................................................... 47
2.5 Ataques Conhecidos ..................................................................................... 48
2.6 Servidor Privado Virtual ................................................................................ 49
2.7 Estatísticas..................................................................................................... 50
2.8 Proxychains ................................................................................................... 50
3 ATAQUE MITM .................................................................................................. 52
4 BITCOIN ............................................................................................................. 53
5 APRESENTAÇÃO E DISCUSSÃO DOS RESULTADOS .................................. 55
6 CONCLUSÕES E RECOMENDAÇÕES ............................................................. 57
REFERÊNCIAS ......................................................................................................... 58
10
1 INTRODUÇÃO
Atualmente, o tema anonimato na internet vêm se destacando em meio a um
cenário global caracterizado pela mutabilidade acelerada, pela guerra irregular e pela
facilidade de acesso a informação, onde os conflitos no meio cibernético são travados
entre estados, empresas e pessoas, em busca de poder, estereotipado pelo simples
saber, pela simples informação.
Nesse ponto, esse trabalho surge como oportunidade de desenvolver uma
capacidade militar que permita uma comunicação segura e anônima na rede mundial
de computadores, internet.
Foi delineado o foco na pesquisa bibliográfica e documental, além de
experimentos realizados em um nó de saída da rede TOR. Assim, foi levantado o
objetivo geral de provar se a criação e a utilização de um nó de saída próprio na rede
TOR evita ataques do tipo MITM, a fim de garantir o anonimato das comunicações
pretendido pelo TOR Project na Internet.
O trabalho está divido seis partes, a saber: Introdução; rede TOR; ataque man-
in-the-middle; Bitcoin; apresentação e discussão dos resultados; e conclusão.
Na introdução há os antecedentes do problema, o problema levantado, as hipóteses
sugeridas, os objetivos da pesquisa, a justifica e a relevância para as ciências
militares, o estado da arte e os procedimentos metodológicos.
No capítulo sobre a rede TOR, incialmente é apresentada uma visão geral
seguindo de um detalhamento sobre o funcionamento da rede. A seguir, o ataque
MITM é abordado, bem como o conceito da criptomoeda Bitcoin.
Em seguir, os dados coletados na prática realizada são analisados e
apresentados. Por fim, são realizadas as considerações finais na conclusão, onde se
dá o desfecho da pesquisa e é confirmada a primeira hipótese sugerida acerca da
eficácia da criação do nó de saída institucional a fim de evitar ataques MITM.
1.1 Antecedentes do Problema
Segundo a Doutrina Militar de Defesa Cibernética (2014, p.13),
“O Brasil, como nação soberana, necessita possuir capacidade para se contrapor às
11
ameaças externas, de modo compatível com sua própria dimensão e suas aspirações
político-estratégicas no cenário internacional”.
Ressalta ainda que:
1.2.2 Na atual conjuntura mundial, caracterizada por incerteza, mutabilidade e volatilidade das ameaças potenciais, bem como pela presença de novos atores não estatais nos possíveis cenários de conflito, a sociedade brasileira, em particular a expressão militar do Poder Nacional, deverá estar permanentemente preparada, considerando os atuais e futuros contenciosos internacionais. Para tal, medidas deverão ser adotadas de forma a capacitá-la a responder oportuna e adequadamente, antecipando os possíveis cenários adversos à Defesa Nacional. (DOUTRINA MILITAR DE DEFESA CIBERNÉTICA, 2014, p. 13)
Além disso, “dentro desse cenário, a Defesa Cibernética vem se estabelecendo
como atividade fundamental ao êxito das operações militares em todos os escalões
de comando, na medida em que viabiliza o exercício do Comando e Controle (C²), por
meio da proteção dos ativos de informação, ao mesmo tempo permitindo que esse
exercício seja negado ao oponente”. (DOUTRINA MILITAR DE DEFESA
CIBERNÉTICA, 2014, p 13).
Assim, foram estabelecidos os Objetivos e as Diretrizes da Política Cibernética
de Defesa (2012, p.15), dentre os quais destaca-se o de “estabelecer
programas/projetos a fim de assegura a capacidade de atuar em rede com segurança,
fortalecendo, dessa forma, a operacionalidade da atividade de Comando e Controle
no Ministério da Defesa.”
Nesse escopo, a oportunidade de produzir conhecimento resultante em
capacidade militar orientou este trabalho de conclusão de curso com foco na pesquisa
e em testes na rede denominada “The Onion Router” (TOR).
Em 1995, o matemático Paul Syverson e os cientistas da computação Michael
G. Reed e David Goldschiag, foram financiados pelo “United States Naval Research
Laboratory” (ONR) para desenvolver o “Onion Routing”, a fim de proteger as
comunicações online da Inteligência Norte Americana. Posteriormente, o “Defense
Advanced Research Project Agency” (DARPA) somou esforços financeiros ao projeto
a partir de 1997. (SYVERSON, 2016).
Apesar dos resultados promissores, o financiamento oficial é encerrado em
1999. Porém, em 2000, Syverson e Roger Dingledine, se conhecem no seminário
“Design Issues in Anonymity and Unobservability”, em Berkeley, Califórnia, Estados
Unidos da América (EUA). Em 2002, Nick Mathensow se junta a dupla e a primeira
geração do projeto é abandonada. No mesmo ano, começam os trabalhos na segunda
12
geração e uma versão alpha é lançada em 20 de setembro, sendo batizada de “The
Onion Routing Project” (TOR Project). (WIKIPÉDIA, WIKIPÉDIA, 2016).
A partir de 2003, surgem novos financiamentos da ONR e do DARPA,
ocorrendo a abertura da rede TOR baseada na política de software livre do
“Massachusetts Institute of Technology” (MIT) em outubro do mesmo ano. Em 2004,
na “13th USENIX Security Symposium”, Berkeley, Califórnia, EUA, é apresentado o
modelo “Tor: The Second-Generation Onion Router” e o projeto também passa a ser
financiados pela “Eletronic Frontier Foundation” (EFF). (WIKIPÉDIA, WIKIPÉDIA,
2016).
Em 2006 é lançado “The Tor Project” com financiamento do EFF, “U.S.
International Broadcasting Bureau”, “Internews, Human Rights Watch”, “The University
of Cambridge”, Google e “Netherlands-based Stichting NLnet”. Neste momento a
maioria dos investimentos são do governo norte americano. (WIKIPÉDIA, WIKIPÉDIA,
2016).
A rede TOR ganha notoriedade mundial e passa a ser alvo de diversos ataques,
incluindo operações governamentais, a fim de acabar com o anonimato de seus
usuários.
Em janeiro de 2014, é lançado o documento “Tor: The Second-Generation
Onion Router (2014 DRAFT v1)” abordando as diversas modificações que a rede TOR
sofrera até aquele momento. Em novembro do mesmo ano, é realizada a “Operation
Onymous” envolvendo forças policiais de 17 países a fim de fechar sites relacionados
a venda de drogas, tráfico de armas e lavagem de dinheiro que operavam na rede
TOR. Essa operação expôs vulnerabilidades dessa rede gerando desconfiança por
parte de seus usuários quanto a eficácia do anonimato objetivado por esse projeto.
Apesar de a operação não revelar como identificou os responsáveis pelos sites, o TOR
Project afirmou que é mais provável o sucesso de investigações policiais normais do
que a atuação sobre a implementação da rede. (WIKIPÉDIA, 2016).
Anonimato e confidencialidade são características distintas. A primeira refere-
se à incerteza da origem e do destino das comunicações; e a segunda está
relacionada à garantia de que somente o destinatário irá ter acesso ao conteúdo dos
dados transmitidos. Dito isso, a rede TOR tem por objetivo garantir somente o
anonimato de seus usuários.
Como será abordado neste trabalho, um dos pontos vulneráveis dessa rede
são os chamado Nós de Saída (Exit Nodes), onde os dados podem transitar sem
13
criptografia da rede TOR. Dessa forma, ataques do tipo man-in-the-middle (MITM)
através da Análise de Tráfego são possíveis. (WIKIPÉDIA, 2016).
1.2 Problema
Visando o anonimato nas comunicações realizadas pelo Exército Brasileiro na
Internet, é oportuno verificar: a criação de um nó de saída institucional na rede TOR é
válido a fim de evitar ataques MITM?
1.3 Hipóteses
H1: a criação de um nó de saída institucional na rede TOR é válido a fim de
evitar ataques MITM.
H2: a criação de um nó de saída institucional na rede TOR não é válido a fim
de evitar ataques MITM.
1.4 Objetivos
A seguir, têm-se os objetivos, geral e específicos, a que o presente trabalho se
propôs atingir, visando apresentar a solução do problema em questão.
1.4.1 Objetivo geral
A presente pesquisa tem por escopo provar se a criação e a utilização de um
nó de saída próprio na rede TOR evita ataques do tipo MITM, a fim de garantir o
anonimato das comunicações pretendido pelo TOR Project na Internet.
1.4.2 Objetivos específicos
Para alcançar com êxito o escopo principal, sugere-se os seguintes objetivos
específicos a serem alcançados:
1. Definir o funcionamento da rede TOR;
2. Definir a criação de um nó de saída na rede TOR;
3. Definir ataques do tipo MITM;
14
4. Definir Bitcoin.
1.5 Justificativa e Relevância para as Ciências militares
A justificativa para o desenvolvimento deste trabalho encontra respaldo na
imposição da Política Cibernética de Defesa, quando esta enumera os objetivos a
serem atingidos, dentre os quais o de “estabelecer programas/projetos a fim de
assegura a capacidade de atuar em rede com segurança, fortalecendo, dessa forma,
a operacionalidade da atividade de Comando e Controle no Ministério da Defesa.”,
como já foi citado.
Este trabalho se torna relevante para as ciências militares na medida em que
produz conhecimento que pode resultar em uma capacidade militar em proveito das
Forças Armadas, a fim de tornar as comunicações mais seguras na internet em
diversas situações, dentre as quais destacam-se:
1. Comunicação entre os diversos escalões de comando nos momentos
de crise ou na indisponibilidade dos meios usuais;
2. Comunicação com elementos de inteligência;
3. Comunicação com militares em nações estrangeiras;
4. Realização de buscas e ataques na internet de forma anônima.
Entretanto, é válido ressaltar que a rede TOR está em constante
aperfeiçoamento e que atualizações do seu design são lançadas periodicamente,
fazendo-se necessário um esforço no sentido de acompanhar a evolução do
anonimato na internet.
1.6 Estado da Arte
Para que se atinja o anonimato na internet, todos os tipos de conexões devem
ser redirecionadas por servidores intermediários antes que atinjam o destino final, bem
como não deve haver o armazenamento de logs (SILVA, 2016). Assim, busca-se o
modelo a partir das seguintes premissas:
Toda conexão deve ser realizada através da rede TOR;
O gateway Whonix deve ser utilizado para maior segurança;
Toda transação de valores monetários deve ser realizada através de
Bitcoin;
15
A carteira Electrum deve ser utilizada, com movimentações pelo
Bitmixer.
Deve-se fazer uso do sistema operacional Tails para navegações WEB.
Todas tecnologias citadas serão detalhadas neste trabalho.
Apesar do modelo apresentado ser eficaz, é importante frisar que tecnologias
novas surgem diariamente, fazendo-se necessário um esforço no sentido de verificar
as melhores oportunidades de anonimato na Internet.
1.7 Procedimentos Metodológicos
Para alcançar a resposta para o problema levantado e a consequente
confirmação parcial da hipótese H1, inicialmente foi realizado uma pesquisa
exploratória a fim de se detalhar o funcionamento e a utilização da rede TOR, bem
como apresentar o conceito de ataques MITM e Bitcoin.
Em seguida, a pesquisa passou a ser descritiva com a finalidade de detalhar a
contratação de um Servidor Virtual Privado utilizando Bitcoin e a criação de um nó de
saída na rede TOR.
Por fim, através de uma abordagem qualitativa, o trabalho foi direcionado para
a realização de experimentos, comprovando a possibilidade de ataques MITM no nó
de saída da rede TOR.
1.7.1 Delineamento da pesquisa
O delineamento da pesquisa contemplou o uso de pesquisa bibliográfica e
documental, além de experimentos realizados em um nó de saída da rede TOR,
seguido da apresentação e discussão dos dados obtidos.
1.7.2 Procedimentos para a revisão da literatura
a. Fontes de busca
A revisão da literatura teve as seguintes fontes de busca:
- Publicações oficiais do TOR Project;
- Livros publicados;
- Documentos oficiais;
16
- Sites relevantes na Internet.
b. Critérios de inclusão
- Publicações nos idiomas português e inglês;
- Publicações do período compreendido entre 2012 e 2016;
- Publicações de sítios oficiais ou acadêmicos.
c. Critérios de exclusão
- Publicações de autoria não comprovada ou desconhecida;
- Publicações de sítios não-oficiais;
- Publicações com conteúdo de credibilidade duvidosa.
1.7.3 Sequência das ações
Para garantir o anonimato, todos os passos realizados na parte prática deste
trabalho foram realizados através da rede TOR, com exceção do download do TOR
Browser, realizado no site oficial do TOR Project -
https://www.torproject.org/download/download-easy.html.en.
Ao abrir o TOR Browser e conectar-se rede, foi acessado o site
“https://electrum.org/#download” a fim de se fazer download e a instalação da carteira
bitcoin Electrum. Em seguida, foi realizado o cadastramento de um e-mail no site
http://www.bol.uol.com.br/ a fim de servir como meio para autenticação da conta em
um servidor virtual privado (VPS).
Após, foi acessado o site https://www.yourserver.se/ para realizar o
cadastramento do VPS, utilizando como autenticador o e-mail previamente criado.
Para realizar o pagamento do aluguel do VPS, foi acessado o site https://bitmixer.io/
a fim de dissimular a transferência de Bitcoin. Em seguida, realizou-se uma
transferência de Bitcoins para o VPS, combinando a carteira Electrum na rede TOR e
o Bitmixer.
Após a conferência do pagamento pelo VPS, obteve-se o login e a senha de
root para acesso ao servidor. Assim, foi realizada a conexão secure shell (ssh) via
proxychains na rede TOR a fim de garantir o anonimato. Já logado no servidor, fez-se
a instalação do serviço de tunelamento da rede TOR, bem como a configuração do nó
de saída.
17
Uma vez iniciado, acompanhou-se a situação do nó de saída por cerca de uma
semana através do site https://atlas.torproject.org/. Em seguida, foi utilizado o
tcpdump para realizar capturas de tráfego no nó de saída. Assim, o TOR Browser foi
configurado para utilizar como nó de saída somente o configurado anteriormente,
sendo acessados os site “http://www.pudim.com.br/” e
“http://www.webs.com/s/login/relogin”.
Em seguida, foi utilizado o programa scp para fazer o download do arquivo
gerado pelo tcpdump a fim de ser analisado no programa wireshark. Por fim, localizou-
se os dados transmitidos pelo TOR Browser, concluindo que o nó de saída pode
interceptar todo fluxo de dados não criptografado sob sua responsabilidade.
18
2 REDE TOR
De acordo com o documento “Tor: The Second-Generation Onion Router (2014
DRAFT v1)”, o “The Onion Routing” é uma rede aberta baseada no protocolo SOCKS
e projetada para alcançar o anonimato de aplicações que utilizam o “Transport Layer
Protocol” (TCP), através da sobreposição de camadas de criptografia.
2.1 Protocolo SOCKS
A RFC-1928, de Março de 1996, normatiza o protocolo SOCKS Versão 5 que
representa um esforço orientado à comunicação criptografada TCP e UDP, entre
clientes isolados em uma rede interna por um firewall e servidores em redes externas.
A figura a seguir ilustra o funcionamento do protocolo SOCKS na pilha do
modelo OSI:
Figura 1: Protocolo SOCKS no modelo OSI Fonte: autor
Conforme a figura 1, todo o fluxo de dados gerado por uma aplicação é
confinado e gerenciado pelo protocolo SOCKS na camada de sessão do modelo OSI
e posteriormente entregue às camadas subsequentes, até a camada física do cliente.
Quando os dados chegam no servidor SOCKS, eles são processados e
encaminhados ao destino final. Em caso de resposta, o caminho inverso é seguido.
Devido ao confinamento dos dados de uma aplicação para um posterior
redirecionamento, o protocolo SOCKS deu origem ao conceito de proxy, amplamente
utilizado em redes estruturadas modernas, bem como tornou-se comum a analogia de
19
sua utilização com a ideia de túnel entre as diversas camadas de sessão, através de
uma comunicação direta.
A fim de aproveitar os recursos oferecidos pelo protocolo SOCKS, os
desenvolvedores da rede TOR optaram por utilizá-lo, tendo como principal vantagem
a compatibilidade com todas as aplicações que fazem uso de conexões TCP. Porém,
diferentemente do propósito inicial do protocolo SOCKS, o cliente TOR o utiliza para
comunicação entre processos de um mesmo sistema operacional, como será
abordado no tópico 2.2.3.2 – Etapas. (Tor: The Second-Generation Onion Router
(2014 DRAFT v1), 2014).
Caso a rede TOR esteja sendo utilizada em um sistema operacional Windows,
a abertura do túnel SOCKS é realizado concomitante a execução do TOR Browser.
Já nos demais sistemas operacionais, a rede TOR pode ser instalada apenas como
um serviço de tunelamento SOCKS ou exatamente como no Windows. Além disso,
tanto o serviço TOR como o TOR Browser, abrirão túneis independentes, funcionando,
por default, nos sockets 127.0.0.1:9050 e 127.0.0.1:9150, respectivamente.
2.2 Funcionamento geral do TOR
A rede TOR existe graças a iniciativa de voluntários em disponibilizar servidores
que funcionam como retransmissores, chamados nós, capazes de redirecionar dados
para outros nós da rede, bem como realizar a comunicação com o destino final.
Para possibilitar o anonimato durante o uso da rede TOR, o fluxo de dados deve
ser retransmitido no mínimo três vezes. Essa sequência de retransmissão recebe o
nome de circuito e possui os seguintes agentes:
1. Guards (Nós de entrada): são responsáveis por conectar o cliente à rede
TOR, bem como retransmitir os dados para os demais nós da rede. Devido a
criptografia realizada no cliente, o Guard desconhece o endereço do destino final dos
dados, restando somente a informação do endereço do próximo nó.
2. Middle-Relays (Nós): são nós intermediários responsáveis por
encaminhar o fluxo de dados ao próximo Relay ou até um Exit-Relay.
3. Exit-Relay (Nós-de-saída): são nós responsáveis pela comunicação com
o destino final.
20
A ilustração de um circuito na rede TOR é apresentada na figura a seguir:
Figura 2: Ilustração do funcionamento da rede TOR
Fonte: http://arstechnica.com/
Conforme a figura 2, assim que o serviço TOR é iniciado, ocorre a escolha da
sequência de servidores que constituirão o circuito utilizado para comunicação com o
destino final. Após a escolha, é realizada a construção desse circuito utilizando
criptografia, de forma que cada nó seja capaz de identificar somente seu antecessor
e seu sucessor - para onde enviará os pacotes de dados. Por fim, o nó de saída retira
a criptografia da rede TOR a fim de tornar possível a comunicação com o destino final.
Como já foi dito, a rede TOR está em constante aprimoramento e no momento
em que este trabalho é realizado, as seguintes características definem a sua
implementação:
Encaminhamento perfeitamente secreto: a rede TOR utiliza um método
capaz de gerar o anonimato;
Separação entre os protocolos da camada de aplicação e a de
anonimato: o anonimato provido pela rede TOR não influencia no fluxo de
dados de uma aplicação;
Multiplexação: A rede TOR permite o compartilhamento de um mesmo
circuito entre várias aplicações;
Topologia de túneis: A rede TOR roteia seu fluxo de dados através de
canais criptografados, simulando túneis entre os nós;
Balanceador de carga: A rede TOR dispões desse recurso a fim de não
sobrecarregar um circuito;
21
Diretórios autoritativos: o TOR Project possui servidores autoritativos
confiáveis, responsáveis por manter e autenticar as informações da rede;
Políticas de saída flexíveis: é possível gerenciar o tipo de tráfego que
um determinado nó de saída irá processar;
Conferência de integridade: A rede TOR garante a integridade dos
dados;
Resistência a censura: A rede TOR implementa formas de driblar a
censura;
Arquitetura modular: Implementações na rede TOR não podem interferir
nas estruturas já concebidas.
As características enumeradas foram desenvolvidas a partir das metas de
implementação estabelecidas pelo TOR Project, a saber:
Aplicabilidade: o sistema deve ser aplicável no mundo real, em termos
de custos, legalidade e facilidade de implementação;
Usabilidade: o sistema deve ser de fácil utilização pelo usuário final;
Flexibilidade: o sistema deve comportar mudanças, bem como
documentação detalhada, de forma a possibilitar estudos futuros;
Simplicidade: Todos os conceitos da rede TOR devem ser de fácil
entendimento.
Por outro lado, o projeto TOR não tem como meta:
Conexão fim-a-fim: Na comunicação peer-to-peer (fim-a-fim) cada
usuário pode se comportar tanto como cliente, como servidor - por
exemplo, transferências Torrent. Dito isso, o TOR não busca soluções
nesse sentido, uma vez que prioriza a comunicação com um servidor de
aplicação centralizado;
Segurança contra ataques fim-a-fim: O TOR não procura proteger
contra ataques realizados fora da rede TOR, por exemplo em
navegadores Web;
Normatização de protocolos: O TOR se aplica na camada de sessão,
não se importando com as camadas superiores do modelo OSI.
Existem diversos projetos de implementação na rede TOR voltados a melhoria
de tráfego, segurança e robustez, porém não há interesse em desenvolver a
comunicação fim-a-fim tendo em vista a grande quantidade de protocolos da camada
22
de aplicação, o que necessitaria de soluções específicas para cada finalidade. (Tor:
The Second-Generation Onion Router (2014 DRAFT v1), 2014).
2.3 Detalhamento
A seguir, o funcionamento da rede TOR será detalhada, iniciando com os
diretórios servidores, servidores autoritativos, consensus e bridges. Após, será
explicado a escolha do circuito, bem como a sua criação. Finalizando, será abordado
o funcionamento do serviço de hospedagem anônimo da rede TOR, bem como
informações adicionais acerca da configuração e acesso à rede.
2.3.1 Diretórios Servidores
Dentre outros artifícios, o usuário da rede TOR atinge o anonimato quando
várias conexões de diferentes clientes deixam um mesmo nó de saída,
impossibilitando a identificação de uma conexão específica - processo característico
do anonimato pela massa. Ainda, para dificultar o levantamento de padrões por um
possível atacante, o cliente estabelece vários circuitos ao mesmo tempo a fim de
pulverizar o fluxo de dados do usuário na rede TOR.
Para que um cliente possa escolher as diversas rotas, o mesmo deve conhecer
todas as possibilidades. Para isso, o TOR Project é responsável por manter e distribuir
uma base de dados atualizada contendo todas as informações públicas da rede, além
de disponibilizar a hospedagem de sites anônimos, os chamados Hidden Service.
Dentro desse contexto, a rede TOR utiliza uma pequena porção de nós como
repositórios, chamados diretórios servidores, responsáveis por coletar mudanças na
topologia da rede, bem como o estado de cada nó, incluindo chaves criptográficas,
endereço IP, porta, políticas de saída e velocidade da banda. A responsabilidade pelo
envio dessas informações é de cada nó, sob a penalidade de não compor a rede. Não
obstante, repositórios e nós também enviam dados para servidores autoritativos,
responsáveis por validar, assinar e redistribuir as informações recebidas de forma que
os dados se mantenham íntegros e confiáveis para utilização pelos clientes. (Tor: The
Second-Generation Onion Router (2014 DRAFT v1), 2014)
Através da prática citada no parágrafo anterior, várias redundâncias do banco
de dados são criadas, aliviando a carga sobre os servidores autoritativos, bem como
23
enrobustecendo a rede. Ainda, é válido ressaltar que o envio de dados é realizado
somente se um usuário alterar as configurações default do seu cliente TOR para
funcionar como um nó.
Toda informação do banco de dados é obtida através do compartilhamento
automático dos clientes TOR com diretórios servidores; ou no site “https://consensus-
health.torproject.org/” por meio de downloads.
2.3.2 Servidores Autoritativos
Servidores autoritativos são diretórios mantidos por pessoas de confiança dos
desenvolvedores do TOR Project - inclusive de conhecimento pessoal - através dos
quais toda a informação da rede é recebida, validada, assinada e redistribuída.
Atualmente, existem oito servidores autoritativos, relacionados na figura
abaixo:
Figura 3: Localização dos Servidores Autoritativos
Fonte: autor
Como se observa na figura 3, os servidores autoritativos estão distribuídos
estrategicamente em diferentes países a fim de dificultar uma possível operação
contra a rede TOR, o que necessitaria de uma ação internacional conjunta.
Após receber as informações da rede, os diretórios autoritativos realizam
alguns testes de conexão para definir o seu nível de credibilidade. Em seguida,
publicam um conjunto de documentos assinados chamado “Consensus” para os
diretórios servidores, bem como no site já citado. (Dingledine, 2016)
24
Segundo o documento dir-spec (Dingledine, 2016) , Os diretórios autoritativos
também são responsáveis por classificar cada nó através das seguintes Flags:
Authority: se um nó é um servidor autoritativo;
Exit: Se um nó aceita saída para, pelo menos, duas das portas 80, 443
e 6667; além de, pelo menos, uma saída para um endereços IP com
mascará de sub-rede /8.
Badexit: se o nó de saída não é recomendado por mais de 3 servidores
autoritativos;
Fast: se um nó estiver entre os oito mais rápidos e/ou disponibilizar uma
banda de pelo menos 100KB/s.
Guard: se um nó estiver entre os 25% mais rápidos e/ou disponibiliza
uma banda de pelo menos 2MB/s.
V2Dir: se um usuário configurou o seu nó para funcionar como diretório
servidor;
Stable: se um nó está ativo a mais de sete dias consecutivos;
Running: se um nó está ativo a mais de 45 minutos;
Valid: se um nó está validado por um servidor autoritativo.
A lista de servidores autoritativos está presente no código fonte do TOR e,
devido a política de software livre, o usuário pode alterar a origem do “consensus”.
Entretanto, os desenvolvedores da rede recomendam manter as configurações
default. (Dingledine, 2016).
2.3.3 Consensus
O consensus é um conjunto de documentos compilados e assinados pelos
servidores autoritativos a cada uma hora. Esse processo é realizado da seguinte
forma:
1. Cada servidor autoritativo compila uma lista de nós conhecidos, incluindo
informações como flags e velocidade de banda;
2. Após, realizam uma permuta desses dados de forma a passar pela
aprovação dos demais servidores autoritativos;
3. Então, cada servidor autoritativo combinas as informações dos demais e
assinam esse documento;
25
4. Em seguida, as informações são permutadas novamente e então
assinadas pelos demais servidores autoritativos;
5. Por fim, um novo consensus é publicado caso a maioria dos servidores
autoritativos aprovem as informações.
No Windows, o consensus é encontrado no diretório
“.\TorBrowser\Browser\TorBrowser\Data\Tor”. Já no Linux, caso tenha sido instalado
somente o serviço de tunelamento, o consensus permanece no diretório “/var/lib/tor/”;
caso tenha sido instalado o browser, é encontrado no mesmo diretório do Windows.
2.3.4 Bridges
Como a lista de todos os nós da rede TOR são de domínio público, é possível
que um país bloqueie todo o acesso a esses endereços, censurando o uso da rede
TOR. Para contornar esse possível problema, foi implementado o conceito de bridge
– nós especiais que não são divulgados em números absolutos.
O servidor autoritativo responsável por administrar a relação de bridges é o
“Tonga” e para solicitar uma lista de bridges, deve-se seguir os seguintes passos,
conforme as figura:
Figura 4: Obtenção de endereços Bridges
Fonte: autor
26
1. Acessar o site: “https://bridges.torproject.org/bridges”
2. Resolver o captcha;
3. Acessar a lista.
Caso não seja possível acessar o site supracitado, deve-se enviar um e-mail
para “[email protected]” utilizando um dos seguintes provedores: Riseup; Gmail;
ou Yahoo. As etapas para configurar o uso de uma bridge pelo TOR serão abordadas
no tópico 2.2.6 – Arquivo torrc.
2.3.5 Escolha Do Circuito
Após a obtenção do consensus atualizado, é iniciada a escolha dos circuitos
pelo cliente, com no mínimo três saltos e baseando-se nas flags atribuídas a cada nó
e na banda disponibilizada.
Segundo o documento path-spec (Dingledine & Nick Mathewson, 2016), a
escolha do circuito acontece em duas etapas: na primeira deve-se selecionar todos
os nós elegíveis para determinada posição; a seguir são escolhidos randomicamente
dentro das possibilidades levantadas. Entretanto, as seguintes regras gerais devem
ser seguidas:
Não será escolhido o mesmo nó duas vezes no mesmo circuito;
Não serão utilizados mais de um nó pertencentes ao mesmo voluntário
no mesmo circuito, mais detalhes serão abordados no tópico 2.2.6 –
Arquivo torrc;
Somente um nó com máscara de sub-rede /16;
Não serão escolhidos nós inválidos;
O primeiro nó deve ser um Guard;
A velocidade da banda do cliente deve ser compatível com a do nó.
A figura a seguir exemplifica uma conexão na rede TOR:
27
Figura 5: Exemplo de circuito na rede TOR
Fonte: autor
Na figura 5, após clicar no TOR Button (1.), é mostrado todo o circuito até o
destino final (2.). Nesse caso, o Guard possui o IP 178.62.197.82, o Relay possui o IP
94.23.1.164 e o Exit-Node possui o IP 185.86.148.206. Além das regras gerais, cada
parte do circuito tem suas peculiaridades, como será abordado a seguir.
2.3.5.1 Exit Nodes
Nós de saída são configurados por um voluntário para que o cliente se
comporte como tal. Essa configuração é realizada através das políticas de saída e
deve-se estabelecer os interesses em disponibilizar o fluxo de dados relacionado a
determinado protocolo da camada de aplicação.
Na escolha de um nó de saída para uma conexão, o cliente deve se preocupar
com a capacidade de determinado nó em conseguir resolver as requisições. A seguir,
segue um exemplo de política de saída:
Figura 6: Exemplo de Política de Saída
Fonte: autor
Conforme a figura 6, a configuração foi realizada para permitir a saída dos
protocolos necessários para comunicação WEB, rejeitando todo o restante. A
configuração de um nó de saída será abordada no tópico 2.2.6 – Arquivo torrc.
28
2.3.5.2 Guard Nodes
Após determinar o nó de saída, o cliente escolhe um de entrada, mantendo
uma lista de, pelo menos, três Guards para serem utilizados randomicamente a partir
das possibilidades levantadas. Como já foi citado no tópico 2.1.1.1 – servidores
autoritativos, não é possível configurar um nó de entrada pois o próprio TOR elege os
Guard a partir de regras pré-determinadas.
2.3.5.3 Middle Relays
Para que um nó seja elegível como um middle-relay, basta que o mesmo tenha
a flag running setada. Cabe ressaltar que um nó pode ser usado para comunicação
entre cliente e Hidden Service, independente de possuir a flag Exit setada - Isso ocorre
devido a conexões desse modo não trafegam fora da rede TOR.
2.3.6 Construção do Circuito
Após a escolha dos circuitos, o cliente TOR passa a construí-los a partir de três
motivos, a saber:
a. Preemtivamente
O cliente TOR mantém um histórico - em torno de uma hora - dos circuitos
montados, a fim de acioná-los rapidamente. Especialmente ao ser inicializado, o
cliente TOR mantém, pelo menos, um circuito nunca utilizado para a porta 80 e, pelo
menos, dois circuitos novos para conexões com Hidden Services - caso o cliente
também esteja hospedando um Hidden Service, esse número aumenta para três.
Após, o cliente TOR adaptará os circuitos já existentes de acordo com as
requisições do usuário, escolhendo os nós de saída adequados para cada aplicação
utilizada. Caso não haja solicitações pelo usuário durante uma hora, o cliente TOR
não abrirá circuitos preemtivamente. Após uma hora, os dados do circuito são
descartados.
b. Sob demanda
São construídos novos circuitos conforme surjam requisições da camada de
aplicação que não possam ser atendidas pelos circuitos já criados.
c. Para testes
29
Assim que um circuito é aberto, o cliente TOR constrói outro circuito para se
conectar ao anterior a fim de testar se o primeiro está funcionando. Essa conexão
também é realizada para testes de banda. (Dingledine & Nick Mathewson, 2016).
Para prevenir a censura, o fluxo de dados na rede TOR deve ser semelhante a
uma conexão HTTPS. A exemplo do aproveitamento do protocolo SOCKS, a rede
TOR utiliza conexões TLS para estabelecer um canal criptografado entre os diversos
nós, conforme a figura a seguir (Tor: The Second-Generation Onion Router (2014
DRAFT v1), 2014):
Figura 7: Comparação de conexões TLSv1.2
Fonte: autor
Na figura 7, o lado esquerdo da linha vertical vermelha é uma conexão com o
site “https://www.gmail.com” através da internet aberta. Já o lado direito representa a
conexão com o Guard da rede TOR cujo endereço IP é 209.222.8.186. Observa-se
que, em ambos os casos, é utilizado o protocolo Transport Layer Security Version 1.2
(TLSv1.2) com etapas praticamente idênticas.
2.3.6.1 Células
Após o estabelecimento da conexão TLS com o Guard, o cliente está apto para
transferir dados na rede TOR. Esses dados são transmitidos com tamanho fixo de
512bytes e são chamados de células. Esse tipo de estratégia dificulta a correlação de
tráfego por padrão de tamanho de pacote. (Tor: The Second-Generation Onion Router
(2014 DRAFT v1), 2014).
30
A tabela a seguir apresenta a estrutura das células:
Header Payload
Circ ID Command Length Data
2 Bytes 1 Byte 2 Bytes 507 Bytes
512 Bytes
Tabela 1: Estrutura de uma célula
Fonte: Tor: The Second-Generation Onion Router (2014 DRAFT v1), 2014
Na tabela 1, é possível observar que a célula é dividida em header e payload.
O header é dividido em CircID, cujo valor é um número randômico para identificar um
circuito específico; length, que representa o tamanho do Payload; e o campo
Command, que pode assumir os seguintes significados:
Padding: utilizado para manter uma conexão ativa;
Create: criar um circuito. Nas versões atuais, não é utilizado;
Created: resposta de sucesso da célula Create. Nas versões atuais, não
é utilizado;
Relay: utilizado para transmissão de dados;
Destroy: ordem de destruição de um circuito;
Create_fast: criação de circuito com o aproveitamento do histórico
abordado no tópico 2.2.3 – Construção do circuito.
Created_fast: resposta de sucesso da célula Create_fast;
Version: identificar a versão do cliente TOR utilizada;
Netinfo: informações da rede;
Relay_early: utilizado para limitar o tamanho do circuito à 8 nós;
Create2: Utilizado para construir circuitos;
Created2: resposta de sucesso da célula Create2;
Vpadding: utilizado para manter circuitos ativos;
Certs: autenticação de conexões entre os nós;
Auth_challenge: autenticação de conexões entre os nós;
Authenticate: autenticação de conexões entre os nós;
Authorize: autenticação de conexões entre os nós. Reservado para uso
futuro;
31
A tabela abaixo apresenta a estrutura de uma célula cujo command é relay:
HEADER RELAY HEADER PAYLOAD
Circ ID Command Length Relay
Command
Recognized Stream ID Digest Length Data
2 Bytes 1 Byte 2 Bytes 1 Byte 2 Bytes 2 Bytes 4 Bytes 2 Bytes 496 Bytes
512 Bytes
Tabela 2: Estrutura de células Relay
Autor: The Second-Generation Onion Router (2014 DRAFT v1), 2014
Observa-se na tabela 2, que a célula é dividida em header, relay header e
payload. Dentro do relay header, o campo recognized atua como autenticador da
célula; o campo StreamID é necessário devido a multiplexação do túnel, possuindo
um número randômico para identificar um stream de dados específico; o campo digest
garante a integridade do payload - cabe ressaltar que o campo digest é calculado em
cada nó do circuito, uma vez que o payload varia conforme as camadas de criptografia
são retiradas; o campo Lenght de uma célula relay contém a quantidade real de dados,
sem criptografia; por fim, campo relay_command pode assumir os seguintes valores:
Begin: utilizado para começar um stream de dados;
Connected: resposta de sucesso da célula Begin.
Data: envio de dados;
End: para fechar um stream;
Sendme: utilizado para controle de tráfego para evitar
congestionamento;
Extend: para estender um circuito. Nas versões atuais, não é utilizado;
Extendend: resposta de sucesso da célula Extend. Nas versões atuais,
não é utilizado;
Truncate: para destruir parte de um circuito;
Truncated: resposta de sucesso da célula Truncate;
Drop: utilizado para manter streams abertos;
Resolve: utilizado para resolver pesquisas DNS anonimamente;
Resolved: resposta de sucesso da célula Resolve;
Begin dir: começar um strem com um diretório servidor, a fim de atualizar
o consensus;
Extend2: utilizado para estender um circuito;
Extended2: resposta de sucesso da célula Extend2.
32
2.3.6.2 Etapas para a Construção do Circuito
Quando se executa o TOR browser no Windows ou quando se inicia o serviço
de tunelamento no Linux, o consensus é atualizado. Após, é realizada a escolha dos
nós que serão utilizados e a construção dos circuitos criptografados utilizando o
protocolo TLSv1.2 é iniciada. Somente quando o usuário faz uso de uma aplicação
que o tunelamento SOCKS é aberto.
Na figura a seguir, é mostrada uma comparação entre as suítes criptográficas
suportadas pelo site “http://www.gmail.com” e uma conexão com o Guard no protocolo
TLSv1.2:
Figura 8: Comparação de suítes criptográficas
Autor: autor
Conforme a figura 8, observa-se a similaridade entre as suítes criptográficas
suportadas e escolhidas pelo site “http://www.gmail.com” (esquerda da linha vertical
vermelha) e pelo cliente TOR (direita da linha vertical vermelha). A partir desse
momento, toda comunicação na rede TOR possui criptografia TLSv1.2.
Imediatamente após a conexão com o Guard, é realizada a autenticação de
ambas as partes como integrantes da rede TOR, através das células cert, authenticate
e auth_challenge. Então, é escolhido um CircID e inicia-se o processo de negociação
de uma chave simétrica Advanced Encryption Standard (AES) de 128bits com o
Guard, a fim de usá-la para criptografar os dados do primeiro salto, conforme a figura
a seguir:
33
Figura 9: Sequência para cálculo de chave simétrica na rede TOR
Fonte: autor
Pode-se observar pela figura 9, que Alice envia uma célula create 2 para o
Guard (1.), contendo em seu payload a primeira parte do algoritmo Diffie-Hellman (DH)
- o payload é criptografado com a chave pública do Guard (Chave Assimétrica), a fim
de garantir a confidencialidade. Nesse momento existem duas camadas de
criptografia, a primeira é providenciada pela conexão TLSv1.2, a segunda pela
criptografia de chave assimétrica.
Por sua vez o Guard responde com uma célula created 2 para Alice (2.),
contendo em seu payload a segunda parte do algoritmo DH, bem como o hash da
chave simétrica calculada por ele. Repare que a resposta não é criptografada, o que
não influi na segurança uma vez que a criptografia TLSv1.2 permanece. Por fim, Alice
também calcula a chave simétrica, comparado o hash da mesma com o obtido do
Guard, possibilitando o envio de células Relay em caso de igualdade. Vale ressaltar
que no algoritmo DH, a chave simétrica nunca é enviada pela rede.
Após a conexão com o Guard, o circuito deve ser expandido, conforme a figura
a seguir:
34
Figura 10: Sequência para extensão de circuitos na rede TOR
Fonte: autor
Observa-se na figura 10, que Alice enviar uma célula relay_extend 2 para o
Guard (1.). O payload dessa célula é criptografado com a chave AES negociada
anteriormente, dividindo-se entre o endereço para conexão com o próximo salto
(<IP/Porta Middle>) e o conteúdo para negociação de uma chave simétrica entre Alice
e Middle, porém criptografado com a chave pública de Middle – esse processo garante
que o Guard não interfira na negociação.
Guard recebe o pacote e decriptografa o seu payload, visualizando as
informações necessárias para conectar-se ao Middle. Em seguida, Guard estabelece
uma conexão TLSv1.2 com Middle. Então, o Guard envia uma célula create 2 para
Middle (2.), contendo como payload a primeira parte DH entre Alice e Middle - nesse
processo é escolhido um novo circID entre Guard e Middle, sem conhecimento de
Alice ou outros nós. Middle responde para Guard (3.) com uma célula created 2,
contendo a sua parte DH e o hash da chave calculada por ele. Em seguida, o Guard
encripta a resposta em uma célula relay_extended 2 e envia para Alice (4.). Alice
recebe o pacote, decriptografa-o, estabelece a chave simétrica, calculando o hash e
comparando-o com o recebido de Middle. Nesse momento, Alice e Middle possuem
35
uma chave simétrica AES 128bits única, sem conhecimento do Guard ou qualquer
outro nó.
Para estender o circuito até o nó-de-saída ou aumentar o número de nós
intermediários no circuito, os mesmos passos devem ser realizados de forma que uma
célula relay_extend 2 alcance o último nó do circuito em construção. Vale ressaltar
que os circuitos são modificados automaticamente pelo cliente TOR a cada dez
minutos e que quanto maior o circuito, mais lenta será a conexão. (Tor Path
Specification, 2016).
Assim, o seguinte diagrama será seguido:
Figura 11: Extensão de circuito na rede TOR
Fonte: autor
Observa-se na figura 11, que Alice deve encriptar, primeiramente, com a chave
pública de Exit, a fim de formar a célula Create 2. Em seguida sobrepõe a primeira
camada de criptografia utilizando a chave simétrica de Middle e, por último, utiliza a
chave simétrica do Guard. Após Alice enviar o pacote, cada nó retira uma camada de
criptografia, verifica o conteúdo do payload, substitui o CircID, enviando para o
próximo salto.
Eventualmente, será utilizada a célula create_fast na comunicação com o
Guard. Nesses casos, Alice enviará um valor randômico “x” e o Guard responderá
com uma célula created_fast, contendo um valor randômico “y”. Assim, ambos
possuem os valores de x e y e podem gerar uma chave simétrica compartilhada. Esse
tipo de conexão evita processamento com criptografia de chave pública, entretanto,
não provém autenticidade, integridade e confidencialidade, delegando essas
atribuições à conexão TLSv1.2 já estabelecida. (Tor Path Specification, 2016).
36
2.3.7 Camada de Aplicação
Após estabelecer o circuito, o cliente TOR está apto a abrir um stream de
dados, desde que aplicação escolhida suporte o protocolo TCP. É possível direcionar
o fluxo de dados TCP através da rede TOR, através do programa proxychains.
2.3.7.1 Etapas
Inicialmente, é necessário abrir um stream de dados entre o nó de saída e o
servidor da aplicação. A figura abaixo ilustra esse processo:
Figura 12: Uso da camada de aplicação na rede TOR
Fonte: autor
No exemplo acima, será iniciada uma conexão WEB. Após a aplicação realizar
uma requisição, o cliente TOR de Alice envia uma célula relay_begin para o nó de
saída, contendo em seu payload um novo StreamID, bem como o endereço e a porta
para a conexão. Depois de se conectar ao servidor, o Exit envia uma célula
relay_connected para Alice. Enfim pode-se iniciar a comunicação entre Alice e o
servidor Web desejado, conforme a figura abaixo:
Figura 13: Fluxo de dados da camada de aplicação
Fonte: autor
37
De acordo com a figura 13, Alice enviam uma requisição “HTTP GET” até o nó
de saída utilizando células relay_data. Então, o Exit realiza a comunicação com o
servidor, enviando a resposta para Alice.
Por fim, tem-se o fluxo completo da comunicação na rede TOR ilustrada no
modelo OSI:
Figura 14: Fluxo de dados na rede TOR
Fonte: autor
Conforme a figura 14, observa-se que os diversos clientes TOR canalizam os
fluxos de dados internos através do protocolo SOCKS. Por outro lado, a comunicação
externa é realizada através da conexão TLSv1.2. (Murdoch, 2011).
38
2.3.7.2 Consultas DNS
Algumas aplicações podem realizar consultas de Domain Name System (DNS)
antes de enviar requisições para o cliente TOR. Caso isso ocorra, Alice iria se expor
pois seu endereço real seria utilizado, podendo vir a desanonimizá-la.
Para evitar vazamentos de consulta DNS, a aplicação deve estar devidamente
configurada para enviar seu fluxo de dados para o cliente TOR, uma vez que este irá
utilizar células relay_resolve e relay_resolved para descobrir o endereço IP de um site.
Esse processo segue a mesma lógica aplicada a conexões web já explicadas.
2.3.8 Hidden Service
Como já foi citado, o TOR Project oferece uma solução para hospedagem de
sites anônimos - chamados Hidden services – baseada nos seguintes princípios:
1. Controle de Acesso: o servidor deve conseguir escolher com quem
deseja se conectar;
2. Robustez: o sistema deve suportas ataques, principalmente o de Denial
of Service (DoS);
3. Isenção: os pontos de introdução não devem ser responsabilizados
pelos dados transmitidos entre cliente e servidor;
4. Transparência: O TOR Project deve fornecer todos os meios necessários
para a conexão com um Hidden Service, a fim de evitar a instalação de
softwares adicionais para esse fim.
A seguir, serão especificadas as etapas para que Alice conecte-se à página
anônima hospedada por Bob na rede TOR.
2.2.8.1 Etapas
O funcionamento dos Hidden Service (HS) seguem passos descritos nas
figuras a seguir:
39
Figura 15: Hidden Service 1
Fonte: The Tor Network
Figura 15:
1. Bob configura o seu nó para hospedar um site anônimos, gerando
uma chave pública (PK) exclusiva para comunicação através de
hidden service.
2. O cliente TOR de Bob escolhe alguns pontos de introdução e cria
circuitos para o envio da chave pública criada;
Figura 16: Hidden Service 2
Fonte: The Tor Network
Figura 16:
1. Bob estabelece uma comunicação com um hidden service directory,
a fim de informar os pontos de introdução, o endereço do hidden
service, bem como a chave pública para comunicação;
40
2. O hidden service directory publica as informações para os diretórios
autoritativos a fim de validar as informações, bem como redistribuir
para os demais HS directories;
Figura 17: Hidden Service 3
Fonte: The Tor Network
Figura 17:
1. Bob compartilha o endereço do seu hidden service com Alice;
2. Alice entra em contato com um HS directory a fim de obter um ponto
de introdução, bem como a chave pública de bob;
3. Em seguida, Alice escolhe um ponto de encontro aleatório (rendez-
vous point), estabelecendo um circuito;
Figura 18: Hidden Service 4
Fonte: The Tor Network
41
Figura 18:
1. Alice envia uma mensagem encriptada com a chave pública de Bob
para o ponto de introdução. Essa mensagem contém o endereço do
ponto de encontro escolhido por Alice e um código de autenticação
(cookie).
2. O ponto de introdução encaminha a mensagem para Bom.
Figura 19: Hidden Service 5
Fonte: The Tor Network
Figura 19:
1. Caso Bob opte por aceitar a conexão com Alice, o mesmo deve
conectar-se ao ponto de encontro informado anteriormente e enviar
a código de autenticação;
2. O ponto de encontro informa Alice da conexão estabelecida. Alice
confere o código de autenticação e, enfim, tem acesso ao hidden
servisse de Bob.
É importante ressaltar que a conexão entre Alice e Bob não deixa a rede TOR,
além de ser efêmera, como qualquer outro circuito. (Tor: The Second-Generation
Onion Router (2014 DRAFT v1), 2014).
42
2.2.8.2 Publicação do Hidden Service
Como visto no tópico anterior, Bob compartilha o endereço de seu Hidden
service com Alice. Porém, com exceção do HS directory, Bob não é obrigado a
publicar esse endereço, o que faria com que seu site anônimo dificilmente recebesse
visitantes.
O cliente TOR gera o endereço dos hidden service a partir da chave pública
criada para esse fim. O site anônimo será composto por números e letras, totalizando
128bits, e receberá uma extensão “.onion” para identificá-lo – como, por exemplo
“v2cbb2l4lsnpio4q.onion”. Esse processo dificulta a identificação do endereço por
pessoas sem o interesse de Bob.
Portanto, não existe maneira de acessar sites com domínio “.onion” fora da rede
TOR. Por outro lado, afim de dar publicidade ao site e receber visitantes, alguns donos
de hidden servisse publicam o endereço na surfasse web, o que possibilita a
indexação por crawlers.
Outra forma de acessar endereços “.onion” é através de proxys na internet –
como o https://www.tor2web.org/ - porém, é valido ressaltar que o proxy está
conectado na rede TOR.
2.3.9 Arquivo torrc
O arquivo torrc é responsável por definir os parâmetros utilizados pelo cliente
TOR para se conectar na rede. Nele, são definidas as configurações de circuitos, nós,
portas e hidden servisses. Entretanto, o cliente irá carregar as opões default caso não
haja alteração nesse arquivo.
O arquivo torrc é localizado no diretório
“.\TorBrowser\Browser\TorBrowser\Data\Tor” do TOR Browser do Linux e do
Windows; e no diretório “/etc/tor” no serviço de tunelamento Linux.
A seguir serão listadas algumas configurações para serem adicionadas ao
arquivo torrc:
utilizar Guards específicos:
EntryNodes $<fingerprint>,$<fingerprint>,...
utilizar nós de saída específicos:
ExitNodes $<fingerprint>,$<fingerprint>,...
43
evitar determinados nós:
ExcludeNodes $<fingerprint>,$<fingerprint>,...
evitar determinados nós de saída:
ExcludeExitNodes $<fingerprint>,$<fingerprint>,...
configurar um nó:
ORPort <porta (default 9001)> Nickname <apelido> RelayBandwidthRate <banda (default 100)> KBytes RelayBandwidthBurst <banda (default 200)> KBytes AccountingMax <franquia (default 4)> GBytes DirPort <porta (default9030)> # funcionar como
servidor diretório MyFamily $<fingerprint>,$<fingerprint>,... #Define
uma família de nós, importante para a construção do circuito
ExitPolicy reject *:* # não funciona como um nó de saída
estabelecer um nó de saída:
ExitPolicy accept *:* # nesse caso serão aceitas todas as conexões
estabelecer um nó como bridge:
BridgeRelay 1
2.4 Formas de acessar o TOR
Nesse tópico, serão abordadas algumas formas de acessar a rede TOR, cada
uma com sua especificidade, vantagens e desvantagens. Cabe ao usuário definir os
seus objetivos a fim atingir o anonimato da melhor maneira possível.
2.4.1 Tor Browser
Seguindo as políticas de facilidade de uso definidas pelo TOR Project, Steve
Murdhock desenvolveu o “TOR” Browser utilizando como base a arquitetura do
navegador Firefox. Dentre as implementações realizadas por Steve na versão atual,
as mais relevantes são (The Design and Implementation of the Tor Browser [DRAFT],
2015):
Interface gráfica amigável;
Implementação do Tor Button;
44
Navegação Privada;
Utilização do addon “No script”;
Utilização do addon “Adblock plus”;
Utilização do addon “http everywhere”.
A interface gráfica aplicada no TOR Browser foi concebida para que um usuário
leigo consiga se conectar na rede sem problema, oferecendo inclusive opções para
conexão através de Bridges. O addon “No Script” está implementado para evitar
ataques a navegadores, principalmente de javascript. O addon “HTTPS Everywhere”
representa um esforço na tentativa de aumentar a segurança fim-a-fim - evitando que
o nó de saída possa analisar ou alterar o tráfego de dados - apesar de não suportar
diversos sites.
O TOR Browser é configurado por default para utilizar o túnel SOCKS,
conforme a figura a seguir:
Figura 20: Configuração do TOR Browser
Fonte: autor
Observa-se que a configuração é destinada ao tunelamento SOCKS, através
do socket 127.0.0.1:9150. Portanto, caso o usuário deseje utilizar outro Browser para
navegação WEB, deverá configurar da mesma forma da explicitada acima. Entretanto,
45
o TOR Project recomenda fortemente que o usuário utilize o TOR Browser default,
principalmente devido a possíveis vazamentos de consulta DNS. (The Design and
Implementation of the Tor Browser [DRAFT], 2015).
2.4.2 Tails
Tails é um sistema operacional completo desenvolvido, principalmente, para
navegação web de forma segura. Além de todas as implementações do TOR Browser,
o Tails apresenta como vantagens (https://tails.boum.org/index.en.html, 2016):
Pode ser instalado em um pen drive criptografado;
Funciona na memória ram, sem instalação em disco;
Isolamento do sistema operacional nativo;
Pode ser iniciado em uma Máquina Virtual (VM);
Realiza automaticamente Wipe da memória ram após desligamento;
A imagem a seguir ilustra o sistema operacional Tails, rodando a partir da
memória ram em uma VM:
Figura 21: Sistema operacional Tails
Fonte: autor
Conforme a figura 21, é importante ressaltar que o Tails somente irá conseguir
fazer Wipe na memória ram se o seu desligamento ocorrer de forma normal. Portanto
resetar a máquina ou eventuais quedas de energia impedirão o Tails de limpar a
memória.
46
2.4.3 Whonix
O Whonix foi projetado para roda através de maquinas virtuais e tem como
principal função evitar vazamentos de informações, bem como proteger o sistema
operacional nativo de ataques. Para atingir esses objetivos, o Whonix foi divido em
duas partes (https://www.whonix.org/wiki/Main_Page, 2016):
a. Whonix gateway
O Whonix gateway é um micro sistema operacional concebido para criar uma
placa de rede virtual capaz de direcionar o tráfego de dados pela rede TOR, bem como
gerenciar o seu acesso.
b. Whonix Workstation
O Whonix Workstation, assim como o Tails, é um sistema
operacional completo pré-configurado para ser utilizado com o
Whonix gateway.
A imagem a seguir ilustra a utilização do Whonix Gateway:
Figura 22: Utilização do Whonix gateway
Fonte: autor
Como é possível observar na figura 22, pode-se conectar qualquer máquina virtual ao Whonix gateway. No exemplo acima, todo tráfego de rede gerado pelo Kali será dentro da rede TOR.
47
2.4.4 Qubes
Seguindo a solução de compartimentação da rede oferecida pelo Whonix, o
sistema operacional Qubes leva ao extremo a segmentação de processos através de
máquinas virtual. Nele, o usuário possui liberdade para configurar o acesso a
diferentes programas conforme a sua necessidade. Além disso, o Whonix vem
instalado por default no Qubes, conforme a figura abaixo:
Figura 23: Qubes
Fonte: https://www.qubes-os.org/tour/
Pode-se observar na figura 23, que existem várias configurações pré definidas,
simbolizadas por cores diferentes. Isso reflete no tamanho do espaço para fazê-lo
funcionar, sendo recomendado no mínimo 32Gb em disco.
2.4.5 Orbot e Orfox
Orbot é uma solução de anonimato desenvolvido para sistemas operacionais
Android, com funcionamento semelhante ao de sistemas operacionais Linux, inclusive
com a opção de funcionar como um nó de saída.
48
Orfox é o navegador recomendado para se utilizar com o Orbot. Ambos são
representados na figura a seguir:
Figura 24: Orbot e Orfox
Fonte: https://play.google.com/store/apps/
Observa-se na figura acima que o método no Android é semelhante ao
utilizado no sistema operacional Linux, uma vez que o Orbot somente abre o
tunelamento SOCKS. Já o Orfox é semelhante ao TOR Browser, com as mesmas
funcionalidades já mencionadas.
2.5 Ataques Conhecidos
Nesse tópico serão abordados alguns ataques contra a rede TOR. Vale
ressaltar que não é meta do TOR Project a proteção contra ataques fim a fim, como
ataques web, uma vez que esses ataques não são realizados dentro da rede;
O ataque passivo de correlação de tempo e volume acontece quando um
observador controla o nó de entra e do saída de um circuito ao mesmo tempo. A partir
desse momento ele possui acesso à todos os endereços IPs que se conectam ao
Guard, dentre um dos quais é o da vítima. No outro ponto ele consegue observar todo
49
o fluxo que sai pelo nó de saída, sendo que um dos fluxos é o da vítima. Assim, é
possível correlacionar a quantidade de tráfego que entra pelo guard e a que sai pelo
exit ao mesmo tempo que correlaciona o endereço IP obtido pelo guard. (Tor: The
Second-Generation Onion Router (2014 DRAFT v1), 2014).
O TOR Project se referiu ao ataque de correlação de tempo e volume com de
alta probabilidade de sucesso, caso ele seja possível. Porém, é um ataque
extremamente difícil de ser executado tendo em vista a rotatividade dos circuitos
utilizados pelo cliente. (Tor: The Second-Generation Onion Router (2014 DRAFT v1),
2014).
Ataques ativos sobre os nós de saída também são possíveis. Em um primeiro
exemplo, o nó de saída pode alterar ativamente o conteúdo de um protocolo que não
realiza checagem fim-a-fim, como o HTTP. O TOR Project recomenda sempre que os
usuários utilizem protocolos que façam esse tipo de checagem. Como segundo
exemplo, um atacante pode enviar conteúdo ilícito para um determinado nó de saída
a fim de tentar derrubá-lo através das regras de um Servidor Virtual Privado (VPS) -
Dessa forma o VPS irá bloquear a conta do voluntário que ativou o nó.
2.6 Servidor Privado Virtual
Segundo a Wikipédia:
Servidor virtual privado, do inglês Virtual Private Server (VPS), é uma máquina virtual vendida como um serviço por uma empresa de hospedagem, porém também é possível que se crie VPS em computadores caseiros. O servidor possui seu próprio sistema operacional dedicado e o cliente possui acesso superusuário, permitindo a instalação de qualquer software que seja compatível com o sistema.[1] Ou seja, não existe de forma física. Para que seja possível a criação de um VPS, um programa especializado na virtualização das maquinas, deve ser instalado no servidor que irá compartilhar os recursos entre os VPS. [2] O VPS é uma solução muito mais barata para pessoas ou empresas com necessidades específicas que não podem ser atendidas por uma hospedagem comum. Por exemplo, executar alguma tarefa no servidor que utilize excessivamente os recursos dele, como memória ou processador, prejudicando outros clientes. Com um VPS o cliente tem uma parcela da memória, processador e demais recursos dedicados apenas para si podendo fazer uso destes recurso da forma que achar melhor, respeitando a ética e disciplina do contratado. (Muitas pessoas usam este recurso de forma irregular causando transtorno a outras pessoas, como uso deliberado de spam). (WIKIPÉDIA, 2016).
Dessa forma, a utilização de um VPS para hospedagem de nós da rede TOR
se tornou uma opção viável. Para evitar o ataque que gera bloqueio de conta citado
no item anterior, o TOR Project mantém uma lista de VPS que permitem o uso de seus
50
serviços como nós da rede. Basta acessar o site
“https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs” para se ter acesso a
lista. A partir desse site foi possível localizar o VPS utilizado para os teste deste TCC.
2.7 Estatísticas
Os sites da internet https://metrics.torproject.org/,
https://torstatus.blutmagie.de/ e https://atlas.torproject.org/# monitoram a rede,
publicando informações e estatísticas sobre os nós e as rede TOR.
Abaixo, são apresentados alguns dados sobre a rede:
Tabela 3: Estatísticas da rede TOR
Fonte: https://torstatus.blutmagie.de/
Observa-se pela tabela 3, que existem uma quantidade expressiva de nós de
saída com a flag BadExit. Geralmente esses nós são denunciados por usuários que,
de alguma forma, perceberam alteração na conexão normal ou receberam alertas de
certificados falsos no navegador WEB.
2.8 Proxychains
Como foi mostrado no tópico x, proxychains é um programa capaz de
redirecionar qualquer conexão TCP através de um proxy. Por default, o proxychains é
51
configurado para ser utilizado com a rede TOR, conforme a figura abaixo:
Figura 25: utilização do ProxyChains
Fonte: autor
Nota-se na figura 25, que o serviço de tunelamento TOR deve estar ativo para
utilização do proxychains, cujo arquivo de configuração localiza-se em
“/etc/proxychains.conf”. No exemplo acima, o proxychains é utilizado para realizar uma
conexão Secure Shell (SSH) de forma anônima, através da rede TOR.
52
3 ATAQUE MITM
Segundo Malenkovich:
O objetivo da maioria dos hackers, independente de seus negócios, é roubar informação do usuário. Seja através de ataques discretos e individuais ou em grande escala por meio de sites populares e bancos de informação financeira. Quase sempre os invasores começam tentando inserir algum vírus na máquina do usuário para depois percorrer um curto caminho até você e sua informação. Se por alguma razão este plano der errado, eles poderão utilizar-se de outro ataque popular conhecido como man-in-the-middle. Como o próprio nome sugere, nesta modalidade o hacker coloca suas armadilhas entre a vítima e sites relevantes, como sites de bancos e contas de e-mail. Estes ataques são extremamente eficientes e difíceis de detectar, especialmente por usuários inexperientes ou desavisados. (Malenkovich, 2013).
Segundo a Wikipédia:
O man-in-the-middle (pt: Homem no meio, em referência ao atacante que intercepta os dados) é uma forma de ataque em que os dados trocados entre duas partes, por exemplo você e o seu banco, são de alguma forma interceptados, registrados e possivelmente alterados pelo atacante sem que as vitimas se apercebam.[1] Numa comunicação normal os dois elementos envolvidos comunicam entre si sem interferências através de um meio, aqui para o que nos interessa, uma rede local à Internet ou ambas. (WIKIPÉDIA, 2016).
Contextualizando com a rede TOR, o próprio nó de saída se torna o atacante do ataque MITM, uma vez que possui a capacidade de analisar todo o tráfego das conexões realizadas com os diversos destinos finais, conforme a figura abaixo:
Figura 26: Ataque MITM
Fonte: autor
Segundo a figura 26, observa-se que o Exit realiza uma conexão TCP com o servidor e recebe a resposta. Caso não haja alguma forma de checagem dos dados fim-a-fim, o nó de saída poderá alterar esse fluxo de dados, bem como capturar
eventuais logins e senha realizados sem criptografia.
53
4 BITCOIN
Segundo a Wikipédia:
Bitcoin (símbolo: ฿; abrev: BTC ou XBT) é uma criptomoeda e sistema de pagamento online baseado em protocolo de código aberto que é independente de qualquer autoridade central.[2] Um bitcoin pode ser transferido por um computador ou smartphone sem recurso a uma instituição financeira intermediária.[3] O conceito foi introduzido em 2008 num white paper publicado por um grupo com o pseudônimo de Satoshi Nakamoto que o chamou de sistema eletrônico de pagamento peer to peer. (WIKIPÉDIA, 2016).
Ressalta ainda que:
O nome Bitcoin também se refere ao software de código aberto que o grupo projetou para o uso da moeda e a respectiva rede peer-to-peer. Diferente da maioria das moedas, bitcoin não depende da confiança em nenhum emissor centralizado ou uma instituição financeira. Bitcoin usa um banco de dados distribuídos espalhados pelos nós da rede peer-to-peer para registrar as transações, e usa criptografia de código aberto para prover funções básicas de segurança, como certificar que bitcoins só podem ser gastas pelo dono e evitar gastos duplos e falsificação. (WIKIPÉDIA, 2016).
Como a transferência de bitcoins ocorre em uma rede peer-to-peer fechada,
não existe um órgão central capaz de armazenar logs sobre todas as operações da
rede. Porém, cada transferência da rede armazena os endereços IP de origem e de
destino. (https://pt.wikipedia.org/wiki/Bitcoin, 2016).
Para dissimular o IP real utilizado na internet, foram desenvolvidas carteiras
bitcoin que utilizam a rede TOR para realizar as transações. Uma carteira que se
destaca para esse fim é a Electrum, conforme a figura a seguir:
Figura 27: Electrum
Fonte: autor
54
Conforme a figura 27, é necessário que o tunelamento TOR esteja aberto para
que a carteira Electrum consiga se conectar na rede. Esse procedimento irá registrar
o endereço do nó de saída nas transferências realizadas.
Para dificultar o rastreamento das transferências, é recomendado que se utilize
o Bitmixer em conjunto com a rede TOR, conforme a figura a seguir:
Figura 28: Bitmixer
Fonte: https://bitmixer.io/how.html
Conforme a figura 28, ao tranferir um montante para o Bitmixer, este possui a
capacidade de pulverizar de pulverizar o valor transferido em pedaços menores a fim
de enviá-los para o destino final. Para que isso seja possível, o Bitmixer detém uma
grande quantidade de Bitcoins. (https://bitmixer.io/how.html, 2016).
55
5 APRESENTAÇÃO E DISCUSSÃO DOS RESULTADOS
Analisando os aspectos que envolvem o presente trabalho e buscando
solucionar o problema proposto, tem-se como premissa básica a confiança de que os
serviços utilizados cumpram o que estabelecem em relação a não armazenagem de
logs, sejam em termos da rede TOR, da carteira bitcoin Electrum, do serviço de
transferência Bitmixer e do VPS contrato. Sem essa premissa, toda pesquisa realizada
para promover o anonimato seria invalidada.
A consideração realizada no parágrafo anterior é válida na medida em que um
provedor de redes virtuais privadas (VPN) que afirmava não guardar logs - cujo site é
“https://www.hidemyass.com/pt/” - resolveu entregar informações ao Federal Bureau
of Investigation (FBI) em uma operação contra hackers que atacaram a empresa
“Sony Corporation” (Andre, 2016). Dessa forma, não há garantias de que logs não são
armazenados pelos serviços utilizados nesse trabalho.
Através das capturas realizadas com o programa tcpdump no nó de saída
configurado, foi possível observar o tráfego ao acessar o site
“http://www.pudim.com.br”, conforme a figura abaixo:
Figura 29: Teste "http://www.pudim.com.br"
Fonte: autor
Conforme a figura 29, observa-se que o endereço de origem, 185.86.148.206,
é do nó de saída, bem como o endereço de destino é do site
“http://www.pudim.com.br” utilizado nos testes. Ainda, verifica-se que a requisição
está em claro, o que possibilita tanto a visualização, como a alteração de seu
conteúdo.
56
Seguindo o mesmo método do exemplo anterior, foi acessado o site
“http://www.webs.com/s/login/relogin” utilizando um login e uma senha falsas,
conforme a figura a seguir:
Figura 30: Teste "http://www.webs.com/s/login/relogin"
Fonte: autor
Observa-se na figura 30, que, mesmo com o método POST de envio, o tcpdump
conseguiu capturar o login e a senha sem dificuldades. A facilidade para interceptar
esses dados se deve ao fato de o protocolo HTTP não utilizar criptografia.
Assim, com base nos dados apresentados, fica evidente que possuir um nó de
saída, utilizando-o no acesso à rede TOR, é a única forma de garantir que o fluxo de
dados não será interceptado ou modificado, partindo da premissa que o usuário possui
controle sobre o nó que configurou.
Portanto, a primeira hipótese levantada é confirmada, uma vez que é válido a
criação de um nó de saída institucional na rede TOR a fim de evitar ataques MITM.
Porém, é importante ressaltar a premissa de que os diversos serviços utilizados para
anonimato irão cumprir o compromisso de não armazenagem de logs.
57
6 CONCLUSÕES E RECOMENDAÇÕES
Após os estudos realizados sobre cada parte que envolve o tema tratado,
desde o entendimento detalhado do funcionamento da rede TOR, passando pela
criação de um nó de saída real, com noções de ataques man-in-the-middle e da
criptomoeda Bitcoin, conclui-se que é válido a criação de um nó de saída institucional
na rede TOR a fim de evitar ataques MITM. Porém, é importante ressaltar a premissa
de que os diversos serviços utilizados para anonimato irão cumprir o compromisso de
não armazenagem de logs.
Devido ao método de análise adotado, por meio de captura de tráfego HTTP,
houveram limitações quanto a eficiência dos ataques MITM em fluxos de dados
criptografados, como o HTTPS. Assim, conclui-se que as análises não se esgotam
com o presente trabalho.
Para futuros estudos, sugere-se o emprego do software SSLStrip para realizar
ataques MITM em conexões criptografadas fim-a-fim, bem como a alteração do fluxo
de dados no nó de saída com a finalidade de desanonimizar um usuário da rede TOR.
58
REFERÊNCIAS
Andre. (02 de MARÇO de 2016). What Everybody Ought to Know About HideMyAss.
Fonte: https://invisibler.com/lulzsec-and-hidemyass/
Çalışkan, E., Tomáš Minárik, & Anna-Maria Osula. (2015). Technical and Legal Overview of the. NATO Cooperative Cyber Defence Centre of Excellence.
DEFESA, M. D. (21 de DEZEMBRO de 2012). POLÍTICA CIBERNÉTICA DE DEFESA. PORTARIA NORMATIVA No 3.389 /MD, DE 21 DE DEZEMBRO DE 2012. BRASIL.
DEFESA, M. D. (18 de NOVEMBRO de 2014). DOUTRINA MILITAR DE DEFESA CIBERNÉTICA. PORTARIA NORMATIVA No 3.010/MD, DE 18 DE NOVEMBRO DE 2014. BRASIL.
Dingledine, R. (07 de JUNHO de 2016). Tor bridges specification. Tor bridges specification.
Dingledine, R. (07 de JUNHO de 2016). Tor directory protocol, version 3. Tor directory protocol, version 3.
Dingledine, R. (07 de JUNHO de 2016). Tor Rendezvous Specification. Tor Rendezvous Specification.
Dingledine, R., & Nick Mathewson. (07 de JUNHO de 2016). Tor Path Specification. Tor Path Specification.
Dingledine, R., & Nick Mathewson. (07 de JUNHO de 2016). Tor Protocol Specification. Tor Protocol Specification.
https://bitmixer.io/how.html. (17 de JULHO de 2016). Fonte: https://bitmixer.io/how.html
https://play.google.com/store/apps/details?id=info.guardianproject.orfox&hl=pt_BRhttps://play.google.com/store/apps/details?id=info.guardianproject.orfox&hl=pt_BR. (17 de JULHO de 2016). Fonte: https://play.google.com/store/apps/details?id=info.guardianproject.orfox&hl=pt_BR
https://pt.wikipedia.org. (17 de JULHO de 2016). Fonte: https://pt.wikipedia.org/wiki/Servidor_virtual_privado
https://pt.wikipedia.org/wiki/Ataque_man-in-the-middle. (17 de JULHO de 2016). Fonte: https://pt.wikipedia.org/wiki/Ataque_man-in-the-middle
https://pt.wikipedia.org/wiki/Bitcoin. (17 de JULHO de 2016). Fonte: https://pt.wikipedia.org/wiki/Bitcoin
https://tails.boum.org/index.en.html. (07 de JUNHO de 2016). Fonte: https://tails.boum.org/doc/about/features/index.en.html
59
https://torstatus.blutmagie.de/. (17 de JULHO de 2016). Fonte: https://torstatus.blutmagie.de/
https://www.qubes-os.org/tour/. (17 de JULHO de 2016). Fonte: https://www.qubes-os.org/tour/
https://www.whonix.org/wiki/Main_Page. (07 de JUNHO de 2016). Fonte: https://www.whonix.org/wiki/Main_Page
Loshin, P. (2013). Practical Anonymity. SYNGRESS.
Malenkovich, S. (10 de ABRIL de 2013). Fonte: https://blog.kaspersky.com.br/what-is-a-man-in-the-middle-attack/462/
Murdoch, S. J. (07 de NOVEMBRO de 2011). p. 15.
Niederhagen, R. (16 de JUNHO de 2014). The Tor Network.
Perry, M., Erinn Clark, & Steven Murdoch. (2015). The Design and Implementation of the Tor Browser [DRAFT].
Roger Dingledine, Nick Mathewson, Steven Murdoch, & Paul Syverson. (2014). Tor: The Second-Generation Onion Router (2014 DRAFT v1). TOR Project.
SILVA, W. (13 de JUNHO de 2016). ANONIMIZAÇÃO E DESANONIMIZAÇÃO. BRASIL.
SYVERSON, P. (04 de JULHO de 2016). ONION-ROUTERonion-router. Fonte: https://www.onion-router.net/History.html
WIKIPÉDIA. (04 de JULHO de 2016). WIKIPÉDIA. Fonte: WIKIPÉDIA: https://en.wikipedia.org/wiki/Operation_Onymous
WIKIPÉDIA. (04 de JULHO de 2016). WIKIPÉDIA. Fonte: https://en.wikipedia.org/wiki/Tor_(anonymity_network)