Navegação segura - análise do uso de HTTPS na perspectiva do utilizador final

Universidade do Minho Escola de Engenharia Carlos Eduardo Ribeiro Machado Navegação Segura - Análise do Uso de HTTPS na Perspectiva do Utilizador Final julho de 2020 UMinho | 2020 Carlos Eduardo Ribeiro Machado Navegação Segura - Análise do Uso de HTTPS na Perspectiva do Utilizador Final Carlos Eduardo Ribeiro Machado Navegação Segura - Análise do Uso de HTTPS na Perspectiva do Utilizador Final Dissertação de Mestrado Mestrado em Engenharia de Redes e Serviços Telemáticos Diretório de Informática Trabalho efetuado sob a orientação do Professora Doutora Solange Rito Lima Professor Doutor Paulo Martins Carvalho Universidade do Minho Escola de Engenharia julho de 2020 Direitos do Autor e Condições de Utilização do Trabalho Por Terceiros Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho i ii Abstract The Internet emerged in the late sixties in a scenario marked by the race of world hegemony between USA and USSR. Besides military applications, it was also initially used by researchers, academics, and college students, enabling file transfer between hosts. After the nineties the Internet reached the general public. It was then focused on other purposes, such as access to hypermedia, social networks, advertising and even products sale. Given the diversification of these accesses, the adoption of protocols for safe browsing has become essential to protect user’s information. Combined with the classification of encrypted traffic, using appropriate techniques for this purpose, this paper aims to analyze the use of HTTPS protocol in various browsing scenarios once considered safe. Through testing scenarios, this research intends to verify changes and impacts that this protocol promotes regarding the data collection from the users during the Internet access experience. Keywords: HTTPS, User, Web security. iii iv Resumo A Internet surgiu no final da década de sessenta em um cenário marcado pela disputa da hegemonia mundial entre EUA e URSS. Além de aplicações militares, ela foi utilizada inicialmente por pesquisadores, académicos e estudante universitários, possibilitando a transferência de arquivos entre hospedeiros. A partir da década de noventa a Internet chegou ao grande público. Passou, então, a ser utilizada para outros propósitos, como o acesso a hipermídias, redes sociais, publicidade e até venda de produtos. Diante da diversificação desses acessos, a adoção de protocolos para navegação segura tornouse essencial para proteção das informações dos utilizadores. Aliado à classificação de tráfego encriptado, utilizando técnicas apropriadas para o efeito, este trabalho tem por objetivo analisar o uso do protocolo HTTPS em vários cenários de navegação considerados seguros. Através de cenários de teste, pretende-se verificar mudanças e impactos que este protocolo repercute quanto à exposição de dados na experiência de acesso à Internet de um utilizador final. Palavras-Chave: HTTPS, Utilizador, Segurança na Web. v vi CONTEÚDO 3.5 CritériosdeAvaliação .................................. 34 3.6 Resumo dos Trabalhos Selecionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.7 Sumário.......................................... 41 4 Metodologia 43 4.1 AmbienteExperimental ................................. 43 4.1.1 Infraestrutura................................... 44 4.1.2 Ferramentas de Captura e Teste . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.3 Preparação dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.1.4 Programação dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1.5 ProcessodeMedição............................... 52 4.1.6 Características dos Navegadores . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.1.7 Características dos Motores de Busca . . . . . . . . . . . . . . . . . . . . . . 55 4.1.8 Reprodutibilidade ................................ 57 4.2 Extração das Informações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2.1 Tratamento e Classificação dos Dados . . . . . . . . . . . . . . . . . . . . . 62 4.3 Sumário.......................................... 64 5 Cenários de Testes e Resultados 65 5.1 ObjetivodosTestes.................................... 65 5.1.1 Taxonomia dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.2 AnálisedosResultados.................................. 68 5.2.1 ConexõesTCP .................................. 68 5.2.2 ConexõesSSL/TLS................................ 71 5.2.3 Cookies ...................................... 74 5.2.4 HTTPeHTTPS ................................. 77 5.2.5 Comportamento dos Navegadores . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2.6 MotoresdeBusca................................. 82 5.3 SíntesedosResultados.................................. 85 xiii CONTEÚDO 5.4 Sumário.......................................... 87 6 Conclusões 89 6.1 Resumo do Trabalho Desenvolvido . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.2 TrabalhosFuturos .................................... 90 Apêndices 93 A TSTAT 95 A.1 CoreTCPSet....................................... 95 A.2 TCPLayer7Set ..................................... 96 A.3 Coluna 42 - Protocolos Identificados . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.4 LogHTTPComplete .................................. 97 B Scripts 99 B.1 RobotFramework..................................... 99 B.2 ScriptXubuntu18.04...................................100 B.3 SriptWindows10.....................................101 Bibliografia 103 xiv Lista de Figuras 2.1 Interação cliente-servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Mensagens de requisição e resposta do HTTP. . . . . . . . . . . . . . . . . . . . . . 18 2.3 ServidorcacheWeb. ................................... 19 2.4 SessãoSSL. ........................................ 23 2.5 SessãoTLS......................................... 24 2.6 Exemplo de navegador a utilizar HTTPS. . . . . . . . . . . . . . . . . . . . . . . . 25 2.7 Diferença entre HTTP e HTTPS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1 MetodologiaSLR. .................................... 30 4.1 Processo de automação dos testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2 Topologiadetestes..................................... 52 4.3 Fluxograma de utilização das ferramentas. . . . . . . . . . . . . . . . . . . . . . . . 63 4.4 Fluxograma de tratamento dos dados. . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1 Tempo médio dos traces realizados por navegador. . . . . . . . . . . . . . . . . . . 66 5.2 Percentual de conexões TCP no Linux e Windows. . . . . . . . . . . . . . . . . . . 68 5.3 Percentual de Tráfego IPv4 e IPv6 nos sistemas operativos Linux e Windows. . . . 69 5.4 Quantidade de pacotes do protocolo SSDP presentes no Linux e Windows. . . . . . 70 5.5 Quantidades de portas visíveis por navegador. . . . . . . . . . . . . . . . . . . . . . 71 5.6 Percentual do tráfego SSL/TLS e fluxos bem-sucedidos por cenário. . . . . . . . . . 72 5.7 Percentual do versão SSL/TLS no lado do Servidor e do Cliente. . . . . . . . . . . 72 xv LISTA DE FIGURAS 5.8 Percentual do protocolo HTTP/1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 5.9 Percentual de Utilização HTTP e HTTPS no Linux e Windows. . . . . . . . . . . . 79 5.10 Requisição de Resposta HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 5.11 Tamanho médio do tráfego por Navegador. . . . . . . . . . . . . . . . . . . . . . . . 81 5.12 Informações dos navegadores no Linux e no Windows. . . . . . . . . . . . . . . . . 82 5.13 Percentual de redirecionamento para URLs seguras dos motores de busca no Linux enoWindows. ...................................... 83 5.14 Médias das palavras pesquisadas nos dois cenários. . . . . . . . . . . . . . . . . . . 84 A.1 SaídasCoreTCPSet. .................................. 95 A.2 SaídasTCPLayer7Set.................................. 96 A.3 Lista de protocolos de aplicação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.4 Saídas Log_HTTP_Complete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 xvi Lista de Tabelas 2.1 Códigos e mensagens HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Termos de busca e principais sinónimos. . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Fontesdepesquisas. ................................... 33 3.3 Artigos encontrados e selecionados em cada fonte de pesquisa. . . . . . . . . . . . . 35 3.4 Artigosselecionados.................................... 37 4.1 Termos da política de privacidade dos navegadores. . . . . . . . . . . . . . . . . . . 55 4.2 Termos da política de privacidade dos motores de busca. . . . . . . . . . . . . . . . 56 5.1 Taxonomiadostestes. .................................. 67 5.2 Interações SSL/TLS - Google Chrome. . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.3 Tempo de validade dos certificados digitais por endereço eletrônico acessado. . . . . 74 5.4 Tipo de cookies encontrados por endereço eletrônico. . . . . . . . . . . . . . . . . . 77 5.5 Percentual de cookies por tempo de validade. . . . . . . . . . . . . . . . . . . . . . 78 5.6 Configurações iniciais dos navegadores. . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.7 Cabeçalhos de resposta HTTPS por navegador. . . . . . . . . . . . . . . . . . . . . 82 5.8 Resumo dos dados analisados dos navegadores. . . . . . . . . . . . . . . . . . . . . 86 5.9 Resumo dos dados analisados dos motores de busca. . . . . . . . . . . . . . . . . . 87 xvii LISTA DE TABELAS xviii Lista de Abreviaturas e Siglas ACM Association for Computing Machinery Digital Library ARPA Advanced Research Projects Agency ARPANET Advanced Research Projects Agency Network ASCII American Standard Code for Information Interchange CA Certification Authority CAIDA Center for Applied Internet Data Analysis CAPES Coordenação de Aperfeiçoamento de Pessoal de Nível Superior CERN Conseil Européen pour la Recherche Nucléaire CORE Computing Research and Education Association of Australasia DNS Domain Name System DOD Departament of Defense DoS Denial of Service DPI Deep Packet Inspection FTP File Transfer Protocol HRU Harrison, Ruzzo, Ullman mode HTML Hypertext Makeup Languge HTTP Hypertext Terminal Protocol HTTPS Hypertext Transfer Protocol Secure IANA Internet Assigned Numbers Authority IDE Integrated Development Environment xix LISTA DE ABREVIATURAS E SIGLAS IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force IMP Interface Message Processors IP Internet Protocol IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ISP Internet Service Providers kbps kilobits por segundo LAN LocalArea Network LPI Lightweight Packet Inspection MAC Message Authentication Code MILNET Military Network MIT Massachusetts Institute of Technology MPLS Multiprotocol Label Switching NCSA National Center for Supercomputing Applications NPC Network Control Protocol NSA Nacional Security Agency NSF National Science Foundation NSFNET National Science Foundation Network PPPoE Point–to–Point Protocol over Ethernet QUIC Quick UDP Internet Connections RFC Request for Comments RGPD Regulamentação Geral da Proteção de Dados RMON Remote Network Monitoring RTT Round Trip Time SLR Systematic Literature Review SMNP Simple Network Management Protocol SMTP Simple Mail Transfer Protocol xx LISTA DE ABREVIATURAS E SIGLAS SNMP SimpleNetwork Management Protocol SSL Secure Sockets Layer TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol URL Uniform Resource Locator VLAN Virtual Local Area Network WAN Wide Area Network WWW World Wide Web xxi LISTA DE ABREVIATURAS E SIGLAS xxii 2.2. ORIGEM E DESENVOLVIMENTO DA INTERNET A NSFNET teria como objetivo ser aberta a todos os centros de pesquisa universitários espalhados pelo país. A partir de então, construiu sua própria rede de backbone a interligar seis centros de supercomputadores. Cada supercomputador era ligado a um microcomputador, que por sua vez era conectado a linhas dedicadas de 56kbps, a formar uma sub-rede com tecnologia física proveniente da ARPANET e tecnologia lógica para comunicação com o propósito de utilizar o sistema de protocolos TCP/IP como padrão [3]. Com o financiamento de diversas redes, a NSF inseriu diversas universidades, museus, laboratórios de pesquisa e bibliotecas em sua rede com alta taxa de transferência de dados. A comunicação entre todos esses locais se dava através de ligação a um dos seus supercomputadores. A NSFNET fez sucesso rapidamente, mas logo se sobrecarregou devido à baixa capacidade de sua rede. Dessa forma, foi aberto espaço para diversas empresas investirem em capacidades maiores para a rede com uma única infra-estrutura que fosse competitiva e tivesse fins lucrativos. Na década 80, o TCP/IP passou a ser a pilha protocolar padrão e as redes NSFNET e ARPANET sem fins militares foram interligadas e veio a criar o que hoje é conhecido como Internet. Essa interligação teve um grande crescimento e foram criadas conexões entre diversos lugares no mundo. Apenas na década de 90 a Internet deixou de ser voltada apenas para pesquisas e passou a ter um perfil comercial. Isso só foi possível devido a criação da aplicação Rede de Alcance Mundial (WWW - World Wide Web), desenvolvida por Tim Berners-Lee, um físico da Organização Européia para a Investigação Nuclear (CERN - Conseil Européen pour la Recherche Nucléaire). Ele também foi responsável pela criação do primeiro navegador de Internet (Web Browser) que consiste em um programa que permite interação entre utilizadores e documentos eletrónicos por meio do protocolo HTTP, descrito na Sessão 2.5.1. A Web facilitou a inserção dos recursos da rede devido ao pioneirismo na aplicação de hipertexto para compartilhamento de recursos de informação. Ela foi introduzida em primeiro momento no CERN e, a princípio, disponibilizava informações através de textos. Somente após a associação da WWW com o Mosaic a Internet veio a entrar em popularidade. O Mosaic foi o primeiro navegador gráfico desenvolvido em 1993 por Marc Andressen no Centro Nacional de Aplicações de Supercomputação (NCSA – National Center for Supercomputing Applications). Junto com a Web tornou-se possível a configuração de páginas a conter textos, figuras, sons e até vídeos. Com isso diversos tipos de páginas foram criadas com os mais diversos tipos de conteúdo, como mapas, catálogos, indicadores financeiros, programas de rádios, etc. Com a chegada do século XXI a infraestrutura das redes se tornou presente em todos os lugares e com isso qualquer conteúdo ou serviço passou a estar disponível eletronicamente. Como exemplo, tem-se votação eletrónicas, comércio eletrónico, governo eletrónico e tantas outras aplicações passadas para vias digitais. Os computadores pessoais perderam espaço para dispositivos de mobilidade [13]. 7 CAPÍTULO 2. ESTADO DA ARTE Fora a criação de navegadores gráficos, outro fator que foi fundamental para o expansão da Internet foi a criação de Provedores de Serviços de Internet (ISP – Internet Service Providers). Estas empresas oferecem aos utilizadores individuais acesso a Internet provendo diversos serviços agregados como e-mail e acesso à Web. Na década de 90, elas reuniram milhões de utilizadores a alterar todo o propósito da Internet, que passou de uma rede acadêmica de pesquisa e de proteção de informações militares, para um serviço de utilidade pública em todo o mundo. Atualmente pode ser acessada de qualquer lugar, a qualquer momento e quando o utilizador desejar em face aos serviços oferecidos [4]. O desenvolvimento nos últimos anos deixou a rede mundial de computadores acessível para praticamente todas as classes sociais. A influência de diversas culturas a tornou uma ferramenta de comunicação em massa. 2.3 Segurança da Internet Durante o período inicial de utilização da ARPANET, a segurança da informação a ser transmitida não era prioridade. Isso porque o acesso era realizado em computadores de grande porte, mais conhecidos como mainframes, em ambientes restritos, controlados e com poucos utilizadores. A troca de mensagens por correio eletrónico e pesquisas computacionais foram as principais finalidades da rede. Porém, entre as décadas de 60 e 70, utilizadores começaram a acessar informações de forma remota. Esse tipo acesso introduziu um novo risco aos dados mantidos remotamente, pois esses mesmos dados poderiam ser acessados por qualquer pessoa, autorizada ou não. O acesso físico aos terminais era supervisionado por um responsável de segurança que iniciava o processo de identificação e autenticação de cada utilizador. Como haviam poucos terminais, o processo de acompanhamento de utilização e atividades era simples. O fato de não existir políticas de segurança para aplicação de senhas de acesso mais elaboradas fez com que a quebra de sigilo e o compartilhamento de senhas entre os utilizadores se tornasse uma grande ameaça. Com o conceito de multi-utilizador e sistemas de compartilhamento inseridos pela implantação de computadores pessoais, as redes de computadores de fato começam a existir. Assim, ocorre o surgimento dos controles de acesso para os utilizadores terem espaços de trabalhos independentes uns dos outros e sem nenhum tipo de interferência. O modelo de segurança HRU (Harrison, Ruzzo, Ullman mode) [5] é um dos trabalhos pioneiros que atuavam a nível de sistema operacional e com a integridade dos direitos de acesso no sistema. Outros trabalhos que se destacam são: o modelo de confidencialidade Bell-LaPaluda, descrito como 8 2.3. SEGURANÇA DA INTERNET uma máquina de estados finitos e foi desenvolvido para aplicar controle de acesso a informação [6], e o modelo Diffie-Hellman introduz o conceito de assinaturas digitais. Esse modelo por sua vez, estabelece um compartilhamento de chaves secreto que pode ser usado para troca de mensagens secretas dentro de um canal de comunicação público e inseguro [7]. Na década de 80, a utilização de computadores pessoais se intensifica e as primeiras aparições de vírus2são registradas. Em 1988 houve o primeiro registro de um worm3, criado por Robert T. Morris Jr., que infectou em um curto período 10% dos computadores conectados a Internet. Dentre as redes afetadas, destacam-se as redes do Pentágono (sede do DoD dos Estados Unidos), da Agência Nacional de Segurança (NSA - Nacional Security Agency) e o Instituto de Tecnologia de Massachusetts (MIT - Massachusetts Institute of Technology). A principal funcionalidade desse worm era explorar as vulnerabilidades das conexões dos protocolos TCP e SNMP (Simple Network Management Protocol) de um sistema operacional Unix. Esse evento se tornou significativo porque gerou um alerta na comunidade sobre aspectos de segurança e a necessidade de investimento em formas de conter e evitar esses problemas. O debate sobre segurança foi intensificado e vários países desenvolveram leis de punição aos atacantes, bem como ferramentas de proteção. Assim, surge o conceito restrição de acesso as redes chamado de firewall. Essa aplicação foi desenvolvida para isolar a redes locais (LAN - Local Area Network) e metropolitanas (WAN - Wide Area Network) através de um filtro com políticas de segurança, no conjunto de protocolos TCP/IP, na medida em os pacotes são transmitidos e recebidos [8]. No mesmo período também foram desenvolvidos programas para combater os vírus, chamados de antivírus. O crescimento das LAN da WAN se intensificaram nos anos 90, período em que a Internet passa a ter milhares de utilizadores. Os ataques começaram a ser mais sofisticados e passaram a focar os pontos de acesso (gateways) entre os computadores e os servidores de conteúdo e serviços. No final da década são registrados os primeiros casos negação de serviço4(DoS - Denial of Service) e códigos maliciosos para roubo de informações dos utilizadores. Com a chegada do século XXI a infraestrutura das redes se tornou presente em todos os lugares e com isso qualquer conteúdo ou serviço passou a estar disponível eletronicamente. Como exemplo, tem-se votações eletrónicas, comércio eletrónico, governo eletrónico e tantas outras aplicações passadas para vias digitais. Os computadores pessoais perderam espaço para dispositivos móveis 2Programas criados para realizar modificações prejudiciais aos computadores de forma a danificar sistemas, corromper ou destruir dados. 3Semelhante ao vírus, mas com a funcionalidade de se replicar. Através dessa característica ele cria cópias operacionais e infecta outros computadores pela rede local, Internet ou anexos de mensagens eletrónicas. 4Forma de ataque que torna indisponível os recursos de um sistema para os seus utilizadores 9 CAPÍTULO 2. ESTADO DA ARTE (smartphones, notebooks, tablets, etc.) e a computação móvel através de conexões sem fio (Wi-Fi e Blueetooth) se popularizou. Os sistemas de pagamento em tempo real (on-line) com a utilização de cartões de crédito também se intensificaram. Em contrapartida, todo esse desenvolvimento também trouxe inúmeras vulnerabilidades de rede de forma a comprometer a integridade das informações [9]. A utilização de analisadores de tráfego para realizar interceptação das comunicações foi desenvolvida em larga escala para uma compreensão em detalhes, do funcionamento da comunicação entre os dispositivos na rede. Agora era possível reunir informações vitais de desempenho dos dispositivos, do comportamento da rede, de possíveis falhas de serviços, priorização do tráfego por serviços mais sensíveis, quais serviços mais utilizados em determinado período e quais dados estão a ser transmitidos. Esses dados compõem um conjunto de informações de alto valor. A convergência de diferentes conteúdos e serviços para o mundo digital fez com que a informação se transformasse em um ativo importante para o ambiente de negócios. Desta forma, é necessário que seja mantida em sigilo para preservar sua integridade e a privacidade de seus utilizadores. Em trabalhos como [10], fica claro a quantidade de informações que podem ser coletadas de uma rede e o quanto pode ser perigosa a exposição de todos esses dados. Sendo assim, a encriptação das informações passou a ser essencial para segurança das redes e seus utilizadores. Nos últimos anos a adoção de comunicação encriptada tem sido adotada em larga escala e cada vez mais a proteção dos dados tem sido uma temática tratada com muita atenção. 2.4 Arquitetura da Internet A popularização da rede mundial de computadores tornou o TCP/IP a pilha protocolar mais usado em redes locais. Em relação a outros modelos de protocolos, o TCP/IP, tem a vantagem de ser roteável, ou seja, foi criado para redes de grandes e de longas distâncias, onde há vários caminhos para a informação atingir o seu destino [11]. Por possuir uma arquitetura aberta, o TCP/IP, pode ser modificado ou adaptado por qualquer fabricante. Por essa característica tornou-se um protocolo universal a dar possibilidade de interagir diversos sistemas sem problemas de comunicação. Como mencionado anteriormente, o TCP/IP é formado por um conjunto de protocolos mais importantes, sendo um o TCP que tem função de transporte confiável fim-a-fim de mensagens de dados entre dois sistemas, o outro é o IP que é responsável pelo encaminhamento de pacotes de dados entre diversas sub-redes desde a origem até o destino [4]. O modelo TCP/IP foi decomposto em vários módulos que realizam tarefas específicas. As tarefas são realizadas em uma ordem precisa, sendo considerado um sistema estratificado, podendo ser dividido em camadas [12]. As 10 2.4. ARQUITETURA DA INTERNET camadas desse modelo referencial são: •camada de acesso à rede ou física; •camada de rede; •camada de transporte; •camada de aplicação. 2.4.1 Camada de Acesso à Rede ou Física É a primeira camada da pilha de protocolos e corresponde ao meio físico, ou seja, aos dispositivos (hardwares) envolvidos na comunicação entre as redes, onde os dados são tratados como pulsos elétricos. Tem como principal função a interligação do modelo TCP/IP com diversos tipos de redes e é responsável por enviar e receber dados em forma de pacotes, contendo endereço de origem, dados e o endereço de destino. Por existir uma grande variedade de tecnologias de rede a utilizar diversas velocidades, protocolos e meios de transmissão, a camada de acesso a rede não tem normatização que possibilita interconexões e inter-operações de redes heterogêneas [11]. Também é conhecida como a camada de enlace (datalink layer) devido a se encarregar do envio dos dados recebidos da camada de rede em forma de quadros através dos dispositivos da rede. 2.4.2 Camada de Rede A camada de Rede é responsável pelo roteamento dos dados, endereçamento dos equipamentos na rede e é definida pelo protocolo IP [11]. Todo dispositivo de rede possui um endereço lógico atribuído a um número, denominado de endereço IP, que é associado a uma ou várias interface de um equipamento ou terminal (host) a identificar a rede e o próprio equipamento nessa rede. A principal função do protocolo de interconexão é fazer a transferência de blocos de dados, chamados de datagramas (frame). Baseia-se em um serviço sem conexão, ou seja, faz apenas o roteamento dos dados pela rede e não faz nenhum tipo de verificação de erros durante a transferência. Por causa desse serviço sem conexão, cada datagrama é considerado como uma unidade independente e tem comunicação não confiável, pois não utiliza nenhuma forma de reconhecimento fim-a-fim ou entre nós intermediários [3]. Também não existem mecanismos para controle de fluxo e de erros. Ocorre apenas uma simples conferência do cabeçalho para garantir que as informações contidas no mesmo sejam encaminhadas corretamente por gateways. Em uma arquitetura Internet TCP/IP é através do endereço IP que as estações conseguem enviar e receber mensagens pela rede. 11 CAPÍTULO 2. ESTADO DA ARTE 2.4.3 Camada de Transporte Esta camada está situada entre a camada de rede e a camada de aplicação e é responsável por receber os dados enviados pela camada de aplicação, que será vista no próximo tópico, e transformá-los em pacotes a serem repassados para a camada de rede através de um canal lógico de comunicação fim-a-fim. A arquitetura na camada de transporte baseia-se em um serviço de transporte orientado à conexão para garantir a entrega dos dados na ordem certa, fornecido pelo protocolo TCP. Mas também baseia-se em serviço de datagrama não orientado à conexão fornecido pelo protocolo UDP (User Datagram Protocol). O protocolo TCP segmenta um fluxo de dados e os numera em determinada sequência que permita sua remontagem quando chegar ao destino. Antes de fazer uma transmissão o protocolo de uma estação de origem faz contato com o protocolo da estação de destino e estabelece uma conexão, que leva o nome de circuito virtual. Essa comunicação é chamada de orientada à conexão e precisa de uma confirmação do destinatário para ocorrer à troca de informações de maneira confiável [11]. O processo de confirmações é mantido durante todo o período em que a conexão ocorrer. Quando o envio dos segmentos termina, o protocolo TCP aguarda confirmação da estação de destino para finalizar a transmissão. Caso algum segmento não seja devidamente confirmado ele é retransmitido. Sendo assim, o protocolo TCP, é um protocolo orientado à conexão e altamente confiável [12]. O protocolo UDP, ao invés de fluxo, recebe blocos de dados de outras camadas. Da mesma maneira que o protocolo TCP, faz a segmentação e numeração dos blocos para permitir a reconstrução da informação no destinatário. Os segmentos não são sequenciados após serem numerados, pois o protocolo não dá importância à ordem de envio dos mesmos. Dessa maneira não existe uma confirmação de recebimento pela estação de origem e o protocolo UDP é dito como não-confiável. Também é considerado como não-orientado à conexão, pois não estabelece um circuito virtual para transferência dos blocos de dados. De maneira resumida pode-se dizer que o protocolo TCP é utilizado para transporte de dados de maneira confiável e o UDP para transporte rápido e não confiável de dados [12]. Para comunicação com camadas superiores, os protocolos TPC e UDP, utilizam portas que servirão para registro lógico de diferentes sessões estabelecidas simultaneamente através da rede. Existem 65.536 portas e estas são numeradas de 0 a 65.535. Cada porta corresponde a um serviço distinto ou pode ser usada por um programa, a tornar possível que uma estação utilize serviços em todas essas portas a aplicar um único endereço IP válido. São definidas por documentos que fazem a descrição de padrões de protocolos de Internet denominados de requisições de mudança (RFC – Request for Comments) e são de responsabilidade da autoridade para atribuição de números de Internet (IANA - Internet Assigned Numbers Authority), organização mundial encarregada de 12 2.5. PROTOCOLOS DE COMUNICAÇÃO coordenar alguns dos principais elementos que mantêm a Internet em funcionamento. As portas reservadas de 0 a 1023 são para serviços mais conhecidos e utilizados como servidores de mensagens eletrónicas (porta 25), compartilhamento de arquivos (portas 20 e 21), etc. As portas maiores ou iguais que 1024 são usadas pelas camadas superiores para estabelecer conexões com dispositivos diversos a identificar a aplicação origem e destino de uma porta UDP ou TCP [12]. 2.4.4 Camada de Aplicação Camada responsável pela interação dos protocolos da camada de transporte e as aplicações que utilizam meios de comunicações de dados, ou seja, define os protocolos necessários para interligar as aplicações, fazer seu controle e as especificações dos dispositivos (interface) com o utilizador [11]. Esta camada não possui um padrão e cada aplicação possui seu próprio protocolo estabelecendo um padrão específico. Sendo assim, é formada pelos protocolos utilizados nas diversas aplicações do modelo TCP/IP. E ainda faz o endereçamento na rede através de portas de comunicações com a camada transporte, onde cada aplicação possui uma porta pré-definida, como já foi mencionado na tópico anterior. Alguns exemplos de protocolos dessa camada são: •FTP - File Transfer Protocol: protocolo para serviços de transferências de arquivos; •SMTP - Simple Mail Transfer Protocol: protocolo utilizado por servidores de mensagens para seu gerenciamento e distribuição; •HTTP - HyperText TransPort Protocol: disponibiliza um dispositivo, normalmente um navegador, para visualização de páginas na Internet. Sendo implementado por um serviço Web; •DNS - Domain Name System: protocolo que mapeia nomes para endereços IPs. 2.5 Protocolos de Comunicação 2.5.1 HTTP É o protocolo de transferência mais empregado em toda Web e sua versão 1.1 é uma das mais utilizadas na Internet até os dias de hoje. É definido pelas RFCs 1945 e 2616 e utiliza formato de texto ASCII5(American Standard Code for Information Interchange) para comunicação. Esse 5Código apresentado por Robert W. Bemer como recurso de unificação para representação de caracteres alfanuméricos em computadores e se tornou a linguagem comum entre todos os dispositivos. 13 CAPÍTULO 2. ESTADO DA ARTE protocolo é executado por dois programas: um cliente, chamado de navegador Web (User Agent) e um servidor, chamado de servidor Web (Web Server). Os dois programas são executados em sistemas finais diferentes e conversam entre si por meio de troca de mensagens [3]. O HTTP determina a estrutura dessas mensagens e a forma como cliente e servidor interagem. Também é responsável pela forma que os clientes realizam a requisição das páginas aos servidores, que por sua vez, fazem a transferência aos clientes. O HTTP trabalha na camada de aplicação para transferência de páginas HTML (Hypertext Markup Languge), que é uma linguagem de programação utilizada para desenvolver páginas Web e proporciona a elaboração de documentos que podem ser acessados e transmitidos por qualquer dispositivo pela Internet. Cada página pode ser constituída de muitos objetos, como imagens, animações e vídeos. Cada objeto, para ser acessado, tem seu próprio endereço eletrónico denominado de URL (Uniform Resource Locator). Assim, quando um utilizador solicita uma página Web, o navegador encaminha ao servidor Web as mensagens de requisições HTTP para os objetos de cada página. O servidor recebe as requisições, as processa e responde com mensagens de resposta HTTP com os objetos que foram solicitados. Essa interação pode ser verificada na Figura 2.1. Figura 2.1: Interação cliente-servidor. 2.5.2 Conexões O HTTP utiliza o protocolo TCP para transporte de dados pela Internet. Assim, um navegador para estabelecer contato com o servidor, envia uma conexão TCP para o servidor através de uma porta de comunicação 80. O TCP é um protocolo orientado à conexão e ao fluxo, pois realiza a interconexão de sistemas e constrói uma conexão estável entre computadores remotos com a 14 2.5. PROTOCOLOS DE COMUNICAÇÃO confirmação de entrega das mensagens através da Internet. Com essas características, nem os navegadores e nem os servidores precisam ser responsabilizar com mensagens perdidas, duplicadas, longas ou qualquer tipo de confirmação. Também considera-se o HTTP como um protocolo sem estado (stateless), ou seja, cada solicitação realizada pelo cliente é independente. Isto significa que assim que o navegador encerra à conexão TCP, não existe registo de informação. Além de todas as requisições serem independentes, não possuem conhecimento uma das outras. Quando um cliente realiza um pedido de uma página web e recebe-o de volta existe um tempo para que essa solicitação ocorra. Esse tempo é chamado de RTT (Round Trip Time), que é o período que um pacote leva para ir do cliente ao servidor e de volta ao cliente. Em algumas situações o RTT pode incluir atrasos na transmissão dos pacotes por meio de dispositivos intermediários e em seu tempo de processamento. Diante desses casos, o HTTP pode adotar dois tipos de conexões: •conexões não persistentes: ao proceder uma transferência de um objeto entre o cliente e o servidor, à conexão TCP é fechada e não fica disponível para outros objetos da página Web. A cada solicitação é necessário um nova conexão TCP, que exige comunicação de três etapas (three-way handshake) devido à necessidade de reconhecimento entre cliente e servidor para comunicação real dos dados. Na primeira etapa o cliente envia uma mensagem com segmento TCP ao servidor. Em um segundo momento, o servidor reconhece o segmento e envia uma resposta ao cliente. Por último, o cliente confirma a resposta enviada pelo servidor e como à conexão TCP encontra-se pronta para o transporte de dados, também envia uma requisição HTTP para receber a página Web e os objetos solicitados. A depender da aplicação utilizada, esse tipo de conexão pode comprometer seu funcionamento com eventuais atrasos; •conexões persistentes: à conexão TCP fica ativa e disponível para envio de qualquer solicitação de objetos pelo cliente. A conexão se encerra após um período de tempo sem requisições. 2.5.3 Formatos de Mensagem HTTP As mensagens pode ser de dois tipos: requisição (request) e resposta (response). 15 CAPÍTULO 2. ESTADO DA ARTE Requisição Essa mensagem é dividida em três partes: linha de requisição, linha de cabeçalho e corpo da mensagem. A primeira parte é a linha de requisição que é o pedido que cliente faz ao servidor e possui os campos URL para localizar o endereço dos objetos solicitados, a versão do HTTP e o método. O método se refere a algum tipo ação que a mensagem demanda, como solicitar ou preencher informações, e é bastante utilizado em mensagens HTTP. Os métodos que podem ser operados são: •GET: requisita a leitura de uma recurso Web; •HEAD: regressa os cabeçalho de uma resposta; •POST: envio de recursos a uma página Web. •PUT: requisita armazenamento de uma página Web; •DELETE: remoção de recursos. •TRACE: verifica se todas as solicitações estão sendo processadas pelo servidor; •OPTIONS: forma de consulta do cliente sobre propriedades do servidor ou de objetos específicos; •CONNECT: facilita a comunicação entre servidores intermediários com recursos de comunicação segura; •PATCH: aplica alterações parciais de recursos. A segunda parte da mensagem corresponde às linhas de cabeçalho que possuem os detalhes das solicitações ao servidor. O cabeçalhos podem ser de três tipos: •gerais: contêm as informações sobre a própria mensagem e o servidor as utiliza para para controlar seu processamento e notificar o cliente com informações extras; •de requisição: além de dar controle ao cliente de como as requisições são processadas e fornecer informações mais detalhadas ao servidor, pode informar quais formatos ou códigos que o cliente pode verificar; •de entidade: se existir, descrevem de forma breve o conteúdo da mensagem. O corpo da mensagem é a terceira parte que constitui uma mensagem de requisição e trará uma entidade, que pode ser um arquivo de imagem, uma página Web ou qualquer outro objeto. 16 2.6. PROTOCOLOS DE COMUNICAÇÃO SEGURA Figura 2.4: Sessão SSL. 2.6.2 TLS Outro protocolo de segurança para promover privacidade e integridade das informações trocadas entre dois aplicativos de comunicação. Atualmente o TLS (Transport Layer Security) está na versão 1.3 proposta na RFC 8446, mas foi introduzido inicialmente em 1999 pelo IETF. O TLS é uma versão que propõe proteção a qualquer comunicação entre navegadores e servidores Web, como serviços de correio eletrónico, mensagens em tempo real e voz sobre IP (VoIP). O TLS é composto por duas camadas: Record Protocol eHandshake Protocol. A primeira camada é responsável por fornecer conexão privada através de criptografia simétrica, que utiliza algoritmos com a mesma chave de criptografia para encriptar o texto pleno e decriptar o texto cifrado. As chaves geradas nesse processo são exclusivas de cada conexão e se baseiam em um segredo negociado por outros protocolos, como o próprio TLS Handshake Protocol [17]. Outra responsabilidade da primeira camada é confiabilidade de conexão através de verificação de integridade das mensagens por códigos de autenticação (MAC - Message Authentication Code). 23 CAPÍTULO 2. ESTADO DA ARTE A segunda camada, Handshake Protocol, viabiliza a segurança da conexões através da autenticação por criptografia assimétrica, que opera com uma chave de criptografia secreta e outra pública. Esse processo pode ser opcional, mas em geral é necessário estar ativo em um dos lados da conexão. Um outra característica dessa camada é de não disponibilizar de nenhuma forma o segredo negociado entre dois dispositivos a fazer com que ele não seja interceptado. Dessa forma, como nenhum atacante pode pode modificar a comunicação de negociação sem ser detectado, à conexão com TLS é dita como confiável [17]. Por estar acima da camada de transporte, o TLS, trabalha de forma independente dos protocolos da camada de aplicação. Porém, é necessário que os desenvolvedores implementem segurança aos protocolos escolhidos para trabalhar em conjunto ao TLS. Porém, o processo de handshake do TLS é complexo e composto de uma grande quantidade de mensagens entre cliente e servidor, o que pode impactar o tráfego e o desempenho da rede. Figura 2.5: Sessão TLS. 2.6.3 HTTPS O HTTPS (Hypertext Transfer Protocol Secure) é a versão do protocolo HTTP com uma camada de segurança adicional que emprega os protocolos SSL/TLS e foi proposto na RFC 2818. O HTTPS, através da camada de segurança, permite que dados sejam enviados por uma conexão criptografada onde a autenticidade entre o cliente e servidor seja verificada por certificados digitais [4]. 24 2.6. PROTOCOLOS DE COMUNICAÇÃO SEGURA Os certificados digitais, por sua vez, são documentos eletrónicos que são aplicados para identificar um utilizador na Internet. Portanto, são considerados como identidade virtual e têm a finalidade de garantir a autenticidade, confidencialidade, integridade e segurança dos dados em qualquer operação realizada em ambiente virtual [16]. Cada utilizador é associado a um certificado de chave pública emitido por uma autoridade de certificação (CA - Certification Authority), que são instituições responsáveis pela emissão de certificados confiáveis. A finalidade do HTTPS é de impossibilitar que a informação transmitida seja interceptada por terceiros. Um utilizador pode identificar na barra de endereços, em seu navegador, a presença de um símbolo em forma de cadeado que constata que a página Web foi certificada como segura. Na Figura 2.5 é possível ver um exemplo no navegador Chrome de uma conexão segura HTTPS, onde a presença de um certificado representado por um cadeado fechado, constitui a relação de confiança entre o navegador e o servidor Web. Figura 2.6: Exemplo de navegador a utilizar HTTPS. Uma conexão HTTPS ocorre de forma simples: 1servidor envia chave pública juntamente com um certificado de validação da mesma para o utilizador; 2utilizador consulta a CA para verificar estado do certificado, se está válido ou revogado; 3se o certificado estiver válido, o navegador confia na chave pública e estabelece comunicação com o servidor Web de forma legítima; 4se o certificado estiver revogado, o navegador não conseguirá estabelecer comunicação com o servidor Web. Conforme mencionado anteriormente, o HTTPS só difere do HTTP pelo camada de segurança e não possui modificações nas funcionalidades gerais do protocolo. A Figura 2.6 demonstra a diferença entre a utilização dos protocolos HTTP e HTTPS. 25 CAPÍTULO 2. ESTADO DA ARTE Figura 2.7: Diferença entre HTTP e HTTPS. 2.7 Classificação do Tráfego de Rede A classificação do tráfego modificou a compreensão das redes de computadores, pois possibilitou mensurar diversas caraterísticas na procura de falhas e melhorias de desempenho. A evolução da Internet trouxe imensos desafios devido a muitas aplicações buscarem não serem detectadas, seja para proteção dos dados de seus utilizadores, seja para utilização de recursos de rede sem nenhum tipo de controle. Por outro lado, pesquisadores, operadores de redes e grandes ISPs necessitam dessas informações para conhecer as particularidades do tráfego, gerenciamento de recursos, segurança da informação e cobrança de utilização de serviços baseados no consumo. Essas duas visões de utilização da análise de tráfego proporcionou uma variedade de técnicas de classificação. 2.7.1 Técnicas de captura do tráfego Técnicas Router-Based Técnica baseada nas informações retiradas através das funções de um roteador (router). Muitas vezes pode ser uma aplicação como o Netflow, que é um recurso dos roteadores da fabricante Cisco e tem como finalidade coletar informações nas interfaces de entrada e saída de dados. Assim, administradores de rede são capazes de executar análises de origem e destino do tráfego, classe de serviços e possíveis causas de congestão. 26 2.7. CLASSIFICAÇÃO DO TRÁFEGO DE REDE Outra forma de retirar informações é através do protocolo SMNP (Simple Network Management Protocol) que é um protocolo de gestão de recursos para Internet. Adotado na camada de aplicação, foi concebido para ser um protocolo padrão implementado por todos os fornecedores e esta disponível na maioria dos dispositivos que se conectam a uma rede [4]. O SNMP fornece recolhimento de informações de todos os dispositivos conectados, onde pode se extrair informações vitais para a administração da rede. Também possui um ferramenta complementar a sua base de dados, chamada de RMON (Remote Network Monitoring), que se caracteriza como uma norma padrão para facilitar o monitoramento da rede através de dispositivos remotos. Além de apresentar métodos para configuração e controle da rede, possibilita a coleta de dados a partir de dispositivos de monitoramento. Técnicas Non Router-Based São técnicas baseadas em coletar informações diretamente dos sistemas através de dispositivos ou aplicações específicas. Pode ser de dois tipos: •medições ativas: realizada mediante a injeção de tráfego na rede. Isto é, insere tráfego de prova para para verificar o comportamento da rede em termos de conectividade, desempenho e disponibilidade de serviços oferecidos. É uma técnica que permite aos administradores de rede e pesquisadores realizarem testes mais específicos as funcionalidades da rede. Em relação a outras técnicas, captura uma quantidade menor de dados e pode ocasionar impactos negativos na rede, já que pode causar sobrecarga de recursos no tráfego existente; •medições passivas: realizada para registro do tráfego sem causar interferência na rede. Essa técnica utiliza instrumentos para capturar informações no momento em que circulam pela rede e mostra-se bastante efetiva devido a possibilidade de coletar um volume de dados bastante representativo. As técnicas de medição podem ser caracterizadas em dois tipos: centralizadas, quando as informações após coletadas são enviadas para um servidor para análise e armazenamento, ou distribuídas que é quando as informações são coletadas em pontos críticos da rede. 2.7.2 Métodos de Classificação Segue uma breve definição dos métodos mais utilizados na classificação do tráfego: •classificação baseada em portas: um dos métodos pioneiros na classificação que analisa portas de origem/destino e os protocolos utilizados durante o processo de comunicação. 27 CAPÍTULO 2. ESTADO DA ARTE Mas no processo evolutivo da Internet, esse método tornou-se ineficaz devido à diversas aplicações adotarem técnicas de disfarce ou portas aleatórias; •classificação baseada na carga útil (payload): denominado de inspeção profunda de pacotes (DPI - Deep Packet Inspection) é método para investigação do conteúdo dos pacotes. Através de informações existentes no campo de payload da camada de transporte faz comparação com uma base de dados para dedução do tipo de tráfego [18]. No entanto, se o tráfego estiver encriptado resulta numa solução ineficiente; •classificação baseada em recursos do fluxo: surgiu como alternativa a DPI e emprega o recurso de análise de dados automatizados para construir modelos analíticos recorrendo, por exemplo, a técnicas de machine learning. Esse método compromete-se em classificar aplicações através de dados estatísticos para identificar padrões no fluxo de informações [19]; •classificação comportamental de sistemas terminais: método baseado no comportamento dos sistemas que fazem a recepção do fluxo de dados. Essa classificação é composta de três níveis e proposta por [20]: o primeiro nível verifica a popularidade de acesso ao terminal face ao número de conexões existentes. O segundo nível se encarrega de descobrir se o terminal é um servidor ou consumidor de serviços ou colabora com outras conexões. Por último, o terceiro nível se responsabiliza em capturar as comunicações da camada de trasporte para identificar o aplicativo de origem. 2.8 Sumário Esse capítulo apresentou uma visão geral do processo evolutivo da Internet e de como a segurança tornou-se fundamental após seu desenvolvimento. Também abordou o funcionamento da Internet através da pilha protocolar TCP/IP, bem como o principal protocolo utilizado para comunicação na camada de aplicação, o HTTP. Além da evolução do protocolo, abordou-se sua aplicação com camada de segurança e os principais protocolos utilizados para essa fim. Por último, foi realizado um resumo sobre as principais técnicas de análise e medição do tráfego, seus métodos de classificação e as ferramentas existentes para identificar e classificar o trafego. 28 Capítulo 3 Critérios de Pesquisa e Trabalhos Relacionados Nesse capítulo será descrito brevemente o processo de recolha de material de referência por intermédio de uma revisão sistemática da literatura (SLR - Systematic Literature Review). Esse tipo de metodologia faz uso de critérios específicos e possibilita a identificação e avaliação das melhores fontes de informações relativas ao tema a ser desenvolvido. Também serão apresentados alguns artigos, resultados da SLR, que se relacionam diretamente com a temática abordada e servirão para elucidar diversos assuntos relativos aos impactos do HTTPS na navegação do utilizador final. 3.1 Revisão Sistemática da Literatura Desde que a Internet foi concebida a necessidade de modificação, para acompanhamento do desenvolvimento tecnológico, foi essencial. Porém, essas mudanças geraram impactos negativos e positivos entre a interação cliente/servidor, ou seja, na navegação Web em geral. A SLR, por sua vez, teve papel fundamental em mapear artigos onde esses impactos estivessem relacionados ao utilizador final. Baseado em [22] e para para cobrir a bibliografia base de forma efetiva, a metodologia SLR foi composta de cinco etapas: definição das questões de pesquisa (research questions) que servem de referência a este trabalho, determinar as fontes de pesquisa e criação de um termo de busca (research query) com palavras chaves, seleção de artigos relevantes, estudo dos artigos selecionados e extração/síntese dos dados encontrados. A figura 3.1 demostra a metodologia adotada. 29 CAPÍTULO 3. CRITÉRIOS DE PESQUISA E TRABALHOS RELACIONADOS Figura 3.1: Metodologia SLR. 3.2 Questões de Pesquisa Algumas research questions foram desenvolvidas para restringir um campo de análise específico, que se refere diretamente ao impacto da navegação do utilizador final: 1Qual é o impacto da utilização da criptografia na navegação Web do utilizador final (segurança e latência na navegação)? Com a evolução da Internet a necessidade de proteção dos dados se tornou fundamental. Além da preservação da identidade do usuário, a segurança da informação é essencial para diversas aplicações via Web, que vão desde consultas até transações bancárias. Essa questão tenta buscar os impactos na navegação do utilizador final, principalmente em relação à latência, já que medidas preventivas de segurança foram inseridas na estrutura da rede. 2Como se efetua e se estrutura a comunicação HTTPS com base nos protocolos SSL/TLS? Com a necessidade de mais segurança na navegação, a criação de protocolo para gerar comunicação segura foi essencial. Diante disso, essa questão irá abordar como o HTTPS se estrutura e sua relação com os protocolos SSL/TLS. 30 3.3. TERMOS DE BUSCA 3Que tipo de informação é possível extrair do HTTPS que seja relativa à comunicação clienteservidor? Para verificar modificações na forma de navegação do utilizador é imprescindível identificar quais os campos essenciais de informação presentes no protocolo de comunicação. 4Qual a percentagem de Navegação Segura é obtida pelos utilizadores com recurso aos vários dispositivos, como computadores pessoais e dispositivos móveis? Segundo algumas plataformas de informação, como o relatório de transparência do Google [1], retratam em pontos percentuais a quantidade de endereços que realmente trabalham com encriptação dos dados. Essa questão tratará de identificar se de fato a segurança está implantada no nível informado por essas ferramentas. 5Qual é a política de Navegação Segura usada pelos grandes fornecedores de conteúdos e serviços (Google, Yahoo, Bing, Facebook, Amazon,etc.)? Cada provedor de serviços possui uma política própria voltada para segurança. Assim, essa questão é necessária para esclarecer se as diferenças geram algum tipo de impacto ao utilizador final. 6Que ferramentas de análise de tráfego cifrado existem? Que técnicas e algoritmos são usados para análise de tráfego cifrado? A classificação do tráfego precisou se moldar aos avanças de tecnologia no campo de encriptação dos dados. Atualmente várias existem várias formas de análise e essa questão trará uma visão geral das ferramentas existentes e o quais serão utilizadas neste trabalho. 7Que evolução e modificações se efetuaram na Navegação Segura nos últimos anos? Essa questão visa reunir as modificações do processo de navegação segura proveniente da adoção da navegação encriptada ao longo dos últimos anos. 3.3 Termos de Busca Com as questões de pesquisa definidas, uma research query, foi desenvolvida segundo os parâmetros definidos em [22]. Esse método consiste em derivar as questões de pesquisa em palavras chaves, identificar sinónimos para cada termo principal, construir uma sequência de pesquisa utilizando as formas boolianas, com o OR para relacionar sinónimos encontrados e o AND para relacionar os termos de pesquisa principais. Todos os termos foram utilizados em inglês, devido ser a língua considerada como universal e 31 CAPÍTULO 3. CRITÉRIOS DE PESQUISA E TRABALHOS RELACIONADOS o idioma com a maior quantidade de trabalhos relevantes publicados. Em relação ao critério de escolha das palavras chave, foram selecionados cinco temas principais e seus sinónimos com maior referência ao tema de comunicação segura entre cliente/servidor. Os termos principais definidos estão listados a seguir e a Tabela 3.1 representa o resultado final do método aplicado. •network: representa suporte para as palavras chave referentes a comunicação entre dois ou mais dispositivos em rede; •security: representa suporte para as palavras chave associadas a segurança na Web; •traffic classification: representa suporte para as palavras chave relativas à caracterização do tráfego; •search engines: representa suporte para para as palavras chave direcionadas as principais motores de busca em relação a navegação segura de seus utilizadores; •devices: representa suporte para as palavras chave inerentes a navegação segura em sistemas operacionais para qualquer tipo de dispositivo. Tabela 3.1: Termos de busca e principais sinónimos. Termos sinónimos Network client-server communications, HTTP, latency, Web Content Provider Security HTTPS,TLS, SSL, secure web browsing, cryptography, security police Traffic classification traffic analysis, payload extraction, DPI, LPI Search engines Google, Yahoo, Bing, DuckGo, Gibiru Devices Android, Linux, Windows Com todos as palavras chaves escolhidas, uma research query foi desenvolvida de forma genérica para poder ser aplicado em qualquer base de dados e poder apresentar resultados consistentes: ("secure web browsing" OR HTTPS OR TLS OR SSL OR cryptography) AND ("traffic analysis" OR "client-server communications" OR latency OR "payload extraction" OR "deep packet inspection" OR DPI OR "light packet inspection" OR LPI ) AND ("web content provider" OR "security police") AND ("mobile device" OR desktop OR Android OR Linux OR Windows) AND (Google OR Facebook OR Yahoo OR Bing OR DuckGo OR Gibiru). 32 3.6. RESUMO DOS TRABALHOS SELECIONADOS modernos e os fatores que estão a levar a priorização do HTTP/2 como principal protocolo de comunicação. O artigo demonstra que a priorização desse tipo de tráfego não é trivial, devido a sua complexidade, e que alguns navegadores levam mais de 25% a mais do tempo médio para carregar uma página Web. Husák et al. [33]: Demonstra um experimento, baseado no monitoramento de rede e impressão digital do protocolo SSL/TLS, para realizar um processo identificação leve e de tempo real de clientes HTTPS. O trabalho demonstra a possibilidade de estimar o navegador de um cliente que utiliza comunicação HTTPS por meio do handshake SSL/TLS. Essa estimativa torna-se possível porque cada navegador tem valores diferentes para as informações de cabeçalho HTTP. A partir dessas informações, dicionários foram criados para identificar navegadores e conexões em tempo real com precisão de 95,4%. Felt et al. [34]: Estudo que reúne métricas para avaliar a adoção e impactos do protocolo HTTPS na perspectiva do cliente/servidor na Web. Para realizar essa avaliação, as métricas foram coletadas dos utilizadores agregados em larga escala dos navegadores Google, Chrome eMozilla Firefox. O trabalho também avalia o crescimento da adoção do HTTPS e identificação das áreas em que podem ter impactos relevante no ecossistema HTTPS. Anrbak et al. [35]: Retrata as vulnerabilidades estruturais do HTTPS, mapeia o mercado de certificados e analisa as soluções regulamentares e tecnológicas sugeridas pelas organizações responsáveis. As pesquisas demonstram que o mercado HTTPS não difere do setor financeiro devido a apresentar incompatibilidades de informações e diversas carências, já que os certificados digitais são produzidos por um número restrito de entidades certificadoras. O artigo também estima que que as propostas de melhorias estão longe de ser adotadas em larga escala e que as falhas persistirão nos próximos anos. Nayloret al. [36]: Por intermédio de datasets de grandes ISPs o estudo examinou resultados de uma adesão acelerada do HTTPS em um período de três anos. É mostrado que o HTTPS pode inserir mais custos na infraestrutura da rede, aumento de latência e mais consumo de dados e energia. Porém, a falta de clareza da comunicação criptografada resulta na ineficiência de visibilidade dos serviços que tenham valor agregado na rede de forma a dificultar seus custos reais . Esse artigo busca estimular a discussão sobre tecnologias que possam mitigar os custos do HTTPS e, ao mesmo tempo, proteger a privacidade do utilizador. Gonzalez et al. [37]: Com a premissa de que o HTTPS deveria tornar o mapeamento de perfis de utilização mais difícil para qualquer pessoa além dos endpoints de comunicação, este trabalho examina até que ponto essa afirmação tem veracidade. Em primeiro momento é mostrado que mediante a indicação do nome do servidor do protocolo TLS ou DNS, que um atacante pode ter informações básicas para criação de um perfil de utilizadores de domínios com conteúdos homo39 CAPÍTULO 3. CRITÉRIOS DE PESQUISA E TRABALHOS RELACIONADOS gêneos. Já para conteúdos com grande variedade de direcionamentos, como portais de notícias e compras, essa técnica possui falhas. Ainda assim, a possibilidade de criar perfis de acesso precisos por pela impressão digital de tráfego que utiliza assinaturas de rede é totalmente viável para identificar a página exata em que um utilizador estar a navegar. Isso torna-se viável devido a impressão digital da camada de transporte permanecer forte e escalável. Velan et al. [10]: Esta pesquisa tem como principal objetivo o fornecimento de uma visão geral e comparativa dos métodos para classificação e análise do tráfego encriptado. O estudo se divide em quatro etapas. Na primeira etapa descreve vários dos protocolos de criptografia mais utilizados com a demonstração de sua estrutura de pacotes e de seu comportamento padrão em uma rede para formar uma base de dados. Já na segunda etapa realiza uma investigação das informações fornecidas por cada protocolo de criptografia, onde os dados monitorados revelam cifras fracas. A descrição da estrutura dos protocolos de criptografia é utilizada na terceira etapa para detectar protocolos em uma rede através de algoritmos de classificação de tráfego. Na quarta e última etapa é fornecida uma diversidade de métodos baseados em comportamento para a classificação do tráfego encriptado, onde é possível obter informações muito detalhadas com destaque, em alguns casos, o conteúdo da conexão. Kausar et al. [38]: Trabalho que apresenta as problemáticas da análise de tráfego e evidencia ataques para explorar vulnerabilidades encontradas nos dispositivos móveis, principalmente em smartphones. Esses dispositivos se tornaram essenciais para navegação diária de um utilizador e não estão livres de riscos à segurança, mesmo com o tráfego encriptado. Desta forma, é proposto um ataque de tempo (timming attack) que rastreia o tempo de conexão entre cliente e servidor para cada solicitação realizada pelo utilizador. Nesse tipo de ataque os recursos de tempo são observados e cada conexão tem um tempo diferente, o que permite que a conexão seja identificada com precisão de 96%. Khater et al. [39]: Este trabalho aborda uma revisão crítica do campo de análise de tráfego de rede em tempo real através da utilização de algoritmos de machine learning para classificar o tráfego encriptado da Internet. Também é um trabalho que demonstra como os pesquisadores estão a buscar alternativas aos desafios atuais da classificação do tráfego encriptado. Finsterbusch et al. [40]: Este artigo apresenta pesquisa que realiza uma análise completa e minuciosa dos mais importantes módulos de DPI de código aberto. Essa análise compreende uma avaliação da precisão da classificação, por meio de um conjunto comum de rastreamentos de tráfego com base realística e de seus requisitos computacionais. Também é apresentada uma avaliação técnica dos módulos de DPI e o estudo dos resultados obtidos que proporcionam uma proposta de diretrizes gerais para o desenvolvimento e implementação de módulos de DPI mais adequados. 40 3.7. SUMÁRIO 3.7 Sumário Este capítulo expôs de forma sucinta o processo de uma revisão sistemática de literatura para seleção de trabalhos relevantes na área de análise e classificação do tráfego. É descrito o processo de criação das research questions eresearch queries para direcionamento específico do campo de pesquisa, bem como a utilização de ferramentas para classificar a qualidade de cada trabalho. Também é abordado a adoção de critérios de qualidade utilizados para um distinção de conferências e jornais com maior avaliações no campo de pesquisas científicas. Por fim é realizado um breve resumo dos artigos selecionados por serem mais relevantes para a temática de protocolos de comunicações seguros e tráfego encriptado. Diante dos trabalhos escolhidos, é possível notar que muitas das pequisas são direcionadas a buscar formas de identificar as mudanças na rede mundial de computadores após as implementações de criptografia. Diversos artigos tem o propósito de mensurar os efeitos do HTTP e suas novas versões, dos impactos do HTTPS, informações da camada de segurança e identificação do payload encriptado, seja voltada para o cliente, seja voltada para o servidor. Porém, são poucos trabalhos que visam discutir o que modificou para o utilizador no âmbito do que é perceptível por ele. Isto é, com todas essas alterações, o utilizador final é realmente capaz de observar o que alterou em seu acesso? Será que o seu acesso se tornou mesmo seguro? Quais os efeitos o HTTPS trouxe para suas informações na Web? Através desses questionamentos esse trabalho realizará um estudo para verificar, pela ótica do utilizador final, quais impactos o HTTPS trouxe para sua experiência de navegação a Internet. 41 CAPÍTULO 3. CRITÉRIOS DE PESQUISA E TRABALHOS RELACIONADOS 42 Capítulo 4 Metodologia A primeira parte do capítulo descreve o processo de criação de um ambiente de prova para verificação do protocolo HTTPS. Nele pretende-se simular, de forma fiável à realidade, a navegação de um utilizador comum em sua residência. Também serão descritas todas as ferramentas utilizadas, a forma como os dados foram capturados e o processo de reprodutibilidade dos testes. A segunda parte aborda a metodologia utilizada no processamento dos dados colhidos. Desta forma, busca-se demonstrar quais funcionalidades específicas de cada ferramenta foram selecionadas para investigar em detalhe os impactos da implementação da segurança na Web na perspectiva de um utilizador comum. 4.1 Ambiente Experimental Para análise dos impactos da utilização do protocolo HTTPS pelo utilizador final, é necessário definir um ambiente experimental de testes fiável a realidade. Isto é, um ambiente que ofereça condições de simular a navegação real de um utilizador em sua residência de modo a identificar, pelo tráfego gerado, o que a utilização de um protocolo seguro pode apresentar. A primeira parte desta sessão é responsável por descrever as principais etapas de conceção desse ambiente e foi dividida em duas sub-sessões: •infraestrutura: corresponde à infraestrutura utilizada para criação e operação das máquinas virtuais, seus respectivos sistemas operativos, navegadores e conteúdo a ser acessado; •ferramentas de captura e testes: descreve as ferramentas que necessitam estar instaladas nas máquinas virtuais para efetuarem o processo de captura do tráfego produzido. Também aborda os requisitos necessários para o processo de otimização e realização dos testes. 43 CAPÍTULO 4. METODOLOGIA A segunda parte com as demais sub-sessões, são responsáveis por descrever o plano dos testes que aborda como será realizada a sequência dos testes, a programação de suas funcionalidades de rotina de repetição e otimização, bem como o processo de medição dos dados. Também discute detalhes importantes dos navegadores e motores de busca utilizados, pois são de extrema importância para a compreensão da interação com protocolos de comunicação segura e seu possível comportamento durante a medição dos dados. Por último ocorre a demostração dos elementos necessário para reprodução do ambiente de testes. 4.1.1 Infraestrutura Conforme mencionado, no processo de criação do ambiente de simulação foi necessário definir qual conteúdo seria acessado, quais navegadores seriam utilizados e quais sistemas operativos comportariam a experimentação. Com o auxilio da ferramenta Alexa Traffic Rank1, que monitoriza os acessos a uma página Web e realiza uma comparação da sua popularidade em relação a outras páginas, criou-se uma relação das URLs para acesso à Internet. Esses endereços foram separados por géneros: notícias, redes sociais, serviços multimédia (streaming) de áudio e vídeo, serviços de e-mail, e motores de busca. Os critérios de escolha dos endereços foram baseados em: •maior número de acessos para endereços de notícias: – www.whiplash.net: é um dos maiores portais sobre música da América Latina e está em atividade há mais de 24 anos; – www.uol.com.br: é o maior portal de notícias do Brasil com mais de 113 milhões de visitantes únicos por mês e 6,7 bilhões de páginas visitadas mensalmente; – www.nexojornal.com.br: veículo de jornalismo eletrónico brasileiro e está entre os melhores portais de jornalismo independente do Brasil. Também é reconhecido por não exibir publicidade em seu conteúdo. •maior diversidade de conteúdo produzido pelos utilizadores para redes sociais: – www.instagram.com: umas das principais redes sociais de compartilhamento de fotos e vídeos entre seus utilizadores. Além de permitir filtros digitais, possibilita a interação com outros endereços de serviços como Facebook, Twitter e Tumblr. •principais plataformas de produção de conteúdos de áudio e vídeo para serviços multimédia: 1A ferramenta está disponibilizada no endereço https://www.alexa.com/topsites. 44 4.1. AMBIENTE EXPERIMENTAL – www.soundcloud.com: uma plataforma para publicação de áudio utilizada por profissionais de música. É um dos endereços mais utilizados para disponibilizar podcasts2; – www.youtube.com: uma das maiores plataformas de compartilhamento de vídeo. É o segundo endereço eletrónico mais acessado pelos utilizadores na Internet. •serviço de e-mail gratuito e com garantia de criptografia ponta a ponta: – www.protonmail.com: serviço de e-mail gratuito que utiliza criptografia para proteção de conteúdos e informações de seus utilizadores. Diferente de outros provedores de e-mail, esse servidor pode ser acessado através de um navegador, da rede Tor3, além de ter compatibilidade com aplicativos de diversos sistemas operativos. •motores de busca mais acessados e que garantam redirecionamento para endereços seguros e proteção de informações de utilizadores: – www.google.com: motor de busca mais utilizados na Internet e que garante o redirecionamento das pesquisas para endereços seguros; – www.bing.com: o segundo motor de busca mais utilizado na Internet. Além de ter sido desenvolvido pela Microsoft, também garante o redirecionamento de pesquisa para endereços seguros; – www.search.yahoo.com: o terceiro motor de busca mais utilizado na Internet e que também garante redirecionamento de pesquisas para endereços seguros; – www.duckduckgo.com: motor de busca alternativo que tem como principal filosofia a privacidade e o não registro de informações do utilizador; – www.gibiru.com: outro motor de busca alternativo que também não registra informações e não divulga informações do utilizador para endereços terceiros. A opção de escolha dos sistemas operativos foi baseada na popularidade entre os utilizadores e na total compatibilidade com bibliotecas de automatização de testes. Como primeiro sistema operativo optou-se pelo Xubuntu, que é uma distribuição Linux e umas das versões de software livre mais utilizadas. O segundo sistema escolhido foi o Windows, devido a ser o principal sistema operativo do mercado de utilizadores finais nos últimos anos. Os sistemas foram emulados a partir de máquinas virtuais criadas através do programa Virtual Box4, que é uma ferramenta específica 2Publicação de aquivos de áudio em formato digital, semelhante a uma transmissão de rádio. O conteúdo é criado sob demanda e fica disponível para o utilizador escutar quando quiser. 3Serviço de anonimização que tem como objetivo proteger as informações dos utilizadores quando elas chegam na Internet através de servidores de hospedagem ocultos. 4Mais detalhes da ferramenta podem ser encontrados em https://www.virtualbox.org. 45 CAPÍTULO 4. METODOLOGIA para a virtualização de sistemas. Essa aplicação permite simular ambientes diferentes que um utilizador pode possuir em seu computador pessoal. O processo de seleção dos navegadores também foi realizado através da popularidade de acesso entre utilizadores, através do último relatório comparativo da revista digital Computer World5, que publica conteúdos voltados para a tecnologia de informação. A compatibilidade com os sistemas operativos escolhidos também se mostrou de extrema importância para a seleção dos navegadores. Assim, segue a lista dos que foram elegidos: •Chrome: desenvolvido pela Google, é o principal navegador utilizado na Internet e integrado com todos os recursos oferecidos pelas plataformas de seus desenvolvedores. •Firefox: navegador gratuito desenvolvido para ser leve, seguro, intuitivo, extensível e multiplataforma. •Opera: presente no mercado há mais de 25 anos e que oferece aos utilizadores mais velocidade nos acessos e sistemas de proteção contra vulnerabilidades. 4.1.2 Ferramentas de Captura e Teste Como descrito na seção 2.7.3, existe uma grande diversidade de ferramentas de análise e classificação do tráfego. Porém, devido às limitações ou à demanda por funcionalidades específicas, torna-se necessária a combinação dessas ferramentas para que se obtenham informações mais completas sobre os dados coletados. A combinação de determinadas ferramentas tem como finalidade analisar os protocolos da camada de transporte, para identificação de fluxos TCP, fluxos UDP a utilizar QUIC e protocolos da camada de aplicação para identificação de sessões que utilizam protocolos de comunicação segura para os dados. É importante mencionar que não se busca identificar o tráfego encriptado e sim as informações encontradas antes desse processo. As seguintes ferramentas foram selecionadas: Tcpdump Utilitário de linha de comando que permite capturar e analisar o tráfego de rede que passa pelo sistema. Costuma ser utilizado no auxílio à identificação de problemas de rede, além de também ser uma ferramenta de segurança. Por ser uma ferramenta de linha de comando poderosa, versátil e com muitas opções de filtro, é ideal para executar em servidores ou dispositivos remotos para 5Os artigos publicados na revista encontram-se disponíveis em https://www.computerworld.com. 46 4.1. AMBIENTE EXPERIMENTAL os quais uma interface gráfica não está disponível e para coletar dados que podem ser analisados posteriormente. Para a coleta dos dados ser realizada, é necessário que os dois sistemas operativos estejam com a ferramenta tcpdump instalada corretamente. É importante ressaltar que essa aplicação precisa ser instalada com privilégios de administração do sistema para fornecer acesso a todas as suas funcionalidades oferecidas no processo de captura. Tshark Programa que analisa protocolos de rede, possibilita a captura ativa de pacotes e permite inspeção de todas as camadas de pilha protocolar TCP/IP. É um sniffer de rede desenvolvido para trabalhar através de linha de comandos. É compatível com diversos sistemas operativos, inclusive dispositivos móveis, como smartphones etablets. Possui flexibilidade para interação com diversas linguagens de programação e possibilita a criação de frameworks6direcionados às necessidades requeridas em uma análise de tráfego específica. Esse programa também é encontrado em versão com interface gráfica, a qual leva o nome de Wireshark. Ele disponibiliza várias ferramentas complementares como código de cores para os protocolos, visualização do fluxo completo de uma conexão e elaboração de gráficos estatísticos dos dados coletados. Libprotoident Analisador que utiliza o processo de inspeção leve de informações ( LPI - Lightweight Packet Inspection), o qual tem a função de investigar os primeiros quatro bytes da carga útil de um pacote juntamente com as portas e endereços IP usados entre dois pontos de conexão distintos. É considerado como uma forma limitada do processo de DPI, mas é avaliado com uma ferramenta de alta precisão para análise off-line [41]. Além de utilizar poucos recursos computacionais, possui uma biblioteca de suporte capaz de identificar mais de 200 protocolos distintos que atuam na camada de aplicação e utilizam TCP/UDP como transporte. Ainda, possui compatibilidade para ser inserida em uma framework. LibTrace Biblioteca que busca detalhes de compactação, formatos de captura e cabeçalhos de protocolo de forma mais eficiente, além de trabalhar em conjunto com a ferramenta Libprotident. A sua principal característica é a decodificação de protocolos para a camada de transporte e nas camadas 6Junção de várias ferramentas para criação de uma aplicação genérica. 47 CAPÍTULO 4. METODOLOGIA inferiores. Esse processo suporta, por exemplo, a verificação de cabeçalhos IPv6 (Internet Protocol Version 6), IPv4 (Internet Protocol Version 4), VLAN(Virtual Local Area Network), MPLS (Multiprotocol Label Switching), PPPoE (Point-to-Point Protocol over Ethernet), fragmentos IP, cabeçalhos incompletos e até cabeçalhos encapsulados [42]. Tstat É um analisador de rede passivo com capacidade de reconstruir as características do tráfego da Internet nos níveis IP, TCP/UDP e aplicação por intermédio de DPI [43]. Essa ferramenta disponibiliza diversas funcionalidades de pós-processamento que permitem a análise completa dos fluxos de dados transmitidos na rede. O Tstat possibilita retirar informações como: tamanho da janela de congestão, segmentos fora de sequência, segmentos duplicados, distinção entre cliente e servidores, aplicações específicas, protocolos, cabeçalhos, entre outras opções. Fiddler Desenvolvido para depuração de tráfego dos protocolos HTTP e HTTPS através de um servidor proxy. A ferramenta apresenta recursos para análise e inspeção de pedidos Web em traces já coletados ou em processos de captura em tempo real. O Fiddler pode ser usado com a maioria dos aplicativos sem a necessidade de configuração adicional, pois ao capturar ou analisar o tráfego, ele se registra no componente de rede da Internet do sistema operativo e solicita que todos os aplicativos comecem a direcionar seus pedidos para serem processados [44]. Essa ferramenta será complementar ao Tstat. SSLAnalyzer Funcionalidade da ferramenta PcapPlusPlus, que é uma biblioteca responsável por possuir recursos avançados para análise detalhadas de protocolos e camadas de um pacote [45]. O SSLAnalyzer, por sua vez, tem como principal característica a análise detalhada do tráfego SSL/TLS em traces coletados e em capturas em tempo real. A ferramenta também será complementar ao Tstat. Robot Framework É uma ferramenta gratuita para automação de testes através de processos automáticos. Como é uma aplicação aberta, permite criar soluções de testes automatizadas de forma elementar e 48 4.1. AMBIENTE EXPERIMENTAL Tabela 4.1: Termos da política de privacidade dos navegadores. Termos aceites na política de privacidade Google Firefox Opera Coleta de informações do sistema operativo Sim Sim Sim Coleta de informações pessoais e senhas Sim Sim Sim Coleta de pesquisas realizadas Sim Sim Sim Coleta de informações de voz e áudio Sim Sim Sim Coleta das atividades de compras Sim Sim Sim Coleta de contatos comunicados e conteúdos compartilhados Sim Sim Sim Coleta das atividades em sites de terceiros Sim Sim Sim Coleta do histórico de navegação Sim Sim Sim Coleta de cookies Sim Sim Sim Coleta das informações de localização geográfica Sim Sim Sim Coleta do endereço IP Sim Sim Sim Dados de pontos de acesso Wi-Fi, torres de celular e Bluetooth Sim Não Não Estatísticas de uso e relatórios de erros Sim Sim Sim Compartilhamento de dados com terceiros Sim Sim Sim Modificação dos dados compartilhados pelo utilizador Sim Sim Sim Declaração de que os dados compartilhados são anonimizados Não Não Sim Informação do período de retenção dos dados coletados Sim Não Não 4.1.7 Características dos Motores de Busca Um motor de busca é projetado para oferecer a seus utilizadores um programa que localize informações armazenadas em um sistema computacional baseado em palavras-chaves. Com essas características, cada motor de busca entrega resultados relevantes, opções de ampliação e restrições de pesquisa, organização das informações encontradas e fácil compreensão dos resultados. Outra propriedade relevante é a compatibilidade com o protocolo HTTPS, que representa a capacidade de utilizar criptografia para proteção de conexões cliente/servidor e o redirecionamento para conteúdos seguros. Ao realizar uma pesquisa, o utilizador necessita de uma rápida resposta do motor de busca. Para que a o processo seja eficiente e retorne informações relevantes, um motor de busca requer a execução prévia de algumas funções específicas: •coleta: programas que percorrem continuamente uma vasta quantidade possível de páginas Web; •armazenamento: as páginas encontrada são armazenadas em servidores dedicados; •extração: todos os conteúdos das páginas encontradas são extraídos; 55 CAPÍTULO 4. METODOLOGIA •indexação: o conteúdo extraído precisa ser estruturado em meios eficazes de pesquisa; •classificação: método para colocar páginas Web com mais probabilidade de dar a resposta correta para a palavra solicitada durante o processo de busca; •pesquisa: forma de como o motor de busca apresenta os resultados encontrados que podem se basear, ou não, em critérios opcionais impostos pelo utilizador. As funções descritas acima destinam-se a clarificar, de forma breve, a capacidade do motor de busca conseguir processar, pesquisar e entregar resultados de forma eficiente para o utilizador. Através de algorítimos de processamento, muitos motores de busca garantem esses resultados e empenham-se em apresentar conteúdos totalmente seguros com o redirecionamento para URLs que utilizem o protocolo HTTPS como padrão. O emprego da política de privacidade também acontece nos motores de busca e de forma semelhante ao que é empregue nos navegadores. A Tabela 4.2 resume alguns termos empregues pelos motores Google, Bing13, Yahoo14, DuckduckGo15 e Gibiru16. Tabela 4.2: Termos da política de privacidade dos motores de busca. Características Google Bing Yahoo DuckDuckGo Gibiru Coleta de informações pessoais Sim Sim Sim Não Não Coleta de pesquisas realizadas Sim Sim Sim Não Não Coleta do histórico de pesquisa Sim Sim Sim Não Sim Resultados personalizados Sim Sim Sim Não Não Estatísticas de utilização Sim Sim Sim Não Não Compartilhamento de dados com terceiros Sim Sim Sim Não Não Coleta e inserção de cookies* Sim Sim Sim Não Não Utilização de busca patrocinada** Sim Sim Sim Não Não Detector de políticas de privacidade abusiva*** Não Não Não Sim Não Coleta da localização geográfica Sim Sim Sim Sim Sim Coleta de endereço IP Sim Sim Sim Não Não Navegação segura com HTTPS Sim Sim Sim Sim Sim Período de retenção dos dados coletados Sim Sim Não Não Não (*) Além da coleta de cookies utilizados, o motor de busca também os implanta para acesso a informações do computador utilizado. (**) Processo onde as páginas Web pagam aos motores de busca para exibirem seu endereço em pesquisas relevantes. 13Pode ser consultado em https://privacy.microsoft.com/pt-pt/privacystatement 14Pode ser consultado em https://policies/verizonmedia/privacy/products/searchservices/pt/br/index.html 15Pode ser consultado em https://duckduckgo.com/privacy 16Pode ser consultado em https://gibiru.com/privacy-policy/privacy-policy 56 4.1. AMBIENTE EXPERIMENTAL (***) Localização de páginas Web com rastreadores ocultos e políticas de privacidade que expõem os dados do utilizador. 4.1.8 Reprodutibilidade A reprodução do ambiente de testes torna-se possível para quaisquer scripts, rotinas de testes e capturas de tráfego efetuadas neste trabalho. Para que seja viável, torna-se essencial respeitar as ferramentas citadas ao longo de toda Sessão 4.1, bem como suas versões mais atualizadas para garantia de um bom desempenho. Para este trabalho, as seguintes versões foram utilizadas: •Virtual Box na versão 6.1.6; •Distribuição Linux Xubuntu na versão 18.04 com todas atualizações vigentes até maio de 2020; •Windows na versão 10 com todas as atualizações vigentes até maio de 2020; •Linguagem de programação Python na versão 3.7; •Para escrita de código o PyCharm foi utilizado na versão 2020.1; •Robot Framework na versão 3.1.2; •Selenium Library na versão 4.4.0; •Tshark na versão 2.6.10; •Tcpdump na versão 4.9.3; •Fiddler na versão 0.5.0; •SSLAnalyzer na versão 19.12; •Google Chrome na versão 81; •Firefox na versão 75; •Opera na versão 68. 57 CAPÍTULO 4. METODOLOGIA 4.2 Extração das Informações Para realizar o processo de extração dos dados é necessário descrever o papel de cada ferramenta apresentada na Sessão 4.1.2. Com a junção de toda a informação se pretende ter mais precisão na análise dos dados. As funcionalidades exploradas em cada ferramenta são a seguir descritas. Tcpdump Responsável por executar a captura do tráfego durante o período de testes. Os arquivos gerados serão salvos na extensão .pcap, visto que todas as ferramentas selecionadas possuem compatibilidade de leitura. Tshark Utilizado para tratamento dos dados capturados devido à sua capacidade de inserção de filtros, verificação de fluxos e geração de gráficos estatísticos. Libprotoident OLibprotoident necessita da biblioteca Libtrace instalada para ativar suas funções e ter a eficiência esperada. Possui duas funções a lpi_protoident elpi_find_unknown. A função lpi_protoident é responsável por tentar identificar os fluxos individuais dos dados que foram concluídos ou expirados e expor informações importantes da camada de aplicação. Os campos relevantes dessa função são: Protocolo de aplicação utilizado 58 4.2. EXTRAÇÃO DAS INFORMAÇÕES IP cliente IP servidor Porta usada pelo cliente Porta usada pelo servidor Protocolo de transporte (6 = TCP, 17 = UDP) Registro de data e hora de início do fluxo Registro de data e hora do fim do fluxo Total de bytes enviados do cliente para o servidor Total de bytes enviados do servidor para o cliente Primeiros quatro bytes de carga útil enviados do cliente em hexadecimal Primeiros quatro bytes de carga útil enviados do cliente em ASCII Tamanho do primeiro pacote de carga útil enviado do cliente Primeiros quatro bytes de carga útil enviados do servidor em hexadecimal Primeiros quatro bytes de carga útil enviados do servidor em ASCII Tamanho do primeiro pacote de carga útil enviado do servidor A segunda, lpi_find_unknown, é responsável por listar os fluxos que a função lpi_protoident não conseguiu identificar. Possui os mesmos campos da primeira função, com exceção do campo de protocolo da aplicação. Fiddler Possibilita visualizar as informações de cada objeto de sessão detalhada com requisição/respostas da conexão entre cliente-servidor. O objeto de sessão também mantém um conjunto de sinalizadores que registram metadados sobre a sessão e um temporizador que armazena carimbos de data e hora registrados no decorrer do processamento da sessão. SSLAnalyzer Realiza detalhamento exclusivo do tráfego SSL/TLS e apresenta as seguintes informações: Contagem e taxa de pacotes 59 CAPÍTULO 4. METODOLOGIA Largura de banda Contagem e taxa de fluxo Pacotes e dados médios por fluxo Número de mensagens do cliente-hello e do servidor-hello Número de fluxos SSL com handshake e mensagens de alerta bem-sucedidas Histograma do nome do host Histograma do conjunto de cifras Histograma de versão Hello do cliente Histograma de portas SSL / TLS Tstat De todas as ferramentas, o TSTAT terá importância maior devido a ter a propriedade de relatar todas as conexões TCP e cabeçalhos HTTP/HTTPS mais detalhadamente. Para validar a conexão, a aplicação identifica o primeiro segmento de início de sessão SYN ( ) e seu término quando são observados os segmentos FYN ( ), ACK ( ) e RST ( ). Para toda a conexão TCP fechada corretamente, a ferramenta cria um arquivo de eventos (log) chamado log_tcp_complete e para conexões incompletas, cria outro arquivo chamado log_tcp_nocomplete. Os registros contidos nas saídas de log são configuráveis a partir de um arquivo chamado runtime.conf. Esse arquivo é separado em módulos para determinar quais serão as informações analisadas. A princípio, três funcionalidades estarão ativas: Core TCP set, encarregado de ativar os eventos relativos às conexões TCP concretizadas, TCP Layer7 set, que inclui informações da camada de aplicação, e a função log_http_complete que registra todas as requisições e respostas do protocolo HTTP/HTTPS em um arquivo específico. As funções Core TCP set eTCP Layer7 set são registradas no log_tcp_complete e todas as suas saídas podem ser consultadas no Apêndice A. Os parâmetros escolhidos para análise foram: •connection type: registro a indicar o tipo de conexão (HTTP, SSL/TLS) conforme identificado pelo mecanismo de inspeção de camada de aplicação; •HTTP type: estados do protocolo HTTP; •HTTP request count: número de requisições para conexões HTTP entre cliente/servidor; •HTTP response count: número de requisições para conexões HTTP entre servidor/cliente; •first HTTP response: código de resposta HTTP; •PSH-separated C2S: mensagens de notificação entre cliente/servidor; 60 4.2. EXTRAÇÃO DAS INFORMAÇÕES •PSH-separated S2C: mensagens de notificação entre servidor/cliente; •TLS client hello SNI: nome do servidor indicado pelo cliente; •TLS client NPN/ALPN: negociação SSL/TLS para HTTPS entre cliente/servidor; •TLS server NPN/ALPN: negociação SSL/TLS para HTTPS entre servidor/cliente; •TLS client ID reuse: número de identificação de sessão utilizado pelo cliente; •TLS client last handshake: último handshake realizado pelo cliente antes do envio dos dados encriptados; •TLS server last handshake: último handshake realizado pelo servidor antes do envio dos dados encriptados; •TLS client app data time: tempo entre a primeira mensagem de dados e o primeiro fluxo enviado do cliente para o servidor em milissegundos; •TLS server app data time: tempo entre a primeira mensagem de dados e o primeiro fluxo enviado do servidor para o cliente em milissegundos; •TLS client app data bytes: sequência de mensagens entre cliente/servidor; •TLS server app data bytes: sequência de mensagens entre servidor/cliente; •FQDN: nome do servidor de domínio recuperado; •IP of DNS resolver: endereço do servidor DNS utilizado; •DNS request time: tempo de requisição ao DNS em milissegundos; •DNS response time: tempo de resposta do DNS em milissegundos. A função log_http_complete registra as informações de cabeçalho de requisição e resposta do protocolo HTTP/HTTPS. Os parâmetros selecionados para análise são: •client IP addr: endereço IP do cliente; •client TCP port: porta TCP do cliente; •server IP addr: endereço IP do servidor; •server TCP port: porta TCP do servidor; •segment time abs: tempo absoluto do processo de requisição e resposta; 61 CAPÍTULO 4. METODOLOGIA •request method: método de requisição (GET/POST/HEAD); •hostname: nome de domínio do servidor (para hospedagem virtual) e (opcionalmente) o número da porta TCP na qual o servidor está a escutar; •FQDN: nome do servidor de domínio recuperado; •URL path: URL de requisição •referer: origem da solicitação do cliente; •user agent: identificador do navegador do cliente; •cookie: cabeçalho de solicitação de cookie recebido pelo navegador do cliente; •do not track: opção de não rastreio habilitada pelo navegador do cliente; •response string: identificador de resposta do servidor; •response code: código de resposta enviado pelo servidor; •content len: tamanho do corpo da entidade em bytes; •content type: tipos de arquivo contidos no corpo da entidade; •server: mensagem de resposta do servidor; •range: resposta HTTP/HTTPS para intervalos de solicitações parciais; •location: registro de redirecionamento de URL; •set cookie: envio de cookies do servidor para o cliente. O fluxograma presente na Figura 4.3 ilustra como será o processo de recolha das informações a partir de cada ferramenta descritas na Sessão 4.1.2. 4.2.1 Tratamento e Classificação dos Dados Com as informações extraídas, serão identificados quais os dados relevantes do utilizador que ficam disponíveis e/ou expostos em um processo de captura. Dessa forma, será constatado até que ponto sua navegação pode ser dita como segura. Para isso ser possível, as ferramentas selecionadas serão essenciais para averiguação dos dados a serem capturados e precisarão evidenciar, se possível: •sessões de handshake de três vias que antecedem a encriptação do payload; 62 4.2. EXTRAÇÃO DAS INFORMAÇÕES Figura 4.3: Fluxograma de utilização das ferramentas. •informações de segurança relativas a versão dos protocolos HTTP, HTTPS, TLS e SSL; •informações de cabeçalho de camada de transporte e aplicação que são visíveis; •informações de cookies; •informação de certificados; •processo de redirecionamento para conteúdo seguro do protocolo HTTPS; •tempo médio entre requisições e respostas entre cliente/servidor. Todos os dados recolhidos passarão por um processo de tratamento em etapas, de modo que se extraia as informações mais relevantes de todo o processo de utilização do protocolo HTTPS e HTTP. A Figura 4.4 demonstra que será extraído do fluxo de dados todas as conexões TCP que foram realizadas. A partir das conexões TCP completas, um script de filtragem de dados irá separar os fluxos por conexões seguras (HTTPS) e conexões inseguras (HTTP). Dos dois tipos de conexões se extrairá todas as informações do processo completo de comunicação entre cliente/servidor. Apenas após esse processo os dados serão, de facto, interpretados. Para as conexões TCP incompletas e conexões TCP completas, com informações do processo de comunicação cliente/- servidor parciais, os dados não terão validade para o propósito do trabalho e serão descartados. 63 CAPÍTULO 4. METODOLOGIA Figura 4.4: Fluxograma de tratamento dos dados. 4.3 Sumário Este capítulo mencionou a metodologia utilizada para a criação de um ambiente de testes funcional e das ferramentas escolhidas, com destaque para as funcionalidades que serão aproveitadas, para realizar o processo de captura e análise dos dados. Também foi o processo das sessões de teste e os períodos de medição. Por último foi exposto em detalhe quais as informações pertinentes de cada ferramenta que foram extraídas para uma análise detalhada de todos os dados colhidos. Todas essas informações são necessárias, pois serão alvo de análise no capítulo seguinte. 64 5.2. ANÁLISE DOS RESULTADOS Figura 5.5: Quantidades de portas visíveis por navegador. 5.2.2 Conexões SSL/TLS A seguir com a análise do handshake entre cliente/servidor, o protocolo SSL/TLS foi inspecionado de modo a identificar as informações da camada de segurança do protocolo HTTPS. A Figura 5.6a demonstra o percentual de utilização do protocolo SSL/TLS nos três navegadores por cada sistema operacional. Como se pode observar, o navegador Chrome possui em média 15%, o Firefox 25% e o Opera 14% dos pacotes recolhidos em cada teste. O Firefox se sobressai por utilizar mecanismos próprios de autenticação e certificados digitais o que o torna mais eficiente neste processo. Já os valores aproximados do Chrome e do Opera ocorrem pela semelhança estrutural, conforme citado anteriormente. Outro ponto a destacar é a utilização de extensões próprias da Google para transferência de informações encriptadas que acabam sendo inibidas pelas ferramentas de análise dos dados. Na Figura 5.6b é possível observar que a quantidade de fluxos SSL/TLS ocorridos com handshake bem-sucedidos é aproximada em todos os navegadores, mesmo em sistemas operativos distintos. Mesmo com informações ocultadas pelos navegadores é admissível aceitar que o protocolo trabalha de forma semelhante em qualquer um dos cenários propostos. Na continuação da investigação dos fluxos, foi possível determinar qual a versão do protocolo utilizada tanto pelo cliente quanto pelo servidor. Na Figura 5.7a pode-ser perceber que versão SSL 3.3, composta pelo SSL3 e TLS 1.2 em modo legado (compatível com versões inferiores), é a mais utilizada pela grande maioria dos servidores Web. Já na Figura 5.7b, que representa o lado do cliente, o resultado de que todos os navegadores utilizem a versão SSL3 com TLS 1.0 massivamente surpreendeu. O resultado inesperado demonstra que o protocolo a ser utilizado está obsoleto, além de possuir diversas vulnerabilidades já conhecidas [14]. 71 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS Figura 5.6: Percentual do tráfego SSL/TLS e fluxos bem-sucedidos por cenário. Os desenvolvedores dos navegadores estimam que, ainda no ano de 2020, o suporte as versões 1.0/1.1 sejam encerrados [50]. Porém, até o momento de elaboração deste trabalho, os navegadores ainda fazem utilização desta versão como padrão. Para modificar para uma a versão mais atualizada, o utilizador precisa alterar as configurações do navegador de forma manual. Esse tipo de alteração acaba por não ser abrangente, visto que a maioria dos utilizadores não detém esse conhecimento. Figura 5.7: Percentual do versão SSL/TLS no lado do Servidor e do Cliente. Ainda através do fluxos bem-sucedidos, também foi possível verificar mais três tipos de informações: o nome do servidor com o número de cada uma de suas interações, mapeamento das prováveis atividades do utilizador e os certificados de autenticação. Em relação aos nomes dos 72 5.2. ANÁLISE DOS RESULTADOS servidores é notório, através da tabela 5.2, a visibilidade de informações em um exemplo de interação cliente/servidor pelo navegador Chrome. Pode-se observar a maioria URLs acessadas faz interações com servidores terceiros para recolha de dados com base nos acessos dos utilizadores. Também pode-se verificar um bom número de servidores que direcionam anúncios intrusivos aos utilizadores, ou seja, sem permissão pŕevia. O programa responsável por essa função é chamado de adware e serve para explorar os locais visitados pelo utilizador e redirecioná-lo a publicidade vinculada a sua navegação. As configurações padrões dos navegadores, de acordo com as políticas de privacidade presentes na Sessão 4.2.7, liberam essas informações e o utilizador não possui nenhum tipo de controle a menos que realize modificações nas configurações. Tabela 5.2: Interações SSL/TLS - Google Chrome. Servidor Tipo Interações por Coleta Diária www.facebook.com Estatístico 67 www.gstatic.com Anúncios intrusivos 63 a-v2.sndcdn.com Estatístico 62 www.google.com Estatístico 52 api-v2.soundcloud.com Conteúdo 44 www.whiplash.net Conteúdo 42 www.i.matheranalytics.com Estatístico 37 nexojornal.s3-sa-east-1.amazonaws.com Conteúdo 35 ib.adnxs.com Anúncios intrusivos 31 www.instagram.com Conteúdo 34 googleads.g.doubleclick.net Anúncios intrusivos 31 s.yimg.com Anúncios intrusivos 28 r6—sn-1vo-v2vs.googlevideo.com Servidor Proxy de conteúdo 27 i.ytimg.com Anúncios intrusivos 26 No entanto, para o mapeamento das atividades do utilizador, mesmo com os dados do payload encriptados, existe a possibilidade de estimar qual acesso foi realizado pelo utilizador apenas com os endereços dos servidores. Por exemplo, na tabela 5.2 o endereço r6—sn-1vo-v2vs.googlevideo.com é um servidor Web Proxy do serviço de streaming de vídeo utilizado por um ISP. Com algumas consultas simples, através páginas Web de geolocalização de endereços IP, foi possível confirmar que o endereço de facto pertence a um ISP de Portugal. Assim, é possível explorar os endereços solicitados pelo navegador e ter conhecimento de toda a navegação realizada. Também foi possível identificar as datas dos certificados digitais utilizados no processo de autenticação dos fluxos SSL/TLS. A tabela 5.3 oferece um resumo da data de validação dos certificados por endereço acessado, onde os valores são os mesmos para todos os navegadores 73 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS utilizados nos testes. Fica evidente que existe uma grande quantidade de certificados que estão fora de validade que podem comprometer a relação de confiança entre cliente/servidor de diversas formas. No entanto, pode observar também que existe uma boa parte dos endereços que estão a utilizar certificados que expirarão nos próximos 50 anos. Resumidamente, toda informação encontrada no processo de handshake antes da encriptação do payload demostra exposição a algum tipo de vulnerabilidade. Seja por utilização de um protocolo desatualizado, seja por redirecionamento a endereços intrusivos. Também existe exposição das informações do utilizador que tornam possível a realização de um footprint4do seu perfil de navegação, como se pode ver em [37] e [38]. Para os certificados digitais inválidos, além de colocar os serviços disponíveis em risco, deixam o utilizador suscetível a fraudes e roubos de identidade [35] [28]. Tabela 5.3: Tempo de validade dos certificados digitais por endereço eletrônico acessado. URL <1990 1991-2000 2001-2019 2020-2050 2051-2070 >2071 www.whiplash.net 0% 0% 10% 25% 45% 20% www.uol.com.br 0% 3% 16% 22% 47% 12% www.nexojornal.com.br 0% 0% 0% 37% 42% 21% www.instagram.com.br 0% 10% 14% 26% 39% 11% www.soundcloud.com 0% 0% 17% 0% 41% 42% www.youtube.com 0% 0% 12% 36% 27% 25% www.protonmail.com 9% 12% 0% 79% 0% 0% www.google.com.br 1% 18% 3% 20% 38% 20% www.bing.com 0% 0% 0% 0% 45% 55% www.yahoo.search.com 15% 0% 25% 0% 27% 33% www.duckduckgo.com 7% 12% 81% 0% 0% 0% www.gibiru.com 13% 0% 26% 0% 0% 61% terceiros* 20% 9% 0% 11% 32% 28% (*) Representa os certificados por URLs de terceiros que atuam no encaminhamento de conteúdo intrusivo. 5.2.3 Cookies As páginas Web fazem uso de diversos métodos importantes para melhoria da experiência de navegação e entregar um conteúdo interessante para cada visitante. Desta forma, os cookies 4Processo de organização de ideias para criar um perfil completo do alvo a ser atacado. 74 5.2. ANÁLISE DOS RESULTADOS tornam-se uma das técnicas mais conhecidas para essa função conforme visto na Sessão 2.7.1. Nesta etapa foram analisados os seguintes tipos: •cookies de sessão: armazenados temporariamente no computador do utilizador e são removidos após o fechamento do navegador. •cookies persistentes ou de controle: armazenam informações chaves do utilizador para otimizar sessões futuras entre o cliente/servidor, além de possuir data de validade e ser eliminado automaticamente. •cookies de terceiros: definidos e utilizados por entidades não proprietárias dos cookies. Essas informações sobre cookies foram listadas a partir de uma função (get_cookie) específica da biblioteca Selenium. Essa função é um pedido em texto pleno sobre as informações enviadas entre cliente/servidor. Abaixo, por exemplo, seguem todas as saídas geradas para os três navegadores através do acesso ao portal de notícias Whiplash nos dois cenários utilizados. Neste caso, a única diferença existente entre elas é o identificador do utilizador que é gerado ao inicio de cada sessão. 1Whiplash porta l −Windows/Linux 3Chrome {’_gat_gtag_UA_156193_3 ’ :’ 1 ’ ,’ _gid ’ :’GA1.2.125023890.1588674206 ’ ,’_ga ’ : ’GA1.2.696601717.1588674206 ’ ,’paginas_vistas ’ :’ 1 ’ ,’__cfduid ’ :’ d9b106010294c0646c3d4af464ab4b8081588674196 ’} 5Firef ox {’__cfduid ’ :’d5d8ed5fb200aad1baa6d2bf76a11f6c41588676885 ’ ,’paginas_vistas ’ :’ 1 ’ ,’_ga ’ :’GA1.2.1627188287.1588676897 ’ , 7’ _gid ’ :’GA1.2.1149617488.1588676897 ’ ,’_gat_gtag_UA_156193_3 ’ :’ 1 ’ } Opera 9{’_gat_gtag_UA_156193_3 ’ :’ 1 ’ ,’ _gid ’ :’GA1.2.490610151.1588679600 ’ ,’_ga ’ :’ GA1.2.1257842315.1588679600 ’ ,’paginas_vistas ’:’ 1 ’ ,’__cfduid ’ :’ d5a0d52900f6f2f19157dc8a1d056356f1588679598 ’} Nas saídas acima, é possível identificar alguns tipos de cookies: •_gat_gtag: associado ao Google Analytics5para fixar a taxa de solicitações e limitar a 5Serviço da Google para monitoramento de tráfego que pode ser agregado a qualquer endereço eletrônico e ferramenta fundamental para o marketing digital. 75 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS coleta de dados em sites de alto tráfego. E expira após 10 minutos; •_ga: também e associado ao Google Analytics para atualização dos serviços de análise utilizados pelo Google. Faz distinção de utilizadores únicos com a geração de uma identificação de clientes. E é incluído em requisições cliente/servidor para calcular dados dos visitantes, sessões e gerar relatórios de análises em uma página Web. Por padrão pode expirar em 2 anos, mas pode ser modificado pelo proprietário do serviço; •_gid: associado ao Google Analytics, parece armazenar e atualizar um valor exclusivo de identificação para cada página visitada em um servidor Web. Este cookie expira em 24 horas; •__cfuid: associado a Cloudfare6para maximizar os recursos da rede, gerenciar o tráfego e proteger os sites contra tráfego mal-intencionado. O seu tempo de vida é no máximo de 30 minutos. A partir dos dados recolhidos no processo de simulação, foi possível gerar a tabela 5.4 que sumariza os tipos de cookies e suas saídas encontradas em todas URLs acessados. É possível notar que todos os endereços armazenam poucos cookies de sessão, que costumam ser removidos após o fechamento do navegador. Os persistentes são utilizados pela grande maioria dos endereços listados, o que deixa claro que há preferência por conservar os dados dos utilizadores. Também é possível observar que a maior parte dos endereços trabalha com cookies de terceiros, ou seja, fazem compartilhamento de informações para compor diversas bases de dados e anúncios intrusivos. O exemplo dos cookies retirados do portal Whiplash demonstra que as informações, de facto, são compartilhadas e disponibilizadas em forma de estatísticas. Outro destaque é para o portal UOL, cujo URL é o que mais possui cookies persistentes. Como é um portal com milhares de acessos mensais, torna-se um endereço eletrônico atrativo para mapear diversas informações sobre os utilizadores em larga escala. O tempo de expiração dos certificados serve para ter uma noção do período que os dados dos utilizadores são armazenados por uma base de dados. Essa constatação configura um alerta sobre a possibilidade da existência de abusos praticados pelas políticas de segurança adotadas por navegadores, motores de busca e páginas Web. Essa questão ocorre devido às informações do período da retenção de dados não serem claras em nenhum dos casos. Isto é, o utilizador não tem nenhuma noção para quem ou por quanto tempo seus dados ficarão realmente disponíveis na Internet. Desta forma, a adoção de melhores práticas que visem a redução desse tempo devem ser adotadas com mais transparência. Outra questão é que a falta de controle sobre os arquivos cookies pode ocasionar roubo de informações acaso não apresentem códigos de autenticação corretos, pois 6Empresa que oferece um conjunto de serviços de proteção e otimização de páginas Web. 76 5.2. ANÁLISE DOS RESULTADOS Tabela 5.4: Tipo de cookies encontrados por endereço eletrônico. Endereço Eletrônico Cookies de Terceiros Cookies Persistentes Cookies de Sessão www.whiplash.net 4 8 2 www.uol.com.br 6 24 9 www.nexojornal.com.br 1 5 2 www.instagram.com 1 6 0 www.soundcloud.com 0 1 0 www.youtube.com 1 3 2 www.protonmail.com 0 2 0 www.google.com 1 5 0 www.bing.com 2 7 2 www.yahoo.search.com 1 4 2 www.duckduckgo.com 0 0 0 www.gibiru.com 0 0 0 há diversos estudos que comprovam essas falhas [16]. Para esse estudo, a maioria das sessões estavam autenticadas e aparentemente não apresentaram a existência de vulnerabilidades. Em seguida buscou-se verificar o tempo de expiração dos cookies encontrados. Os dados foram concentrados na tabela 5.5, onde é possível verificar que o tempo expiração mais utilizado para armazenamento é o período de 2 anos. Porém, foram encontrados outros endereços que concentrase em armazenar informações por muito mais tempo, com variações que podem ser de 5 dias até 20 anos. São poucos os endereços que fazem uso de dados que expiram em menos tempo com destaque para os cookies que são descartados em até 10 minutos ou quando o navegador é simplesmente fechado. 5.2.4 HTTP e HTTPS Em termos de adoção da versão do protocolo HTTP, identificou-se o uso expressivo da versão 1.1, como pode ser visto na Figura 5.8. Mesmo com o HTTP/2 em crescente adoção e com os navegadores configurados por padrão para uso automático desse protocolo, não houve registros de versões diferentes da versão 1.1 em nenhum dos dois cenários de testes. No entanto, existem estudos que comprovam que a adesão é uma realidade por diversos servidores Web [31] [32]. Outra análise realizada foi a utilização do protocolo HTTPS em relação ao HTTP. A Figura 5.9a sumariza os resultados do sistema operacional Linux. O Firefox detém mais de 93% do seu tráfego encriptado. Já o Chorme tem um comportamento diferente em relação aos outros 77 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS Tabela 5.5: Percentual de cookies por tempo de validade. Tempo expiração Percentual 10 minutos ou quando o navegador for finalizado 17,5% Até 24 horas 6,0% Até 5 dias 4,5% Até 30 dias 11,0% Até 100 dias 8,0% Até 300 dias 2,0% Até 1 ano 7,8% Até 2 anos 36,0% Até 10 anos 6,2% Até 20 anos 1,0% Figura 5.8: Percentual do protocolo HTTP/1.1. navegadores, pois apenas 59% é considerado como HTTPS e 29,7% HTTP. O alto índice do uso do HTTP, neste caso, ocorre devido ao navegador utilizar o protocolo QUIC nas conexões TCP realizadas por este mesmo protocolo. Conforme já citado anteriormente, esse protocolo é proprietário do Google e também utiliza SSL/TLS para encriptar a troca de dados. O Opera também apresenta essa mesma particularidade com o QUIC devido a utilizar o mesmo motor de compilação que o Chrome. Desta forma, apresenta 49% para HTTPS e 26% para HTTP. A Figura 5.10 expõe um exemplo de requisição bem sucedida entre cliente/servidor com evidência na presença do protocolo na porta 443 para os navegadores Chrome e Opera. Na Figura 5.9b são demonstrados os resultados para o sistema operacional Windows e como pode-se observar eles são semelhantes com Opera a apresentar maior uso de HTTPS em Windows. 78 5.2. ANÁLISE DOS RESULTADOS Figura 5.9: Percentual de Utilização HTTP e HTTPS no Linux e Windows. Portanto, se constata que o comportamento dos navegadores é similar em todos os cenários de teste e com percentuais altos de encriptação de informações. O sistema operacional, nesse caso, não é um fator determinante para melhor utilização de um protocolo de navegação seguro para o utilizador final. Figura 5.10: Requisição de Resposta HTTP. Mesmo com adoção em larga escala do HTTPS, ainda existem muitos acessos que não utilizam nenhum tipo de segurança. Para este trabalho, todos URLs selecionadas utilizam protocolos de comunicação segura entre cliente/servidor. Entretanto, isso não significa que o protocolo HTTPS não apresente falhas, como demonstrado em trabalhos como [35] e [14]. Ainda, mesmo com a encriptação dos dados, é possível captar diversas informações dos utilizadores das mais diversas formas, nomeadamente o tamanho de pacotes [25], machine learning [29], reconstrução de conexões TCP [30] ao handshake SSL/TLS [33]. 79 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS 5.2.5 Comportamento dos Navegadores Os navegadores selecionados dispõem de uma série de recursos de configurações que vão da melhoria de recursos a restrição do compartilhamento de informações. Muitos utilizadores não possuem um conhecimento avançado de informática para customizar um navegador para suas necessidades de navegação, pois na maioria dos casos almejam apenas que o processo de navegação seja eficiente. Desta maneira, muitos navegadores apresentam uma configuração padrão ao serem instalados nos dispositivos. Essas configurações iniciais são baseadas na politicas de privacidade aceites pelo utilizador na instalação do navegador, visto que esse processo só é concluído com a aceitação de todos os termos propostos. A tabela 5.6 resume algumas das configurações presentes nos navegadores Chrome, Firefox e Opera. É válido ressaltar que as configurações não sofrem alterações pela diferença dos sistemas operativos dos cenários de testes. A tabela evidencia que a maioria dos parâmetros encontra-se ativa e está de acordo com as políticas de privacidade citadas na Sessão 4.1.6. Fica evidente a quantidade de informação que o utilizador disponibiliza para os navegadores, pois toda sua atividade está a ser mapeada através de sua localização, históricos de pagamentos, histórico de acessos, senhas e diversos outros dados sensíveis. Outro destaque vai para o processo de registro, manipulação e não remoção dos cookies utilizados, que também pode vir a apresentar um alerta sobre o uso abusivo de políticas de segurança e carece de mais aprofundamento. Em questões de segurança de acesso pode-se verificar que os navegadores são compostos de critérios para bloqueio a endereços maliciosos. Tabela 5.6: Configurações iniciais dos navegadores. Configurações Chrome Firefox Opera Integração com conta de serviços próprios Ativado Ativado Ativado Atualizações automáticas Ativado Ativado Ativado Bloqueadores de conteúdo malicioso Ativado Ativado Ativado Registro e manipulação de cookies Ativado Ativado Ativado Deletar registros de cookies ao fechar o navegador Desativado Desativado Desativado Salvar senhas/Logins Ativado Ativado Ativado Salvar histórico de pagamentos Ativado Ativado Ativado Salvar histórico de pagamentos com criptomoedas Ativado Ativado Ativado Salvar histórico de navegação Ativado Ativado Ativado Localização do utilizador Ativado Ativado Ativado Coleta de dados técnicos Ativado Ativado Ativado Coleta de dados do utilizador Ativado Ativado Ativado Essas configurações são apenas modificações simples que podem vir a ser alteradas por qual80 5.4. SUMÁRIO Tabela 5.9: Resumo dos dados analisados dos motores de busca. Etapa de Investigação Caract. Class. Bing Google Yahoo DuckGo Gibiru Motores de Busca Exposição de dados sensíveis ED E Sim Sim Sim Sim Sim Coleta e armazenamento de dados ED E Sim Sim Sim Não Não Compartilhamento dos dados ED E Sim Sim Sim Não Não Redirecionamento eficiente TE E Sim Sim Sim Não Não Resultados sem datas V E Não Não Não Sim Sim (*) Para as características de verificação de cada etapa, serão adotados os seguintes critérios: ED - Exposição de dados, V - Vulnerabilidades e TE - Tráfego Encriptado. (**) Para os níveis de classificação serão adotados os critérios: E - Existente e I - Inexistente. De uma forma geral conclui-se: •o comportamento de navegação é o mesmo ao comparar os sistemas operativos Linux e Windows; •todos os navegadores possuem algum tipo de vulnerabilidade; •todos os navegadores expõem dados sensíveis dos utilizadores; •todos URLs e motores de busca também expõem os dados dos utilizadores; •todos os navegadores, URLs e motores de busca armazenam e compartilham as informações recolhidas dos utilizadores com endereços terceiros; •possibilidade de abusos nas políticas de privacidade aceites pelos utilizadores; •todos os navegadores fazem uso de protocolos de comunicação segura. 5.4 Sumário A primeira parte do capítulo apresentou a taxonomia para realização dos testes, de forma que os resultados da metodologia exposta no Capítulo 4 fossem evidenciados. A segunda parte foi responsável por mostrar uma análise de todo o tráfego gerado pela simulação de uma navegação na Internet. A análise buscou apresentar as diferenças de acesso entre dois sistemas operativos, 87 CAPÍTULO 5. CENÁRIOS DE TESTES E RESULTADOS com três tipos de navegadores e vários motores de busca para evidenciar as mudanças do processo de coleta e exposição dos dados do utilizador na experiência de navegação na Internet com a implantação da comunicação segura entre cliente e servidor. 88 Capítulo 6 Conclusões Neste capítulo apresenta-se um resumo do trabalho desenvolvido e discutido ao longo desta dissertação. Apresentam-se também temas possíveis para serem desenvolvidos em trabalhos futuros. 6.1 Resumo do Trabalho Desenvolvido As ferramentas específicas que procuram caracterizar o protocolo HTTPS, objeto de estudo dessa dissertação, foram aplicadas através da medição passiva de tráfego na qual os dados são armazenados para depois serem tratados. A utilização de diversas ferramentas foi necessária para ter perspectivas diferentes da mesma informação, de maneira a possibilitar a coleta de dados relevantes, já que o uso de apenas uma única ferramenta pode apresentar limitações quanto aos resultados. A junção do Tstat, com as ferramentas Libtrace, Libprotoident, SSLAnalyzer e Fiddler, que utilizam DPI e LPI por exemplo, foi essencial para o mapeamento de dados através de técnicas de extração de assinaturas do protocolo SSL/TLS durante o estabelecimento da conexão segura entre cliente/servidor. O primeiro objetivo deste trabalho procurou analisar quais os impactos significativos promovidos pelo protocolo HTTPS na conexão do utilizador através de uma simulação do processo de navegação. Pelas observações realizadas, pode-se concluir que o utilizador não percebe as alterações na sua forma de acesso. Isso ocorre porque a maioria das questões que envolvem o protocolo HTTPS não estão facilmente acessíveis e a falta de conhecimento técnico por parte do utilizador comum para buscá-las contribui para que essa informação não seja percebida. Algumas aplicações específicas visam prestar um auxílio para que essa informação chegue ao utilizador mas, por vezes, 89 CAPÍTULO 6. CONCLUSÕES este apenas se preocupa em ter uma conexão eficiente. Constata-se que a navegação se tornou realmente segura e existe uma preocupação em proteger a conexão com servidores Web, as informações dos utilizadores e o conteúdo acessado de atores externos. Mas por outro lado, essas informações acabam por ser coletadas, armazenadas e compartilhadas por navegadores, endereços eletrônicos e motores de busca sem nenhum tipo de controle por parte do utilizador. A conexão passou a ser segura, mas a exposição das informações dos utilizadores aumentou significativamente. Também, as políticas de privacidade adotadas aparentam ser abusivas e muitas vezes o utilizador aceita os termos sem ter noção do que está a autorizar. O segundo objetivo visava verificar se os sites de busca realizam redirecionamento dos utilizadores de forma efetiva para endereços mais seguros. Conclui-se que a utilização de cookies está ligado diretamente a esse processo, visto que quanto maior a manipulação por parte de navegadores e motores de busca, maior é quantidade de endereços seguros ao qual o utilizador é redirecionado. O terceiro objetivo consistia identificar e comparar comportamentos no acesso realizado pelo utilizador a partir de um computador pessoal com sistemas operacionais diferentes. No entanto, conclui-se que para sistemas operativos Linux e Windows não existem diferenças ou impactos no processo de navegação. Para além do cumprimento dos objetivo estabelecidos, este projeto também permitiu alertar para a existência de uma grande exposição dos dados do utilizador. Além da exposição, é notado o compartilhamento com diversas bases de armazenamento de dados e como mencionado anteriormente, o utilizador não tem conhecimento do destino ao qual seus dados são enviados, para quem e nem por quanto tempo eles estarão disponíveis. Surge então a questão: De que adianta proteger a conexão, se tantas outras informações são disponibilizadas sem controle? Diante disso, a RGPD torna-se uma forma essencial para combater essa grande exposição. 6.2 Trabalhos Futuros Com relação a trabalhos futuros sugere-se a ampliação do número de navegadores de forma a identificar se o comportamento se assemelha aos que foram analisados. Propõe-se também a investigação em sistemas operacionais de dispositivos móveis, como o Android e o IOS, e a verificação se existem diferenças significativas dos resultados em comparação aos sistemas operacionais de computadores. Por fim, sugere-se a utilização de ferramentas de machine learning na tentativa de automatizar 90 6.2. TRABALHOS FUTUROS a investigação de mais informações que estão a ser expostas e a criação de um dicionário padrão de exposição de dados para esse tipo de pesquisa. 91 CAPÍTULO 6. CONCLUSÕES 92 Apêndices 93 94 Apêndice A TSTAT A.1 Core TCP Set Figura A.1: Saídas Core TCP Set. 95 APÊNDICE A. TSTAT A.2 TCP Layer 7 Set Figura A.2: Saídas TCP Layer 7 Set. A.3 Coluna 42 - Protocolos Identificados Figura A.3: Lista de protocolos de aplicação. 96 Bibliografia [1] "Relatório de Cripotografia HTTPS na WEB - JUL/2019". Disponível em https://transparencyreport.google.com/https/overview. [2] NC Solutions. "Global Encryption - Trends Study". Ponemom Institute, 2018. [3] Tanenbaum, Andrew S. "Redes de computadores", 5a ed., Rio de Janeiro: Pearson, 2010. [4] Kurose, James F. e ROSS, Keith W. "Redes de Computadores e a Internet: Uma Abordagem Top-Down"; tradução Arlete Simille Marques; revisão técnica Wagner Luiz Zucchi. 3a ed., São Paulo: Pearson, 2006. [5] Harrison, M. A., Ruzzo, W. L., e Ullman, J. D. "On protection in operating systems". Proceedings of the 5th ACM Symposium on Operating Systems Principles, (SOSP) 1975. [6] Pfleeger CP., Pfleeger SL. "Security in computing. 4a ed. Estados Unidos: Prentice Hall; 2007 [7] Kallam, S. "Diffie-Hellman:Key Exchange and Public Key Cryptosystems". Math and Computer Science Department Indiana State University, 2015. [8] Melo, Sandro. "Exploração de Vulnerabilidades de Redes TCP IP", 3a ed., Rio de Janeiro: Alta Books, 2017. [9] Dlamini, M. T., Eloff, J. H. P., e Eloff, M. M."Information security: The moving target". Computers and Security - Elsevier, 2009. [10] Velan, P., Čermák, M., Čeleda, P., e Drašar, M. "A survey of methods for encrypted traffic classification and analysis". International Journal of Network Management, 2015. [11] Torres, G. "Redes de Computadores: Curso Completo". Rio de Janeiro: Axcel Books, 2001. [12] Felippetti, M. Aurélio. "CCNA 6.0 Guia Completo de Estudo". Florianópolis: Visual Books, 2016. 103 BIBLIOGRAFIA [13] Stenberg, D. "HTTP2 Explained. Computer Communication Review". disponível em: https://daniel.haxx.se/http2/. [14] Satapathy, A., e Livingston, J. "A Comprehensive Survey on SSL/ TLS and their Vulnerabilities". International Journal of Computer Applications, 2016. [15] Roskind J. "QUIC: Design Document and Specification Rationale". Disponível em: https://goo.gl/eCYF1a. [16] Stallings, W. "Criptografia e Segurança de Redes de Redes: Princípios e Práticas". tradução Daniel Vieira; revisão técnica Paulo Barreto e Rafael Misoczki. 6a ed., São Paulo: Pearson, 2015. [17] Elgohary, A., Sobh, T. S., e Zaki, M. "Design of an enhancement for SSL/TLS protocols". Computers and Security - Elsevier, 2006. [18] Finsterbusch, M., Richter, C., Rocha, E., Müller, J. A., e Hänßgen, K. A survey of payloadbased traffic classification approaches. IEEE Communications Surveys and Tutorials, 2014. [19] Barlet-Ros Co-Advisor, P., e Solé-Pareta, J. "Network Traffic Classification: From Theory to Practice Valentín Carela-Español. Universidade da Catatalunha, 2014. [20] Karagiannis, T., Papagiannaki, K., e Faloutsos, M. “Blinc: Multilevel traffic classification in the dark,” Special Interest Groupon data Communication, (SIGCOMM), 2005. [21] "Performance Measurement Tools Taxonomy". Disponível em: http://www.caida.org/tools/taxonomy/performance.xml. [22] Kitchenham, B. e Charters, S. “Guidelines for performing Systematic Literature Reviews in Software Engineering", Engineering, vol. 2. Durham, 2007. [23] "Infosheet 2016 - Center for Applied Internet Data Analysis". Disponível em: http://www.caida.org/publications/posters/eps/caida-infosheet-2016.pdf. [24] Amara, S., Macedo, J., Bendella, F., e Santos, A. "Group formation in mobile computer supported collaborative learning contexts: A systematic literature review". Educational Technology and Society, 2016. [25] Liu, C., Han, J., e Wei, Q. "Browser Identification Based on Encrypted Traffic". International Conference on Communications, Information Management and Network Security, (Cimns), 2016. [26] Gill, P., e Williamson, C. "Characterizing Organizational Use of Web-based Services: Methodology, Challenges, Observations, and Insights". ACM Journal, 2015. 104 BIBLIOGRAFIA [27] Kim, S. M., Goo, Y. H., Kim, M. S., Choi, S. G., e Choi, M. J. "A method for service identification of SSL/TLS encrypted traffic with the relation of session ID and Server IP". 17th Asia-Pacific Network Operations and Management Symposium: Managing a Very Connected World, (APNOMS), 2015. [28] Durumeric, Z., Kasten, J., Bailey, M., e Halderman, J. A. "Analysis of the HTTPS certificate ecosystem". Proceedings of the ACM SIGCOMM Internet Measurement Conference, ACM IMC, 2013. [29] Muehlstein, J., Zion, Y., Bahumi, M., Kirshenboim, I., Dubin, R., Dvir, A., e Pele, O. "Analyzing HTTPS encrypted traffic to identify user’s operating system, browser and application". IEEE Access, 2017. [30] Fang, C., Liu, J., e Lei, Z. "Fine-Grained HTTP Web Traffic Analysis Based on Large-Scale Mobile Datasets". IEEE Access, 2016. [31] Manzoor, J., Drago, I., e Sadre, R. "How HTTP/2 is changing web traffic and how to detect it". Proceedings of the 1st Network Traffic Measurement and Analysis Conference, (TMA), 2017. [32] Wijnants, M., Marx, R., Quax, P., e Lamotte, W. "HTTP/2 Prioritization and its Impact on Web Performance". International World Wide Web Conference Committee - ACM Library, 2018. [33] Husák, M., Cermák, M., Jirsík, T., e Pavelčeleda, P. P. "HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting". EURASIP Journal on Information Security, 2016. [34] Felt, A. P., Barnes, R., King, A., Palmer, C., Bentzel, C., Tabriz, P. "Measuring HTTPS adoption on the web". 26th USENIX Security Symposium, 2017. [35] Arnbak, A., Asghari, H., Van Eeten, M., e Van Eijk, N. "Security collapse in the HTTPS market". Communications of the ACM, 2014. [36] Naylor, D., Finamore, A., Leontiadis, I., Grunenberger, Y., Mellia, M., Munafò, M., e Steenkiste, P. "The Cost of the “S” in HTTPS". 10th International Conference on Emerging Networking EXperiments and Technologies - ACM Digital Library, (CoNEXT), 2014. [37] Gonzalez, R., Soriente, C., e Laoutaris, N. "User profiling in the time of HTTPS". Proceedings of the ACM SIGCOMM Internet Measurement Conference, IMC, 2016. [38] Kausar, F., Aljumah, S., Alzaydi, S., e Alroba, R. "Traffic Analysis Attack for Identifying Users’ Online Activities". IEEE Computer Society, 2019. 105 BIBLIOGRAFIA [39] Al Khater, N., e Overill, R. E. "Network traffic classification techniques and challenges". The 10th International Conference on Digital Information Management,(Icdim), 2015. [40] Finsterbusch, M., Richter, C., Rocha, E., Müller, J. A., e Hänßgen, K. "A survey of payloadbased traffic classification approaches". IEEE Communications Surveys and Tutorials, 2014. [41] Alcock, S., e Nelson, R. "Libprotoident: Traffic Classification Using Lightweight Packet Inspection". WAND - Network Research Group. 2011. [42] Alcock, S., Lorier, P., e Nelson, R. "Libtrace: A Packet Capture and Analysis Library". International Conference on Parallel and Distributed Computing, Applications and Technologies - PDCAT. Nova Zelândia, 2008. [43] Mellia, M., Carpani, A., e Cigno, R. Lo. "TStat: TCP STatistic and Analysis Tool". LNCS (Vol. 2601). Torino, 2003. [44] Lawrence, E. "An Overview of Telerik Fiddler". Disponível em https://www.telerik.com/blogs/an-overview-of-telerik-fiddler. [45] "Pcapplusplus - Feature Overview", Disponível em https://pcapplusplus.github.io/docs/features. [46] "Robot Framework for Web Tests". Disponível em https://robotframework.org. [47] "Selenium Library - Python". Disponível em https://selenium-python.readthedocs.io. [48] "Pycharm - IDE". Dispovível em https://www.jetbrains.com/pycharm/. [49] Grikorik, Y. "High Performance - Browser Networking". Estados Unidos: O’Reilly, 2013. [50] "Chrome e outros navegadores vão abandonar protocolo usado há quase 20 anos"Disponível em https://olhardigital.com.br/noticia/chrome-e-outros-navegadores-vao-abandonarprotocolo-usado-ha-quase-20-anos/79202. 106