monero.press

HTTP e HTTPS

Quando você digita um endereço e aperta Enter, o navegador começa uma conversa com um computador que pode estar do outro lado do mundo. Essa conversa segue um protocolo, o HTTP, e quase sempre vai protegida por outro, o TLS. Juntos, eles formam o HTTPS, a sigla que aparece no começo de quase todos os endereços da web. Escolha uma página do site de uma padaria fictícia e acompanhe a conversa inteira:

Antes de pedir qualquer coisa, o navegador abre uma conexão com o servidor, pelo TCP. Com https://, os dois ainda combinam uma chave secreta e o servidor prova quem é. Só então vai a requisição, uma pequena mensagem de texto que diz o que o navegador quer, e volta a resposta, com um código que diz se deu certo e, em seguida, a página. Troque para http:// e a página chega uma ida e volta antes, sem a criptografia, mas qualquer um no caminho pode ler a conversa inteira.

O HTTP nasceu em 1991 como um protocolo de uma linha só, e hoje carrega quase tudo o que passa pela internet: páginas, fotos, vídeos, as conversas dos aplicativos com os seus servidores. Neste guia, vamos começar pelo formato das mensagens e dos endereços, ver como uma página com dezenas de arquivos é carregada e como cookies e cache dão memória a um protocolo que esquece tudo. Depois, vamos entender desde o começo a criptografia que protege a conversa: chaves secretas, a troca de chaves de Diffie e Hellman, os certificados e o aperto de mãos do TLS. No fim, as versões mais novas, o HTTP/2 e o HTTP/3.

Uma conversa em texto

O HTTP é um protocolo de pedido e resposta. O navegador, o cliente, manda uma requisição; o servidor manda uma resposta; e cada requisição recebe uma única resposta definitiva. Na versão que ainda serve de base para as outras, o HTTP/1.1, as duas mensagens são texto puro, que dá para ler e até digitar à mão. Toque nas linhas para ver o que cada uma diz:

As duas mensagens têm a mesma forma: uma primeira linha, uma série de cabeçalhos, no formato Nome: valor, uma linha vazia e, às vezes, um corpo. Na requisição, a primeira linha diz o que se quer; na resposta, como foi. Os cabeçalhos carregam todo o resto: o tipo do conteúdo, o tamanho, a língua preferida, as regras de cache, os cookies. Há mais de duzentos cabeçalhos registrados, e qualquer um pode inventar outros, desde que os dois lados os entendam.

Dois cabeçalhos da resposta merecem atenção. O Content-Type diz o que é o corpo, com os tipos de mídia herdados do e-mail: text/html para uma página, image/jpeg para uma foto, application/json para os dados que os aplicativos trocam com os servidores. Sem ele, o navegador não saberia se deve mostrar os bytes como texto, como imagem ou oferecer um download. E o Content-Length diz onde a resposta termina. Quando o servidor não sabe o tamanho de antemão, como numa página montada aos poucos, ele manda o corpo em pedaços, cada um precedido do próprio tamanho, e avisa com Transfer-Encoding: chunked.

Muitas vezes o corpo nem é texto legível. Se o navegador anunciar em Accept-Encoding que sabe descomprimir, o servidor pode mandar a página comprimida, com gzip, com o Brotli, lançado pelo Google em 2015, ou com o Zstandard, que o Chrome passou a aceitar em 2024. Uma página de HTML costuma encolher para um quarto do tamanho, ou menos.

Endereços

Tudo começa com um endereço, o que os padrões chamam de URL. Ele junta, numa linha só, as informações de que o navegador precisa para chegar ao recurso: o protocolo, o servidor, a porta e o caminho. Digite um endereço, ou escolha um dos exemplos:

Cada parte vai para um lugar diferente. O nome do site vai para o DNS, que devolve o endereço IP do servidor, como vimos no guia sobre o DNS. A porta vai para o TCP: quando ela não aparece, vale a 80 para http e a 443 para https. O caminho e a consulta vão na primeira linha da requisição, e o nome do site vai de novo, no cabeçalho Host. Já o fragmento, depois do #, nunca sai do navegador: ele só diz em que ponto da página rolar.

