Acabaram de surgir notícias de que Apple, Cloudflare, Fastly e Mozilla têm colaborado no aprimoramento da criptografia do mecanismo de identificação de nome de servidor de HTTPS no IETF 102 Hackathon, conforme indicado por um tweet de Nick Sullivan da Cloudflare. O tweet parabenizou a equipe de mixagem dos quatro gigantes da tecnologia, dizendo “Trabalho incrível” e compartilhando lá sob links para os servidores em funcionamento em esni.examp1e.net e cloudflare-esni.com .
Excelente trabalho no hackathon IETF 102 pela equipe SNI criptografada composta por pessoas de @Cloudflare @rapidamente @mozilla e @maçã . Agora existem implementações em BoringSSL, NSS e picotls.
Os servidores em funcionamento estão ativos em https://t.co/sLI9xLRjlK e https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 de julho de 2018
O IETF Hackathon é uma plataforma que convida jovens desenvolvedores e entusiastas de tecnologia a se unirem na elaboração de soluções para problemas relacionados à tecnologia enfrentados pelo usuário comum atualmente. Os eventos são de participação gratuita, abertos a todos e incentivam o trabalho em equipe ao invés da competição. O IETF Hackathon deste ano foi realizado em Montreal no dia 14ºe 15ºde julho. A conquista mais proeminente resultante disso, ao que parece, é a criptografia da Indicação de nome do servidor (SNI) do Transport Layer Security (TLS), um problema que tem atormentado os desenvolvedores na última década, um problema que os membros da Apple, Cloudflare, Fastly , e a Mozilla já propôs uma solução para.
Evento IETF Hackathon. IETF
Houve uma mudança global clara do protocolo de transferência de hipertexto (HTTP) para a indicação de nome do servidor de segurança da camada de transporte Protocolo de transferência de hipertexto seguro (TLS SNI HTTPS) na última década e meia. o problema que surgiu da otimização do sistema TLS SNI HTTPS foi a capacidade do hacker de usar SNI contra seu propósito para combinar a transferência de dados para descriptografia posterior.
Antes do desenvolvimento do SNI, era difícil estabelecer conexões seguras com vários servidores virtuais usando o mesmo primeiro handshake do cliente. Quando um endereço IP interagia com um servidor, os dois trocavam “olá”, o servidor enviava seus certificados, o computador enviava sua chave de cliente, os dois trocavam comandos “ChangeCipherSpec” e então a interação era finalizada quando uma conexão era estabelecida. Isso pode parecer fácil da maneira que acabou de ser dito, mas o processo envolveu múltiplas trocas e respostas que facilmente conseguiram se tornar bastante problemáticas conforme o número de servidores sendo comunicados aumentava. Se todos os sites usassem os mesmos certificados, isso não seria um grande problema, mas, infelizmente, raramente era o caso. Quando vários sites estavam enviando vários certificados de um lado para outro, era difícil para o servidor determinar qual certificado o computador estava procurando e na complexa rede de trocas, tornou-se difícil identificar quem enviou o quê e quando, encerrando assim toda a atividade com uma mensagem de aviso completamente.
O TLS SNI foi então apresentado em junho de 2003 por meio de uma cúpula da IETF e o propósito que serviu, de certa forma, foi criar etiquetas de nome para os computadores e serviços envolvidos na web de troca. Isso tornou o processo de troca de saudação entre servidor e cliente muito mais direto, pois o servidor foi capaz de fornecer os certificados exatos necessários e os dois puderam ter sua própria conversa sem se confundir sobre quem disse o quê. É um pouco como ter nomes de contato para bate-papos e não ficar confuso sobre a origem das mensagens, e também ser capaz de responder a cada consulta de forma adequada, fornecendo os documentos certos para o computador que precisar. Essa definição SNI é exatamente o que causou o maior problema com esse método de otimização do processo de troca.
A dificuldade que muitas empresas enfrentaram ao mudar para HTTPS foi a adaptação de muitos certificados ao formato SNI com endereços IP individuais para realizar solicitações para cada certificado. O que o TLS fez por eles foi simplificar a geração de certificados para responder a essas solicitações, e o que o SNI fez ainda mais foi remover a necessidade de endereços IP de certificados dedicados individualizados, lançando um sistema de identificação completo em toda a rede da Internet. O que veio com a atualização do século foi o fato de permitir que os hackers usassem os “nomes de contato” estabelecidos para monitorar e proteger a transferência de dados e extrair as informações de que precisam para descriptografar em um estágio posterior.
Embora o TLS permitisse o envio e recebimento de dados em um canal criptografado, com o SNI garantindo que eles chegassem ao destino correto, o último também fornecia meios para que os hackers monitorassem a atividade online e a correspondessem à sua origem, seguindo solicitações de DNS e endereços IP e fluxos de dados. Embora políticas de codificação SNI mais rígidas tenham sido implementadas passando informações de DNS através do canal TLS também, uma pequena janela permanece para que os hackers possam usar isso como um meio de identificação para seguir a parte da informação que eles gostariam de extrair e isolar para descriptografia. Servidores complexos que lidam com maior tráfego de dados criptografados TLS usam SNI de texto simples para enviar a comunicação em seus servidores e é isso que torna mais fácil para os hackers identificarem os canais e fluxos de informação que desejam seguir. Uma vez que um hacker é capaz de extrair as informações SNI dos dados de interesse, ele / ela é capaz de configurar um falso replay do comando em uma conexão TLS separada com o servidor, enviando as informações SNI roubadas e recuperando as informações que estava associado a ele. Houve várias tentativas de resolver esse problema de SNI no passado, mas a maioria foi contra o princípio de simplicidade em que o SNI opera para torná-lo um método de identificação conveniente para servidores.
De volta à cúpula que primeiro trabalhou para estabelecer esse método, os participantes de quatro gigantes da tecnologia voltaram à conferência em Montreal para desenvolver uma criptografia para o TLS SNI porque, apesar da maior eficiência no sistema adjacente multi HTTPS, a segurança ainda é uma preocupação. tanto quanto antes.
Para ocultar o SNI em TLS, um “Serviço Oculto” deve ser mantido sob a aparência de um “Serviço de Frente” que o hacker pode ver. Sem ser capaz de observar diretamente o serviço oculto, o hacker será enganado pelo disfarce de fachada que esconde em texto simples, sem ser capaz de identificar os parâmetros do serviço secreto subjacentes usados para retransmitir os dados criptografados. Conforme o observador segue a trilha do serviço de fronting, os dados são removidos do canal observado, pois ele é redirecionado para o serviço oculto pretendido, ponto em que o hacker terá perdido sua trilha. Visto que o servidor também será exposto ao serviço de fronting, conforme os dados chegam até lá, um segundo sinal SNI paralelo será enviado ao serviço de fronting para redirecionar os dados para o serviço oculto e neste processo de mudança de direção, o hacker irá ser perdido na web do servidor. Este mecanismo de bilhetes duplos é posteriormente desenvolvido em um bilhete combinado sob o mesmo SNI. Conforme uma parte dos dados é enviada para o servidor, os dados produzem um redirecionamento SNI cooperativo e os dois trabalham em conjunto para levar os dados criptografados TLS para onde precisam ir. Sem ser capaz de quebrar o serviço de fronting randomizado que cobre ambas as faixas SNI, o hacker não será capaz de seguir a trilha dos dados, mas o servidor ainda será capaz de conectar os dois e descriptografar o serviço oculto como o local final dos dados. Isso permite que os servidores continuem usando SNI para otimizar sua transferência de dados na criptografia TLS, garantindo que os hackers não possam tirar proveito do mecanismo SNI.
