O que é HTTPS? A versão segura do HTTP

Toda vez que você abre um site, digita uma senha ou faz uma compra online, há uma camada invisível trabalhando para impedir que estranhos leiam seus dados no meio do caminho. Essa camada é o HTTPS. Neste artigo você vai entender o que ele é, como funciona, o que acontece no handshake, como certificados provam identidade e por que hoje praticamente todo site precisa dele.

HTTP e HTTPS: qual a diferença?

O HTTP (HyperText Transfer Protocol) é o protocolo que define como navegadores e servidores trocam mensagens na web. Se você ainda não está familiarizado com ele, vale a pena ler primeiro O que é HTTP? Métodos, status e como a web conversa, porque o HTTPS é, literalmente, esse mesmo protocolo com uma camada de segurança por baixo.

O "S" no final significa Secure (seguro). Na prática, o HTTPS é o HTTP rodando sobre uma conexão criptografada. As regras de como pedir e receber páginas continuam idênticas às descritas na especificação do HTTP (Fielding, Nottingham, Reschke, 2022) — o que muda é que ninguém no caminho consegue ler ou alterar o conteúdo.

A diferença aparece já na URL:

Um ponto que confunde iniciantes: HTTPS não é um protocolo novo. Não existe um "protocolo HTTPS" com métodos e status próprios. O que existe é o HTTP de sempre — os mesmos GET, POST, 200, 404 — transportado dentro de um túnel cifrado por TLS. Por isso tudo o que você sabe sobre HTTP continua valendo; o HTTPS apenas embrulha esse conteúdo.

O problema que o HTTPS resolve

Imagine enviar um cartão postal: qualquer pessoa que o manuseie até o destino pode ler a mensagem. O HTTP puro funciona assim. Seus dados passam por vários equipamentos (roteadores, provedores, redes Wi-Fi) e, em cada ponto, podem ser:

O HTTPS ataca os três problemas de uma vez, oferecendo confidencialidade, integridade e autenticação.

Um exemplo concreto: o Wi-Fi do café

Pense em uma rede Wi-Fi pública e aberta. Sem HTTPS, qualquer pessoa conectada à mesma rede, com ferramentas simples, pode capturar o tráfego e ler senhas, cookies de sessão e mensagens em texto aberto. Pior: um atacante pode se posicionar entre você e o site (um ataque conhecido como man-in-the-middle), interceptando e até modificando o que você vê. O HTTPS torna esse cenário inviável: mesmo capturando os pacotes, o atacante vê apenas dados embaralhados, e qualquer tentativa de alteração é detectada pela outra ponta. Esse é o motivo prático pelo qual a web inteira migrou para HTTPS.

Como o HTTPS protege a conexão

A segurança do HTTPS vem de um protocolo chamado TLS (Transport Layer Security). Ele se posiciona entre o HTTP e a rede, embaralhando tudo o que sobe e desce. Para um mergulho completo, veja O que é TLS? Como o HTTPS protege suas conexões; aqui basta entender as três garantias que ele entrega:

A versão moderna desse protocolo é o TLS 1.3, definida na RFC 8446 (Rescorla, 2018), que tornou o handshake mais rápido e removeu opções de criptografia consideradas frágeis.

Vale corrigir um equívoco comum: você ainda ouve falar em "SSL", o antecessor do TLS. O SSL está obsoleto e inseguro há anos; toda conexão "HTTPS" séria hoje usa TLS. O termo "certificado SSL" sobreviveu por inércia de marketing, mas a tecnologia por baixo é TLS.

Criptografia simétrica e assimétrica trabalhando juntas

O HTTPS combina dois tipos de criptografia, e entender essa dupla é a chave para enxergar como tudo funciona. Se quiser se aprofundar nos conceitos, O que é criptografia? Simétrica, assimétrica e hashing cobre cada um em detalhe.

