1º Ten Com VICTOR TORRES KUMM EFICÁCIA DA UTILIZAÇÃO...

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




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




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


_____________________________________________________

FELIPE RODRIGUES DE VASCONCELLOS – Cap Com Membro


_________________________________________________

VINICIUS LUIS PALUDETO – 1º Ten Com Membro


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:

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:

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;



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:

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


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


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)

1º Ten Com VICTOR TORRES KUMM EFICÁCIA DA UTILIZAÇÃO...

Documents

Transcript of 1º Ten Com VICTOR TORRES KUMM EFICÁCIA DA UTILIZAÇÃO...