Um endereço só pode usar letras sem acento, algarismos e alguns símbolos. No caminho e na consulta, o resto, incluindo os espaços, vira uma sequência de bytes escritos em hexadecimal, cada um depois de um %: São Paulo vira S%C3%A3o%20Paulo. Os bytes são os do UTF-8, que vimos no guia sobre o Unicode, e o espaço é o byte 20, em hexadecimal. Os navegadores mostram a forma bonita na barra de endereço e mandam a codificada pela rede. No nome do site, a regra é outra: as letras acentuadas viram a forma com xn-- que vimos no guia sobre o DNS.

Da CERN ao HTTP/1.1

Em março de 1989, Tim Berners-Lee, um físico que trabalhava com computação na CERN, o laboratório europeu de física de partículas, propôs um sistema para organizar a informação do laboratório em documentos ligados entre si. No fim de 1990, ele já tinha o primeiro servidor e o primeiro navegador funcionando, num computador NeXT, e o primeiro site, info.cern.ch. Em agosto de 1991, anunciou a World Wide Web publicamente, e, em abril de 1993, a CERN colocou o software em domínio público. O protocolo que ligava navegador e servidor era o HTTP, de Hypertext Transfer Protocol, protocolo de transferência de hipertexto.

A primeira versão, que depois ganhou o número 0.9, era de uma simplicidade extrema. Compare as três primeiras versões:

O HTTP/1.0 foi documentado em maio de 1996, quando a web já tinha explodido, e registrava o que os navegadores e servidores já faziam: cabeçalhos, códigos de status, tipos de conteúdo. Ele não chegou a ser um padrão formal. O HTTP/1.1 veio em janeiro de 1997, com duas mudanças que importam até hoje: o cabeçalho Host, que permitiu a um único servidor, num único endereço IP, hospedar milhares de sites, e as conexões persistentes, que evitam abrir uma conexão TCP para cada arquivo. A especificação foi revista em 1999, em 2014 e, por último, em 2022, quando ela foi dividida em três documentos: um com o significado das mensagens, comum a todas as versões, um sobre cache e um com o formato de texto do HTTP/1.1.

Métodos e formulários

A primeira palavra da requisição é o método, o verbo do pedido. O mais comum é o GET, “obter”, que pede uma cópia de um recurso. O HEAD pede só os cabeçalhos da resposta, sem o corpo, e serve para saber o tamanho ou a data de um arquivo sem baixá-lo. O POST manda dados para o servidor processar, como um formulário ou uma compra. E há outros, usados sobretudo pelos aplicativos que conversam com servidores: PUT para criar ou substituir um recurso, PATCH para alterar um pedaço dele e DELETE para apagá-lo.

A diferença entre eles não é só de nome. O GET e o HEAD são seguros: não devem mudar nada no servidor, e por isso o navegador, os buscadores e os caches podem repeti-los à vontade. O PUT e o DELETE não são seguros, mas são idempotentes: repetir o pedido dá no mesmo que fazê-lo uma vez. Já o POST não promete nada, e repetir um pode significar pagar duas vezes. É por isso que o navegador pergunta antes de reenviar um formulário quando você recarrega a página. Veja como um formulário vira uma requisição com cada método:

Nos dois casos, os campos vão codificados do mesmo jeito, como pares nome=valor separados por &, com os espaços trocados por + e os outros caracteres especiais por %XX. Os aplicativos costumam mandar os dados em outro formato, o JSON, com Content-Type: application/json, mas a ideia é a mesma: o método diz o que fazer, e o corpo leva os dados.

Códigos de status

A resposta começa com um número de três algarismos, o código de status. O primeiro algarismo diz a categoria: 2 é sucesso, 3 é redirecionamento, 4 é um erro de quem pediu e 5 é um erro do servidor. Os programas decidem o que fazer olhando só para o número; a frase ao lado, como Not Found, é para humanos, e o HTTP/2 nem a transmite mais. Toque nos códigos para ver quando cada um aparece:

Os redirecionamentos vêm com um cabeçalho Location, e o navegador segue para o novo endereço sozinho. É assim que um site que mudou de nome continua funcionando e que um endereço com http:// leva à versão com https://. O código 304, que não traz corpo nenhum, é a base da revalidação do cache, que veremos adiante. E o 418 tem uma história própria: ele nasceu numa especificação de 1º de abril de 1998, sobre um protocolo para controlar cafeteiras pela rede, e significava “sou um bule”. Tanta gente o usou como piada que ele acabou reservado, para nunca ser usado a sério.

Uma página, muitos arquivos

