- A comunicação na internet tem uma estrutura em que vários níveis dividem o processamento dos pacotes, e graças aos protocolos em camadas o desenvolvedor não precisa lidar diretamente com os detalhes de implementação de transporte, roteamento e segurança
- Uma requisição HTTP segue um fluxo em etapas que começa na criação da mensagem pelo navegador e passa por consulta DNS, handshake TCP de 3 vias, roteadores e resposta do servidor
- O HTTP básico envia cabeçalhos e corpo em texto puro, por isso é vulnerável a escuta e falsificação de servidor; para cobrir essa limitação, foi adicionada uma camada de segurança
- HTTPS é HTTP com criptografia e verificação via TLS, e o handshake TLS é o processo de alinhar versão, cipher suite, certificado e informações de troca de chaves para criar uma chave de sessão simétrica
- O TLS 1.3 remove RSA e cipher suites e parâmetros vulneráveis, reduzindo as opções para formar um handshake mais simples, rápido e seguro do que os anteriores
Modelo em camadas para entender a comunicação na internet
- A internet é uma rede de redes de computadores interconectadas, e “Internet” significa literalmente “entre redes”
- Ela opera como uma rede em malha de comutação de pacotes, com uma estrutura de best-effort delivery que não garante nem a entrega do pacote nem o tempo de chegada
- Como várias camadas de abstração cuidam nos bastidores de tentativas de reenvio, garantia de ordem, remoção de duplicidade e segurança, a internet parece funcionar de forma fluida
- Cada camada fornece uma função específica, e diferentes protocolos podem implementar essa função
- Graças a essa modularização, trocar o protocolo de uma camada nem sempre afeta os protocolos das outras camadas
Papel de cada camada da rede
- A Application layer processa a lógica específica da aplicação; sua unidade de comunicação é a mensagem, e o HTTP é o exemplo mais representativo
- A Security layer fornece criptografia e autenticação; sua unidade de comunicação é o record, e o TLS é um exemplo
- A Transport layer cuida da transmissão confiável de dados; usa TCP segment ou UDP datagram e identifica comunicações por números de porta
- A Network layer roteia pacotes pela internet; usa endereços IP como identificadores
- A Link layer gerencia a comunicação próxima ao meio físico; usa frame e identifica dispositivos por endereços MAC
- A Physical layer transmite bits fisicamente entre dispositivos; fibra óptica e cabos Ethernet são exemplos
Fluxo de uma requisição HTTP
Como os pacotes chegam ao servidor
- Quando o cliente envia a requisição, os pacotes de dados não vão direto ao servidor; eles passam por vários equipamentos de rede e roteadores até encontrar um caminho para o gateway da rede do servidor
- Depois disso, a Link layer cuida da transmissão no trecho local
-
Etapas de como o texto cruza a internet
- O dispositivo cliente encapsula os dados da requisição HTTP em um TCP segment e depois os envolve novamente em um IP packet
- Se a conexão for cabeada, isso ainda é encapsulado em um Link layer frame, como um Ethernet frame
- O frame é transmitido pela rede local até o roteador do cliente
- O roteador local recebe o frame, remove o cabeçalho da Link layer e processa o IP packet
- O roteador olha o endereço IP de destino e decide o próximo hop
- O pacote é encaminhado pela próxima rede passando por um ou mais roteadores intermediários, e cada roteador repete o processo de decidir e encaminhar para o próximo hop
- Eventualmente, o pacote chega a um roteador na mesma rede do servidor de destino
- Esse roteador toma a decisão final de roteamento e envia o pacote para o dispositivo local correspondente ao servidor
- O roteador do servidor entrega o pacote ao servidor pelo segment da rede local
- A Link layer garante que o frame seja entregue corretamente à interface de rede do servidor
- O servidor recebe o frame, extrai o IP packet e processa o TCP segment encapsulado para reconstruir a requisição HTTP original
- O processo da Network layer de enviar pacotes pela internet também é usado em etapas anteriores, como resolução de nome de domínio e handshake TCP
Resposta do servidor e renderização no navegador
- Depois de processar a requisição HTTP, o servidor envia uma resposta HTTP ao cliente
- A resposta inclui a versão do HTTP em uso, um código de status como
200 ou 404, cabeçalhos de resposta e um corpo com dados como o HTML da página solicitada ou JSON
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456
Example Page
Hello, world!
- O cliente recebe e processa a resposta HTTP
- O navegador interpreta o HTML e renderiza o conteúdo na tela
- Se a resposta tiver recursos adicionais, como imagens, CSS e JavaScript, o navegador envia novas requisições HTTP seguindo o mesmo processo
Problemas de segurança do HTTP e o HTTPS
- O HTTP básico não tem nenhuma segurança
- Quem estiver ouvindo a conexão pode ver 100% dos dados trocados
- Se alguém fingir ser o servidor, o cliente pode enviar informações importantes para o destino errado
- HTTPS é a forma de HTTP com criptografia e verificação adicionadas
- Existem várias formas de tornar a comunicação HTTP segura, mas a implementação mais usada hoje é o TLS
- O TLS permite que cliente e servidor validem a identidade um do outro e criptografem o payload de um jeito que ambos consigam descriptografar
- O fluxo de uma requisição HTTPS é igual ao fluxo de uma requisição HTTP visto antes, mas com a adição de uma Security layer entre a Application layer e a Transport layer
- O handshake TLS normalmente usa TCP
O que o handshake TLS negocia
- O handshake TLS é o processo em que cliente e servidor entram em acordo sobre vários elementos que serão usados na comunicação
- Entre esses elementos está o conjunto de algoritmos usados para verificação de mensagens, compressão e criptografia
- Esse conjunto de algoritmos é chamado de cipher suite
- Em sentido estrito, cipher suite exclui o algoritmo de compressão, mas neste texto o termo é usado para o conjunto completo
- Os componentes de exemplo são os seguintes
- Compression algorithm: forma de comprimir os dados no wire; Gzip e Brotli são exemplos, e hoje o Brotli é o mais usado
- Key exchange algorithm: forma de trocar com segurança chaves criptográficas em um canal público; ECDHE-RSA e ECDHE-ECDSA são exemplos, e hoje o ECDHE é o mais usado
- Authentication algorithm: forma de autenticar a identidade das partes durante o handshake; RSA e ECDSA são exemplos, com RSA amplamente usado e ECDSA ganhando popularidade
- Symmetric encryption algorithm: forma de criptografar os dados entre cliente e servidor; AES-128-GCM e AES-256-GCM são exemplos, e o AES-GCM oferece segurança forte e eficiência
- MAC algorithm: forma de garantir a integridade e a autenticidade da mensagem; HMAC-SHA256 e HMAC-SHA384 são exemplos, com HMAC-SHA256 e o modo GCM das cipher suites mais recentes em uso
- Cliente e servidor entram em acordo sobre a cipher suite e trocam informações de seed aleatória e do certificado SSL para criar uma chave simétrica que será usada na criptografia e verificação das mensagens
- A explicação do handshake TLS tem como fonte a Cloudflare
Etapas do handshake TLS tradicional
-
Client Hello
- O cliente envia ao servidor uma mensagem TCP contendo as cipher suites compatíveis, a versão de TLS suportada e um número aleatório chamado Client Random
-
Server Hello
- O servidor responde com uma mensagem TCP contendo a versão de TLS escolhida, o algoritmo de cipher suite selecionado e o Server Random
-
Certificate Verification
- O cliente verifica o certificado SSL do servidor por meio de uma Certificate Authority e obtém a public key do servidor
-
Premaster Secret Generation
- O cliente cria o premaster secret, criptografa-o com a public key do servidor e o envia ao servidor
-
Decryption
- O servidor usa a private key para descriptografar o premaster secret
-
Session Key Creation
- Cliente e servidor usam o Client Random, o Server Random e o premaster secret para criar a session key
-
Client Ready
- O cliente envia a mensagem
finished, criptografada com a session key
-
Server Ready
- O servidor envia a mensagem
finished, criptografada com a session key
-
Secure HTTP Communication
- A partir daí, os dois lados se comunicam com criptografia simétrica segura usando a session key
O que mudou no TLS 1.3
- O handshake TLS explicado acima descreve o processo das versões antigas do TLS; pelo padrão atual, o TLS 1.3 já considera esse método obsoleto
- O TLS 1.3 e posteriores não oferecem suporte a RSA e a várias cipher suites por motivos de segurança
- As versões mais novas reduziram bastante as opções, ficando mais simples, seguras e rápidas
- No TLS 1.3, os conceitos centrais permanecem
- o handshake serve para entrar em acordo sobre método de compressão, autenticação do servidor e troca de chaves
- ele gera chaves de criptografia simétrica para proteger os dados dos pacotes trocados via TCP
- O TLS 1.3 não oferece suporte a cipher suites e parâmetros vulneráveis a ataques, e reduz o handshake para torná-lo mais rápido e seguro
-
Etapas básicas do handshake TLS 1.3
- Client hello: o cliente envia a versão do protocolo, o Client Random e a lista de cipher suites
- no TLS 1.3, o suporte a cipher suites inseguras foi removido, então o número de opções possíveis caiu bastante
- o Client hello também inclui parâmetros que serão usados para calcular o premaster secret
- o cliente assume que conhece o método de key exchange preferido do servidor, o que é mais provável por causa da lista reduzida de cipher suites
- essa estrutura reduz o comprimento total do handshake em comparação com o TLS 1.0, 1.1 e 1.2
- Server generates master secret: o servidor já recebeu o Client Random, os parâmetros do cliente e a cipher suite, e pode gerar diretamente o Server Random para criar o master secret
- Server hello and
Finished: o Server hello inclui o certificado do servidor, a assinatura digital, o Server Random e a cipher suite escolhida
- como o servidor já tem o master secret, ele também envia a mensagem
Finished
- Final steps and client
Finished: o cliente verifica a assinatura e o certificado, gera o master secret e então envia a mensagem Finished
- Secure symmetric encryption achieved: a partir daí, a criptografia simétrica segura está estabelecida
1 comentários
Opiniões no Hacker News
Como leigo, fico curioso: quando não consigo acessar um site específico ou a internet inteira, não entendo por que é tão difícil saber em que trecho ocorreu a falha
Muitas vezes não fica claro se é um erro de configuração de rede na minha máquina local, um problema na conexão Wi‑Fi até o roteador, um problema no cabo entre o roteador e o ISP, uma falha em larga escala do ISP ou uma falha no site que estou tentando acessar
Já ouvi uma explicação vaga de que isso acontece porque as requisições são roteadas por caminhos não determinísticos, mas ela não convence muito. Fico me perguntando: se algum link no caminho quebra, por que o último link que ainda estava funcionando não poderia avisar de volta “sua mensagem chegou até aqui, mas falhei ao tentar enviá-la para a próxima etapa”?
As configurações variam muito, não há como saber qual configuração era intencional, e é arriscado fazer suposições com base em causas comuns e acabar apresentando uma resposta completamente errada
Por exemplo, se nem o servidor DNS nem o host de destino respondem, você poderia dizer que é um erro de configuração do roteador ou uma falha do ISP, mas a causa real pode ser um cliente VPN que alterou a tabela de roteamento local e o servidor DNS e depois não restaurou tudo ao encerrar. A questão é: como o diagnosticador saberia se aquilo era uma mudança temporária ou uma configuração permanente?
As aplicações não veem mensagens ICMP a menos que configurem o socket dessa forma. Isso é tratado como um erro “temporário”; no Linux, é configurado com a opção de socket
IP_RECVERRQuando se trabalha na camada 7, coletar erros dessa camada não tem muito valor. O erro Destination Unreachable exposto para cima se encaixará na lógica de tratamento de falhas que você já terá, e nesse caso as outras camadas farão novas tentativas para destinos inalcançáveis, então provavelmente aparecerá como timeout
Estes RFCs ajudam a entender como a camada TCP trata erros ICMP: https://www.rfc-editor.org/rfc/rfc1122#page-103
A seção 4.2.3.9 diz que mensagens Unreachable são condições de soft error, portanto o TCP não deve encerrar a conexão e deve fornecer a informação à aplicação. O TCP pode repassar isso para a camada de aplicação por meio da rotina ERROR_REPORT, ou registrar a mensagem e só reportá-la à aplicação quando a conexão TCP expirar por timeout
Também há um documento que aborda com mais detalhes como as pilhas interagem para estudar ICMP como vetor de ataque contra TCP: https://www.rfc-editor.org/rfc/rfc5927
Se não for possível alcançar o próprio servidor DNS, então há algum erro de rede entre o usuário e esse servidor. Normalmente, o diagnóstico é feito executando as etapas manualmente: verificar se dá para dar ping no endereço do servidor DNS, se esse servidor DNS consegue resolver aquele host e o que acontece com outros servidores DNS. Certos nomes também podem ser excluídos por políticas da empresa
Se quiser investigar mais a fundo, ferramentas de linha de comando como
ping,tracerouteedigsão úteisO MTR é como um ping + traceroute que roda continuamente em tempo real, com cada hop mostrado separadamente
Quando percebi pela primeira vez que um nó na rede da Xfinity tinha caído, isso também foi consistente: no mesmo MTR, eu conseguia ver que pelo menos da minha rede até o modem estava tudo normal. Não vi muitas ferramentas que mostrem tão bem quanto o MTR um aumento de latência de centenas de ms em algum hop além do ISP
Ele não resolve todos os problemas, mas fornece a latência separada por hop, então vale a pena conferir
Para dizer “o problema está aqui”, é preciso fazer suposições sobre como o sistema operacional, o hardware e a rede estão configurados
Ao acessar um site, primeiro é preciso obter no DNS o endereço IP do servidor web, mas de onde o navegador obtém o IP do DNS já é algo complexo. Ele pode estar configurado no navegador, no sistema operacional, no roteador ou no modem; se não estiver configurado, vem do servidor DHCP ao qual o roteador se conectou. Esse servidor pode ser o DHCP do ISP ou outro roteador dentro de uma organização
Se o DNS parece estranho, é fácil saber que o IP está errado, mas é difícil dizer de onde esse IP veio. No SSL, também pode ser que o certificado do servidor esteja incorreto, ou que o certificado no meu computador esteja incorreto
Algo possivelmente relacionado: também há exemplos interativos que acompanham byte a byte em detalhe o TLSv1.2 e o TLSv1.3
Se você quiser aprender mais sobre TLS, é um material de que gosto muito e recomendo fortemente
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
Fico curioso se há mais exemplos de textos escritos por essa perspectiva. Gosto de textos explicados “como se fossem para um engenheiro mediano”, independentemente do nível de experiência
Em geral são muito úteis, porque dá para aprender peças que não estavam totalmente claras ou obter mais exemplos para usar ao explicar a outras pessoas
Exemplos:
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/ssl/transport-layer-secu...
https://www.cloudflare.com/learning/performance/what-is-http...
A explicação de que “o cliente gera o premaster secret, criptografa com a chave pública do servidor e envia ao servidor” já não é verdade há muito tempo
Acrescenta-se que o processo recém-explicado é o de versões iniciais do TLS antigas em comparação com o TLS 1.3 moderno
A afirmação de que “as versões atuais do TLS (>1.3) não suportam RSA e várias suítes de cifras por motivos de segurança” está correta na parte de troca de chaves. Isso porque RSA não oferece forward secrecy
RSA ainda é usado para assinaturas e provavelmente é o tipo mais difundido em certificados x509
Pelo que sei, o Safari também aumentou recentemente o requisito de chave para 2048 bits em assinaturas RSA
Este texto parece um resumo feito por IA de um texto que explicava HTTPS de verdade. Os termos aparecem sem contexto
Não explica o que é um certificado nem como funciona a cadeia de confiança, e presume que o leitor conheça criptografia de chave pública. Explica 6 das 7 camadas do OSI, mas nem menciona o termo em si, e deixa de fora a camada de apresentação
Claro, o título já diz “mediocre”
Escrever não é meu forte, então aceito a crítica com gratidão. Meu texto ter passado de “ruim” para “é IA?” já é uma evolução
Pensei bastante sobre onde cortar a explicação, e considerei que criptografia de chave pública era uma boa fronteira, pois poderia ser explicada melhor em outro lugar. O mesmo vale para as várias camadas do OSI
Admito que eu deveria ter tratado de certificados e talvez de toda a cadeia de confiança
Não consigo encontrar um código que mostre a verificação da assinatura de
SHA256(client_hello_random + server_hello_random + curve_info + public_key)Conheço a teoria, mas ao tentar implementar algo dá problema. Seria bom ter um link para um programa de brinquedo que mostre como isso é feito na prática
Espero muito que não seja uma formulação do tipo “o certificado SSL do servidor contém a chave privada”. Ainda assim, o título é “Mediocre Engineer”
TLS <1.3 também não funciona da forma descrita no texto, e mesmo assim ele tenta misturar elementos mais novos do 1.3. A parte de DNS explica um resolvedor recursivo, mas o cliente não faz isso; provavelmente ele se comunica com um resolvedor stub
Erros como “Internet Layer”, a sugestão de que brotli é um algoritmo amplamente usado em compressão TLS ou em suítes de cifras, e “as versões atuais do TLS (>1.3) não suportam RSA” continuam aparecendo
Por causa desse tipo de blogspam, às vezes eu gostaria que houvesse downvote. O anúncio não incomoda a ponto de merecer flag, mas o nível é baixo. Talvez eu devesse escrever um texto menos mediocre e colocá-lo na primeira página do HN. Se eu ganhasse US$ 300 mil por ano, teria mais tempo
O conteúdo do texto, no geral, está um pouco desatualizado. Hoje, 30% das requisições web são HTTP/3, e também existe CORS, mas não há data de publicação
Eu normalmente desenvolvo sistemas SaaS implantados dentro de redes corporativas, e requisições CORS ficam perto de 0%. HTTP/3 também