A sacada é usar a assimétrica apenas para combinar, com segurança, uma chave simétrica temporária. Depois disso, toda a comunicação roda com a simétrica, que é veloz. É como usar um cofre blindado (lento) só para entregar a chave de casa (rápida).

Por que não usar só uma delas?

Se usássemos apenas a simétrica, teríamos o problema do ovo e da galinha: como cliente e servidor combinariam a chave secreta sem que um espião visse essa troca? Não dá para enviar a chave em texto aberto. A criptografia assimétrica resolve exatamente isso, permitindo estabelecer um segredo compartilhado mesmo com terceiros ouvindo. Se, por outro lado, usássemos apenas a assimétrica, a conexão seria lenta demais — operações assimétricas custam caro em CPU. A combinação pega o melhor dos dois mundos: segurança para a negociação inicial, velocidade para o tráfego contínuo.

O handshake TLS passo a passo

Antes de qualquer página ser enviada, cliente e servidor fazem um "aperto de mão" (handshake) para estabelecer a conexão segura. De forma simplificada:

1. Cliente  -> Servidor : "Olá, quero falar com segurança. Suporto TLS 1.3."
2. Servidor -> Cliente  : "Olá! Aqui está meu certificado digital."
3. Cliente              : verifica o certificado com uma Autoridade Certificadora.
4. Cliente <-> Servidor : combinam uma chave simétrica de sessão.
5. Cliente <-> Servidor : a partir daqui, tudo trafega criptografado.

No TLS 1.3, esse processo foi enxugado para reduzir o número de idas e vindas, deixando a conexão segura quase imperceptível em termos de velocidade (Rescorla, 2018).

O que muda do TLS 1.2 para o 1.3

A diferença não é cosmética. No TLS 1.2, o handshake exigia duas idas e voltas (2-RTT) antes de qualquer dado de aplicação ser enviado, o que adicionava latência perceptível, especialmente em conexões longas. O TLS 1.3 reduziu isso para uma ida e volta (1-RTT) e introduziu um modo 0-RTT para conexões a sites já visitados, em que o cliente pode enviar dados junto com a primeira mensagem. Além da velocidade, o TLS 1.3 removeu algoritmos criptográficos antigos e quebradiços, deixando apenas um conjunto enxuto de opções modernas — menos espaço para configurações inseguras. Na prática, isso significa conexões seguras que abrem mais rápido e erram menos.

Certificados digitais e Autoridades Certificadoras

O certificado digital é o documento que comprova a identidade do site. Ele é emitido por uma Autoridade Certificadora (CA), uma organização confiável que verifica quem é o dono do domínio antes de assinar o certificado.

Quando o navegador recebe o certificado, ele checa:

Se algo não confere, você vê aquele aviso vermelho de "conexão não segura". O cadeado na barra de endereços indica apenas que a conexão é cifrada e o certificado é válido — não que o site seja honesto. Um site de phishing também pode ter HTTPS.

A cadeia de confiança

Por que seu navegador confia no certificado de um site que ele nunca viu antes? Por causa de uma cadeia de confiança. O navegador (ou o sistema operacional) vem com uma lista de CAs raiz em que confia previamente. Essas raízes assinam certificados intermediários, que por sua vez assinam o certificado do site. Quando você acessa um site, o servidor envia seu certificado mais os intermediários, e o navegador verifica a assinatura subindo a cadeia até chegar a uma raiz confiável. Se a corrente fecha numa raiz conhecida, a identidade é aceita. Esse modelo distribui a confiança: você não precisa conhecer cada site, apenas confiar em um punhado de autoridades raiz.

Tipos de validação

Nem todo certificado prova o mesmo nível de identidade:

Para a maioria dos sites, um certificado DV automatizado é suficiente — ele garante a criptografia, que é o que protege os dados.

Hoje, iniciativas como o Let's Encrypt emitem certificados DV gratuitos e automatizados via o protocolo ACME, o que ajudou a tornar o HTTPS universal. A automação resolve um problema histórico: certificados expiram, e renovar manualmente era fonte constante de quedas de site.