Uma página raramente é um arquivo só. O HTML traz referências a folhas de estilo, scripts, fontes e imagens, e o navegador precisa de uma requisição para cada um. Em 2025, a página inicial típica de um site pedia 75 arquivos no celular e 80 no computador, somando entre 2,5 e 3 megabytes. O desafio é buscar tudo isso depressa, e o maior inimigo não é a velocidade da conexão, mas o tempo de ida e volta: cada conexão nova custa idas e voltas antes do primeiro byte. Compare as versões do HTTP carregando uma página da padaria, com 13 arquivos, e use o controle abaixo da figura para mudar o tempo de ida e volta:

No HTTP/1.0, cada arquivo tinha a sua própria conexão, e cada conexão custava idas e voltas só para ser aberta: uma para o TCP e, com criptografia, outra para o TLS. O HTTP/1.1 manteve as conexões abertas, mas numa conexão só cabe uma requisição por vez: a próxima tem de esperar a resposta anterior chegar inteira. Para não ficar numa fila só, os navegadores abrem até seis conexões com o mesmo site, um número que não está em padrão nenhum e que o Chrome e o Firefox adotaram por conta própria. O HTTP/1.1 chegou a prever uma alternativa, mandar várias requisições seguidas sem esperar as respostas, mas as respostas tinham de voltar na mesma ordem, e um arquivo lento travava todos os outros. Na prática, quase ninguém a usou.

O HTTP/2, de 2015, resolveu isso de outro jeito: numa única conexão, ele corta as respostas em quadros e intercala os quadros de todas elas, como vários fluxos que correm lado a lado. Todas as requisições podem sair ao mesmo tempo, e uma resposta lenta não segura as outras. Mas ligue a perda de um pacote e veja o que acontece com ele: o TCP entrega os bytes na ordem, e, enquanto o pacote perdido não é reenviado, todos os fluxos da conexão ficam parados, até os que não tinham nada a ver com ele. É o bloqueio de cabeça de fila. O HTTP/3 existe em boa parte para resolver esse problema, como veremos no fim.

A figura simplifica bastante: não há controle de congestionamento, que deixa as conexões novas lentas no começo, e, nela, o navegador só descobre os arquivos depois de receber o HTML inteiro, enquanto um navegador de verdade começa a pedi-los assim que os encontra no meio do HTML. Mas as proporções são as de verdade: com uma ida e volta longa, como a de um celular com sinal ruim, o que pesa é quantas vezes o navegador precisa esperar.

Cookies

O HTTP não tem memória. Cada requisição é independente, e o servidor não tem como saber se duas delas vieram da mesma pessoa. Para uma página de notícias, tanto faz; para uma loja, com login e carrinho de compras, é um problema. A solução, inventada em 1994 por Lou Montulli, na Netscape, é o cookie: o servidor manda um pequeno texto no cabeçalho Set-Cookie, o navegador o guarda e o devolve no cabeçalho Cookie em todas as requisições seguintes para o mesmo site. Entre na loja da padaria e observe as mensagens:

O cookie de sessão não guarda o nome da Ana nem o carrinho: guarda só um número sorteado, e o servidor mantém uma tabela que liga cada número a uma sessão. Quem tiver o número passa pela Ana, e por isso ele deve ser tratado como uma senha. Os atributos do cookie ajudam a protegê-lo: Secure faz com que ele só viaje por HTTPS, HttpOnly o esconde dos scripts da página e SameSite=Lax faz com que, vindo de outro site, ele só vá quando você mesmo segue um link, e não nos pedidos que o outro site dispara por conta própria, como um formulário enviado às escondidas. Desde 2020, o Chrome trata todo cookie sem esse atributo como Lax.

Os cookies também servem para seguir as pessoas pela web. Se dezenas de sites carregam uma imagem ou um script do mesmo serviço de anúncios, esse serviço recebe o seu cookie em cada um deles, e sabe por onde você passou. São os cookies de terceiros. O Safari e o Firefox passaram a bloqueá-los ou a isolá-los por site. O Chrome anunciou por anos que faria o mesmo, mas desistiu em 2024 e, em 2025, abandonou também a ideia de perguntar a cada usuário: nele, os cookies de terceiros continuam liberados, e quem quiser bloqueá-los precisa mudar as configurações.

Cache

A melhor requisição é a que não precisa ser feita. O navegador guarda as respostas num cache e as reaproveita, seguindo as instruções que o próprio servidor dá nos cabeçalhos. Veja o que acontece com a foto do pão ao longo de três visitas:

