Fraquezas de HTTPS. Parte 2

Qualquer sistema tem suas próprias forças e fraquezas. A primeira parte sobre os pontos fracos do HTTPS provocou uma reação ambígua de que "não são pontos fracos, foi planejado". A primeira parte dizia:

1. Sobre a impossibilidade de fornecer total confidencialidade e privacidade aos usuários (você ainda pode rastrear e banir os recursos que uma pessoa visita)
2. O fato de os certificados serem transmitidos por um canal aberto e geralmente conterem mais informações do que o recurso atual (por exemplo, o certificado bing.com contém informações sobre 72 recursos adicionais, incluindo ambiente de teste, teste, ambiente beta)

Vou continuar chamando isso de design de "fraquezas". Neste artigo, falaremos sobre outra fraqueza - centralização .

O HTTPS é baseado nos protocolos SSL e TLS (para simplificar, chamaremos SSL - embora SSL e TLS funcionem em diferentes níveis da pilha OSI). Portanto, falando de pontos fracos, teremos em mente a centralização do protocolo SSL.

Teoria

Comece com a teoria dos protocolos de criptografia. O problema com a criptografia moderna não é a criptografia em si, mas o que fazer com as chaves: como armazenar, transferir, criar e destruí-las com segurança.

A base do SSL é a criptografia assimétrica , que é determinada pela presença de duas chaves - se uma é criptografada, somente a segunda pode descriptografar e vice-versa.

A principal função da criptografia assimétrica é a autenticação , não a criptografia - é uma operação bastante cara e com muitos recursos para esse algoritmo. Criptografia rápida e eficiente é uma prerrogativa de algoritmos simétricos que usam a mesma chave para criptografia e descriptografia.

Uma das chaves permanece sempre de um lado para confirmar sua identificação, é chamada de privada . A chave pública está disponível para todos.

Imagine que existe uma vila do futuro em que Boris e Anya vivem. No futuro, chaves de tamanho diferente já são mais rigorosas e as habilidades do cérebro são desproporcionais em relação ao moderno, mas a abordagem, suponha, permanece a mesma.

Boris e Anya querem a privacidade de sua correspondência amorosa, então o principal para eles é uma troca segura de informações.

No caso mais simples, Boris envia a Anna uma mensagem: "vamos conversar". Anya gera dois pares de chaves de criptografia assimétricas - Pr1 privado e P1 público. “Vamos lá”, diz Anya, “eu sou Anya, aqui está minha chave pública, aqui está o algoritmo de criptografia simétrica que eu conheço.” Boris gera uma chave simétrica S1, criptografa-a com a chave pública Ani P1 (S1). Agora, nem o próprio Boris poderá descriptografar S1, porque apenas Anya pode descriptografar a mensagem com sua chave privada. No final, Boris e Ani têm uma chave de sessão simétrica para "garantir" a transmissão confiável de cartas entre si e impedir que os pais leiam sua correspondência.



Especificamente, não reduzi fortemente essas mensagens; na verdade, descrevemos o SSL Handshake com autenticação unidirecional [1]. Em dois sentidos, Boris gera seu par de chaves e transfere a chave pública para Anya.

Uma conclusão importante que já podemos fazer. Das três principais funções do protocolo SSL (autenticação, criptografia, integridade), a mais importante é a autenticação.

Está tudo bem até que um carteiro apareça ofendido pela vida, que seja ganancioso por ler as cartas de outras pessoas e, além disso, também seja inteligente. Entre Boris e Anya, surge a questão de como garantir agora que o carteiro não será capaz de ler suas mensagens. A resposta não é possível. O carteiro pode gerar seu próprio par de chaves, expor Boris sua chave "supostamente" de Ani, organizar dois canais criptografados e ler cartas com calma.