HTTPS, DNS e CDN: como tudo se encaixa

O HTTPS não atua sozinho na entrega de um site. Antes mesmo do handshake, seu navegador precisa descobrir o endereço IP do servidor, e isso é trabalho do DNS — explicado em O que é DNS? A agenda telefônica da internet. É por isso, inclusive, que existem extensões como DNS sobre HTTPS, para proteger também essa etapa.

Já quando o site usa uma rede de distribuição de conteúdo, a conexão segura geralmente termina no servidor de borda mais próximo de você. Vale entender esse papel em O que é uma CDN e como ela acelera seu site: a CDN guarda os certificados e faz o handshake TLS perto do usuário, deixando o carregamento mais rápido sem abrir mão da criptografia.

Por que o HTTPS é obrigatório hoje

O HTTPS deixou de ser um diferencial para virar requisito básico. Alguns motivos:

Com certificados gratuitos e configuração automatizada, não há mais desculpa técnica ou de custo para deixar um site no HTTP puro.

Boas práticas ao usar HTTPS

Se você desenvolve aplicações, vale seguir alguns cuidados:

Entendendo o HSTS

O Strict-Transport-Security é um cabeçalho de resposta que merece destaque. Ele instrui o navegador a, durante um período definido, recusar qualquer conexão HTTP àquele domínio e usar exclusivamente HTTPS — mesmo que o usuário digite http://.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

O HSTS fecha uma brecha sutil: sem ele, a primeira requisição de um usuário que digita o domínio sem o https:// ainda sai em HTTP e pode ser sequestrada antes do redirecionamento. Cuidado, porém: ative o preload só quando tiver certeza de que todo o domínio e seus subdomínios suportam HTTPS permanentemente, pois reverter a inclusão na lista é lento.

Erros comuns com HTTPS

Perguntas frequentes

O cadeado garante que o site é seguro? Não. Ele garante que a conexão é cifrada e que o domínio teve sua identidade verificada por uma CA. Um site de phishing pode obter um certificado válido e exibir o cadeado. Segurança da conexão não é o mesmo que confiabilidade do conteúdo.

HTTPS deixa meu site mais lento? Praticamente não. O custo do handshake foi muito reduzido pelo TLS 1.3, e em muitos casos o HTTPS é até mais rápido, porque o HTTP/2 e o HTTP/3 — que trazem ganhos de performance — só funcionam sobre conexões seguras.

SSL e TLS são a mesma coisa? São protocolos da mesma família, mas o SSL é antigo e inseguro. O que se usa hoje é o TLS. "Certificado SSL" é apenas um nome antigo que pegou.

Preciso pagar por um certificado? Não para a maioria dos casos. O Let's Encrypt emite certificados DV gratuitos e automatizados, suficientes para garantir a criptografia da maior parte dos sites.

HTTPS protege os dados depois que chegam ao servidor? Não. O HTTPS protege os dados em trânsito, entre o navegador e o servidor. O que acontece com eles depois — como são armazenados, quem tem acesso — é responsabilidade da aplicação. Criptografia em trânsito não substitui boas práticas de segurança no back-end.

Conclusão

O HTTPS é o HTTP vestido com uma armadura de criptografia. Ele garante que seus dados cheguem privados, intactos e ao destino certo, combinando criptografia assimétrica para negociar a sessão e simétrica para a velocidade do dia a dia, tudo orquestrado pelo TLS e ancorado numa cadeia de confiança que parte de Autoridades Certificadoras. Com handshakes rápidos no TLS 1.3, certificados gratuitos e automatizados, e mecanismos como o HSTS para fechar brechas, servir tudo sob HTTPS deixou de ser opcional. Em um mundo onde até a busca por um endereço precisa de proteção, dominar o HTTPS é entender a base da web segura — e o ponto de partida de qualquer coisa que você construa online.

Referências