O Cache-Control: max-age diz por quantos segundos a cópia pode ser usada sem perguntar nada. Vencido esse prazo, o navegador pergunta de novo, mas mandando a etiqueta da versão que tem, no cabeçalho If-None-Match. Se nada mudou, a resposta é um 304 de poucas dezenas de bytes, em vez da foto inteira. É a mesma ideia da validade do DNS, com um detalhe a mais: vencida a validade, a cópia antiga ainda pode ser confirmada, em vez de baixada de novo.

Muitos sites combinam as duas coisas de um jeito esperto: dão validade de um ano aos arquivos e mudam o nome do arquivo sempre que o conteúdo muda, como em estilo.3f9a2c.css. O navegador nunca precisa perguntar, e, quando o site muda, o HTML aponta para um nome novo. Entre o navegador e o servidor também pode haver caches compartilhados, como as redes de distribuição de conteúdo, as CDNs, com cópias do site espalhadas pelo mundo, como as cópias dos servidores raiz do DNS.

O problema do texto aberto

Até aqui, tudo viajou em texto aberto. Entre você e o servidor há a sua rede Wi-Fi, o seu provedor e vários roteadores de outras empresas, e cada um deles vê cada byte que passa, e pode alterá-lo. Numa rede Wi-Fi aberta, basta estar por perto: o rádio chega a todos. Veja o que um intruso num café consegue capturar quando a Ana entra na loja da padaria:

Com HTTP, o intruso lê a senha. E, mesmo que a senha tivesse viajado protegida, ele leria o cookie de sessão, e com o cookie entraria na conta da Ana sem senha nenhuma. Em outubro de 2010, uma extensão para o Firefox chamada Firesheep tornou isso trivial: numa rede Wi-Fi aberta, ela mostrava as contas das pessoas em volta, e um clique bastava para entrar nelas. O susto ajudou a convencer os grandes sites a adotar o HTTPS em todas as páginas, e não só nas de login.

Com HTTPS, o conteúdo vira uma sequência de bytes sem sentido para quem não tem a chave, e qualquer alteração no caminho é detectada. Para chegar lá, o navegador e o servidor precisam resolver três problemas: combinar uma chave secreta, fazer isso na frente de todo mundo e ter certeza de que estão falando um com o outro, e não com um intruso. Vamos um de cada vez.

Cifras e chaves

Uma cifra transforma uma mensagem em algo ilegível, de um jeito que só quem tem a chave consegue desfazer. As cifras que protegem o conteúdo na web são simétricas: a mesma chave serve para cifrar e para decifrar. Uma das ideias mais simples, e que está no coração de cifras de verdade, é gerar a partir da chave uma sequência de bytes que parece aleatória e combiná-la com a mensagem, byte a byte, pela operação ou exclusivo (⊕), que dá 1 onde os bits são diferentes e 0 onde são iguais. Experimente com uma cifra de brinquedo:

O truque do ou exclusivo é que ele se desfaz sozinho: aplicar a mesma sequência duas vezes devolve os bytes originais. Com a chave certa, a mensagem volta; mude uma única letra da chave de quem recebe e sai lixo. A sequência da figura vem de um gerador fraco, que um especialista quebraria em segundos. As cifras de verdade, como o AES, adotado como padrão em 2001, e o ChaCha20, usam chaves de 128 ou 256 bits, e testar todas as chaves possíveis levaria mais tempo do que a idade do universo. As versões usadas no TLS também acrescentam a cada mensagem uma etiqueta de autenticação, que denuncia qualquer bit alterado no caminho.

Resta um problema: a chave. O navegador nunca falou com o servidor da padaria, e os dois não têm nenhum segredo em comum. Mandar a chave pela rede não adianta, porque o intruso também a veria.

Combinar um segredo em público

Em 1976, Whitfield Diffie e Martin Hellman publicaram uma solução que parece mágica: dois desconhecidos podem combinar um segredo trocando mensagens em público, mesmo com alguém ouvindo tudo. A ideia costuma ser explicada com tintas. Misturar tintas é fácil, mas separar uma mistura nas cores de origem é praticamente impossível. Mude as cores secretas e acompanhe:

cor secreta da Ana
cor secreta do Bruno