O dilema só pode ser resolvido pela presença de um determinado terceiro que pode garantir que a chave P1 pertence a Ana. Imagine que um conselho da vila apareça na vila, que mantém um registro de chaves públicas para os moradores. Anya pode pegar seu passaporte, sua chave pública P1, ir até lá e pedir para se registrar. Boris, quando recebe P1 de Ani, pode ir ao mesmo conselho da vila e checar o registro. Se a chave não coincidir, você pode começar a pecar no carteiro e culpá-lo por tudo sério, embora ele possa negar. Mas o problema ainda está sendo resolvido.



Não é um camilfo, é claro, Boris estava sempre carregando o conselho da vila. Portanto, a mesma autenticação pode ser feita com o próprio conselho da vila. O Conselho da Vila agora se autodenomina Autoridade de Certificação (CA) e possui seu próprio par de chaves, P10 e Pr10. Quando Anya chega com um passaporte e sua chave pública, a CA emite algo como um cartão que indica que essa é Anya, ela possui a chave pública P1, algumas outras informações, até o número do passaporte e adiciona outro campo para ela. assinaturas: pega todas as informações do cartão, remove o hash e criptografa com sua chave privada e a chama de assinatura digital. Seria possível fazer sem hash, mas a assinatura era muito grande. E a CA agora chama este cartão de certificado.

Agora, por trocar mensagens de amor com Anya, Anya dá a ele não apenas o nome e a chave pública, mas também o certificado. Boris só precisará ir ao conselho da vila uma vez e pedir sua chave pública. Qualquer informação que essa chave possa descriptografar será considerada, a priori, informação criptografada pelo conselho da vila. O carteiro não sabe o que fazer, está coberto por um vácuo existencial, resta apenas uma coisa: tentar pegar a chave privada do conselho da vila para que a vida volte à estaca zero.



Mas a vida não pára. Boris tem outra namorada em uma vila vizinha, depois outra. Ele precisa adicionar as chaves de outros conselhos da vila aos seus confiáveis, começa a manter seu registro nas chaves públicas das autoridades de certificação. Em seguida, ganha uma escala nacional e supranacional. Existem tantas organizações que assinam certificados que começam a mesclar em uma hierarquia. Aparece a Autoridade de Certificação Raiz, que não assina certificados de meros mortais, mas assina certificados de centros intermediários (Autoridade de Certificação Intermediária) depois de verificá-los. Agora, basta o Boris armazenar apenas as chaves públicas dos certificados raiz. E de Ani ele recebe não apenas um de seus certificados, mas também certificados de centros intermediários, a fim de verificá-los até o centro raiz.

Campo problema

O sistema se torna mais complexo e centralizado , e a partir desse momento o carteiro novamente tem uma chance.

Por um lado, o Boris inicialmente possui uma pequena lista de autoridades de certificação raiz (o Windows prescreve cerca de 50 autoridades de certificação raiz durante a instalação). Por outro lado, é difícil para ele acompanhar toda a cadeia de centros de certificação. O mais provável é que ele não verifique mais se o certificado de Ani de sua própria aldeia, por algum motivo, indica o centro de certificação de outro país. Ele confia em sua lista de centros de raiz em 99,9%. Um carteiro pode seguir o caminho mais brutal e, de alguma forma (engenharia social, hacking com penetração), registra sua falsa autoridade de certificação raiz no registro de Boris.



PS. Esse método de adição de um certificado falso do centro raiz é usado ativamente por pentesters (como eu) e atacantes. Para realizar testes de penetração e usar essa abordagem, minha ferramenta favorita é o ZapProxy (de código aberto e gratuito), que gerará um certificado de centro raiz (ele precisará ser instalado manualmente) e, em seguida, substitua esse certificado por um "semelhante". Isso permite não apenas visualizar o tráfego, mas também pará-lo, alterá-lo e enviá-lo ainda mais. Portanto, se a validação no seu sistema não estiver duplicada no servidor, você definitivamente terá problemas.