Ana e Bruno terminam com a mesma cor, formada pela cor pública e pelos dois segredos, e nenhum dos dois segredos passou pela rede. Eva viu a cor pública e as duas misturas, mas, sem conseguir separar as tintas, o melhor que ela consegue é misturar o que viu, e aí a cor pública entra duas vezes. Escolha “Com números” para ver a versão de verdade: no lugar de misturar tintas, elevar um número a uma potência e ficar só com o resto da divisão por um número primo. Calcular a potência é rápido; descobrir o expoente a partir do resultado, o chamado logaritmo discreto, é muito difícil quando os números têm centenas de algarismos.

Hoje, a web usa uma variação com curvas elípticas, a X25519, que chega à mesma segurança com números bem menores. E, desde o fim de 2024, o Chrome e o Firefox combinam essa troca com uma segunda, o ML-KEM, que resiste também aos computadores quânticos, capazes, em tese, de resolver o logaritmo discreto. A combinação foi padronizada em agosto de 2026 com o nome X25519MLKEM768, e em abril a Cloudflare já contava mais de 65% do tráfego de pessoas em seus servidores protegido por ela. A pressa tem motivo: alguém pode gravar uma conversa cifrada hoje e esperar um computador quântico para decifrá-la daqui a anos.

A curiosidade histórica é que a descoberta já tinha sido feita antes, em segredo. No GCHQ, o serviço britânico de inteligência de sinais, James Ellis, Clifford Cocks e Malcolm Williamson chegaram às mesmas ideias a partir de 1970. Williamson só pôs no papel o equivalente à troca de Diffie e Hellman em 1976, mas, segundo Ellis, tinha pensado nele bem antes. O trabalho ficou em segredo até dezembro de 1997.

Mas a troca de chaves tem um ponto fraco. Escolha “Com um intruso no meio”: se Eva, em vez de só ouvir, conseguir interceptar as mensagens e trocar as misturas pelas dela, ela combina uma chave com a Ana e outra com o Bruno. Cada um acha que está falando com o outro, e Eva decifra, lê e cifra de novo tudo o que passa. A matemática não tem como evitar isso. O que falta é o navegador ter certeza de quem está do outro lado.

Certificados

A resposta vem de outra invenção da mesma época, a assinatura digital. Com ela, cada servidor tem um par de chaves: uma privada, que ele guarda a sete chaves, e uma pública, que ele mostra a todo mundo. Com a chave privada, o servidor assina uma mensagem; com a chave pública, qualquer um confere que a assinatura só pode ter sido feita por quem tem a chave privada. No aperto de mãos do TLS, o servidor assina a conversa até ali, e o navegador confere com a chave pública do servidor. Se Eva trocar alguma coisa, a assinatura não confere.

Mas isso só empurra a pergunta um passo para trás: como saber que aquela chave pública é mesmo da padaria? É para isso que existe o certificado, um documento que diz, em resumo, “a chave pública de padaria.example é esta”, assinado por uma autoridade certificadora, uma empresa ou organização que conferiu que quem pediu o certificado controla o site. A assinatura da autoridade é conferida com a chave dela, que vem num certificado assinado por uma autoridade acima, até chegar a uma raiz: uma autoridade cuja chave já vem instalada no sistema operacional ou no navegador. Escolha um certificado e veja o navegador conferir:

As autoridades da figura são fictícias, mas a estrutura é a de verdade. Na prática, quem assina os certificados dos sites são autoridades intermediárias, e as raízes, cujas chaves são as mais valiosas, ficam guardadas longe da rede. Desde 2015, uma autoridade sem fins lucrativos, a Let's Encrypt, emite certificados de graça e de forma automática, e foi decisiva para o HTTPS se tornar a regra: no fim de setembro de 2026, ela tinha quase 692 milhões de certificados ativos.

Um certificado vale por pouco tempo, e esse tempo está encolhendo. Desde 15 de março de 2026, o máximo é de 200 dias, e as regras acertadas entre as autoridades e os navegadores o reduzem para 100 dias em 2027 e para 47 em 2029. Certificados curtos limitam o estrago de uma chave roubada e obrigam os sites a renovar tudo automaticamente. Além disso, os principais navegadores só aceitam certificados registrados em listas públicas, os registros de transparência de certificados, e qualquer um pode procurar ali os certificados emitidos para o seu domínio. Uma autoridade que emita um certificado indevido não tem como escondê-lo.

O aperto de mãos do TLS