PPS O segundo problema levantado neste caso diz respeito a Ani e à indicação de um centro incompreensível em seu certificado. Anya pagou o dinheiro e gostaria que Boris a reconhecesse de qualquer maneira. Esse problema é resolvido usando a SSL Pinning [3], quando o aplicativo pode ser confiável apenas em um determinado certificado e em algumas autoridades de certificação. Isso é especialmente útil para aplicativos de alto risco. Com os navegadores, isso é mais complicado, para aplicativos móveis que funcionam com um ou dois serviços, mais fácil. Para fins de experimento, coloquei um certificado falso no meu Android, indiquei que o tráfego deveria passar pelo ZapProxy, que se destaca na rede da minha máquina, e analisei quantos aplicativos usam esse mecanismo. Quase ninguém, eu pude assistir e brincar com a substituição do tráfego por quase todos os aplicativos populares.

Então, voltando ao nosso carteiro. O governo não pôde deixar de apreciar seu zelo e deu a ele o status de um agente secreto com poderes superiores. Embora as chaves privadas das autoridades de certificação raiz estejam armazenadas em sete bloqueios, discos de gravação automática, proteção em vários níveis - até a autoridade do carteiro pode não ser suficiente para negociar com eles para fornecer a ele sua chave privada, a fim de gerar certificados válidos falsos em tempo real (embora tudo seja possível). Ele encontrou uma maneira mais fácil. Ele vai ao seu próprio conselho da vila, que está na hierarquia dos centros de certificação no nível mais baixo, e pressiona ou suborna o conselho da vila para assinar seu certificado como certificado de um centro de certificação intermediário. Agora ele pode ouvir o tráfego não apenas de Boris, mas em princípio de qualquer assunto. A pessoa provavelmente nem notará nada, o navegador não emitirá nenhum aviso.



Este é um problema conhecido, e a humanidade também está tentando combatê-lo. Se tais certificados falsos, centros intermediários e raiz comprometidos forem encontrados, esses certificados deverão ser marcados como revogados e comprometidos (Certificados Revogados). Isso significa que, além de armazenar certificados raiz, o Boris ainda precisa sincronizá-los com a lista on-line de certificados revogados - esse mecanismo é implementado através dos protocolos CRL (lista de revogação de certificados) e dos protocolos Online Certificate Status Protocol (OCSP) [4], que, a propósito, funcionam de acordo com canal desprotegido. Quando começamos a trabalhar ativamente no controle do tráfego OUTPUT usando o Dhound [5], notamos solicitações periódicas na porta 80. Se você banir essas solicitações no nível do firewall, algumas funções param de funcionar - por exemplo, o envio de email. O problema com certificados revogados é que já existem um grande número deles: em 2013, havia cerca de 3 milhões de certificados revogados [6], 23.000 certificados revogados pela Symantec somente em 2018 [7]. O Chrome desativou a função padrão de verificação completa de certificados revogados há alguns anos [8] para aumentar a velocidade de carregamento da página. Acontece que, se nossa operadora de correio for descoberta, o processo de impedir ainda mais suas ações será longo e nem sempre bem-sucedido.

Conclusões

O moderno sistema SSL está parcialmente fechado e centralizado , o que é definitivamente um dos seus pontos fracos. Enquanto isso, sempre haverá uma tentação para que as “pessoas poderosas deste mundo” obtenham seus benefícios, sem colocar a privacidade pessoal na prioridade. Ainda assim, seus próprios algoritmos de criptografia serão criados em nível nacional, na tentativa de isolar outros países de seus próprios cidadãos e fazê-lo nós mesmos. O comprometimento dos nós principais pode derrubar todo o sistema como um todo. A crescente entropia e complexidade do sistema levará cada vez mais ao seu estado instável e, finalmente, à morte do sistema.

Qual a saída? A transição de um sistema SSL fechado e centralizado para um mais transparente e distribuído, que por sua natureza não será capaz de dar vantagens a nenhuma das partes. Talvez essa seja uma solução semelhante à que implementa uma blockchain aberta.

PS. O protocolo SSL possui nuances mais complexas que não foram mencionadas no artigo. Mas o nível de informação foi suficiente para revelar uma de suas fraquezas. Existem outras fraquezas? Nos seguintes artigos, veremos.


Postado por Denis Koloshko, CISSP