O protocolo que junta todas essas peças é o TLS, de Transport Layer Security, segurança da camada de transporte. Ele descende do SSL, lançado pela Netscape em 1995 e ainda o nome que muita gente usa. Antes da primeira requisição, o navegador e o servidor fazem um aperto de mãos: combinam as cifras, trocam as partes da chave e o servidor apresenta o certificado. Compare as versões e mude o tempo de ida e volta; toque nas setas para ver o que vai em cada mensagem:

No TLS 1.2, de 2008, o aperto de mãos custava duas idas e voltas, além da do TCP. O TLS 1.3, de 2018, cortou uma: o navegador já manda a sua parte da troca de chaves na primeira mensagem, apostando na forma de troca que o servidor vai escolher. Com isso, todo o resto, incluindo o certificado, já vai cifrado, e um intruso nem vê qual certificado o servidor apresentou. O TLS 1.3 também jogou fora as opções antigas e inseguras que as versões anteriores acumularam, e hoje protege a maior parte das páginas; as versões 1.0 e 1.1 foram oficialmente aposentadas em 2021.

Duas mensagens do aperto de mãos merecem atenção. O ClientHello, que ainda viaja em texto aberto, leva o nome do site que o navegador quer, no campo SNI, para que um servidor que hospede vários sites saiba qual certificado apresentar. E, no fim, as duas partes trocam uma mensagem Finished, já cifrada, com um resumo de tudo o que foi dito: se um intruso tiver alterado qualquer coisa, por exemplo para forçar uma cifra mais fraca, os resumos não batem e a conexão é abandonada.

HTTP/2 e HTTP/3

Em 2009, o Google anunciou um protocolo experimental chamado SPDY, que foi a base do HTTP/2, publicado em 2015. O HTTP/2 mantém tudo o que as mensagens significam, os métodos, os códigos e os cabeçalhos, e muda só a forma de transmiti-las. Em vez de texto, ele usa quadros binários, cada um com um cabeçalho de 9 bytes que diz o tamanho, o tipo e o fluxo a que ele pertence. E os cabeçalhos passam a ser comprimidos, com um esquema chamado HPACK. Compare duas requisições seguidas na mesma conexão:

O HPACK usa duas tabelas. A estática, igual em todo lugar, tem 61 cabeçalhos comuns, como :method: GET, que viram um byte só. A dinâmica é montada durante a conexão: os cabeçalhos mandados por inteiro costumam ficar guardados dos dois lados, numa tabela de tamanho limitado, e da segunda vez basta mandar a posição deles. Os nomes que começam com dois-pontos, como :path e :authority, são os pseudocabeçalhos, que substituem a primeira linha do HTTP/1.1 e o Host. Numa página com dezenas de requisições, quase sempre com os mesmos cabeçalhos longos, a economia é grande.

O HTTP/2 ainda roda sobre o TCP, e herda o bloqueio de cabeça de fila que vimos na cascata. O HTTP/3, publicado em 2022, troca o TCP pelo QUIC, um protocolo de transporte criado no Google e padronizado em 2021, que roda sobre o UDP. O QUIC faz ele mesmo o que o TCP fazia, como confirmar a entrega, reenviar o que se perdeu e controlar o congestionamento, mas separa os fluxos: um pacote perdido só atrasa o fluxo a que ele pertencia. O QUIC também traz o TLS 1.3 embutido, o que junta os dois apertos de mãos numa ida e volta só, e identifica a conexão por um número próprio, e não pelos endereços, de modo que um celular que passa do Wi-Fi para a rede móvel pode manter a conexão.

As três versões convivem. Em 2025, metade das requisições que chegaram à Cloudflare usava o HTTP/2, 29% o HTTP/1.x e 21% o HTTP/3. Os navegadores descobrem se um site fala HTTP/3 por um cabeçalho da resposta, o Alt-Svc, e passam a usá-lo nas conexões seguintes, ou por um registro do tipo HTTPS no DNS, que permite usá-lo já na primeira.

O que o HTTPS não esconde

O HTTPS protege o conteúdo da conversa, mas não o fato de que ela aconteceu. Quem está no caminho continua vendo os endereços IP, o tamanho das mensagens e os horários, e, com eles, às vezes dá para adivinhar muito: qual vídeo alguém assiste, por exemplo, pelo padrão dos tamanhos. O nome do site vai em texto aberto no SNI e, em geral, também nas consultas ao DNS, a menos que elas sejam cifradas, como vimos no guia sobre o DNS. Para fechar a primeira brecha, existe o ECH, a cifragem do ClientHello, publicado como padrão em março de 2026: o navegador cifra o ClientHello inteiro com uma chave que o site publica no DNS, e o intruso só vê o nome genérico da empresa que hospeda o site. O Chrome e o Firefox já o usam desde 2023; o Safari ainda não.

E o cadeado não diz nada sobre as intenções de quem está do outro lado. Ele garante que você está conversando com o dono de padaria.example, e não que padaria.example seja uma padaria honesta: um site de golpe consegue um certificado com a mesma facilidade, desde que controle o próprio domínio. Por isso os navegadores deixaram de destacar o cadeado como sinal de confiança (desde 2023, o Chrome nem o mostra mais e põe no lugar um ícone neutro de ajustes) e passaram a destacar o contrário, os sites sem criptografia. Desde 2018, o Chrome marca toda página em HTTP como “Não seguro”.

Hoje, a web é quase toda cifrada: segundo o Google, 99% das páginas abertas no Chrome para Android chegam por HTTPS, e 95% no Chrome para Windows. Para fechar a porta que resta, a do acesso por http://, em que um intruso ainda pode interceptar o redirecionamento, os sites podem mandar o cabeçalho Strict-Transport-Security, que diz ao navegador para, durante um prazo, só usar HTTPS com eles. Como o navegador só aprende isso depois da primeira visita, os sites também podem entrar numa lista que já vem embutida nos navegadores, a de pré-carregamento do HSTS, que protege até o primeiro acesso. E, desde a versão 154, lançada em 22 de setembro de 2026, o Chrome para computador passou a pedir a confirmação do usuário antes de abrir um site público sem HTTPS.

Na prática

Todo navegador tem ferramentas para ver essas conversas. Nas ferramentas de desenvolvedor, abertas com F12, a aba Rede mostra cada requisição da página, com os cabeçalhos, os tempos numa cascata como a da figura e a versão do protocolo usada. No terminal, o curl faz uma requisição e, com a opção -v, mostra o aperto de mãos e as mensagens. Para o site da padaria, a saída seria mais ou menos esta:

$ curl -v https://padaria.example/cardapio
*   Trying 203.0.113.10:443...
* ALPN: curl offers h2,http/1.1
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=padaria.example
*  expire date: Jan 16 23:59:59 2027 GMT
*  issuer: O=AC Exemplo; CN=AC Exemplo R7
> GET /cardapio HTTP/2
> Host: padaria.example
> Accept: */*
>
< HTTP/2 200
< content-type: text/html; charset=utf-8
< content-length: 164

As linhas com * descrevem a conexão: a versão do TLS, a cifra, a troca de chaves pós-quântica e o certificado. As com > são a requisição, e as com <, a resposta. Repare que, no HTTP/2, a frase do status desapareceu e os nomes dos cabeçalhos estão em minúsculas: o curl mostra as mensagens no formato do HTTP/1.1, mas o que viajou foram quadros binários. E, se você quiser ver a conversa em texto puro, dá para fazer como nos anos 1990 e digitar uma requisição à mão, com telnet ou nc, num servidor que ainda aceite HTTP sem criptografia.

Palavras finais

O HTTP é um exemplo raro de protocolo que cresceu sem perder a ideia original. A requisição de 1991, um método e um caminho, continua lá no fundo de cada página que você abre, com o mesmo GET, agora cercado de cabeçalhos, cortado em quadros binários, comprimido e cifrado. Cada camada acrescentada resolveu um problema concreto: o Host para dividir servidores, as conexões persistentes e depois os fluxos para ganhar tempo, os cookies para lembrar quem é quem, o cache para não repetir o trabalho.

E o HTTPS é um exemplo raro de criptografia que ficou invisível. Uma troca de chaves inventada em 1976, assinaturas digitais, uma cadeia de autoridades e, agora, algoritmos pensados para os computadores do futuro, tudo acontece em uma ida e volta, antes da primeira letra da página aparecer, bilhões de vezes por dia. Da próxima vez que você vir o cadeado, ou não vir, você sabe exatamente o que ele garante, e o que não garante.

Leituras adicionais

O site da padaria, os endereços IP das figuras e as autoridades certificadoras são fictícios, de nomes e faixas reservados para exemplos. A cascata usa um modelo simplificado, sem controle de congestionamento, e a cifra da figura é de brinquedo: serve para mostrar a ideia, não para proteger nada. As estatísticas foram consultadas em setembro de 2026.