DWEB 01.10 Segurança na Web: HTTPS, SSL/TLS e Certificados

Quando você digita sua senha em um site, ela viaja por uma sequência de roteadores, cabos, antenas, possivelmente cabos submarinos, até chegar ao servidor. Cada um desses pontos é um lugar onde, em tese, alguém poderia interceptar o tráfego. Se a comunicação não tivesse nenhum tipo de proteção, qualquer pessoa em uma rede pública de café — ou qualquer atacante dentro de um provedor de internet — poderia simplesmente ler tudo, palavra por palavra, como quem lê um cartão-postal. Esse era, literalmente, o estado da web nos seus primeiros anos. A solução é a peça final que vamos estudar nesta aula: o conjunto de tecnologias que formam o HTTPS, viabilizado pelos protocolos SSL/TLS e pelos certificados digitais.

Os três pilares da segurança na comunicação

Toda comunicação digital segura precisa entregar três garantias:

  1. Confidencialidade — ninguém além do destinatário consegue ler o conteúdo.
  2. Integridade — ninguém consegue alterar o conteúdo no caminho sem que isso seja percebido.
  3. Autenticidade — o destinatário tem certeza de quem é o emissor (e vice-versa).

Sem confidencialidade, suas senhas podem ser roubadas. Sem integridade, alguém pode trocar o número da conta bancária no momento de um pagamento. Sem autenticidade, você pode estar conversando com um impostor sem saber. O HTTPS, ancorado em SSL/TLS, é o conjunto de mecanismos que entrega essas três garantias na web.

HTTPS é HTTP + TLS

Como vimos rapidamente no Tópico 1.3, HTTPS não é um protocolo radicalmente diferente. É o mesmo HTTP — mesmas requisições, mesmos métodos, mesmos status, mesmos cabeçalhos —, mas embrulhado em uma camada de segurança chamada TLS (Transport Layer Security).

A relação histórica entre SSL e TLS gera, às vezes, confusão. Vale esclarecer:

  • O SSL (Secure Sockets Layer) foi o protocolo original, criado pela Netscape nos anos 1990. Teve as versões 1.0, 2.0 e 3.0.
  • O TLS (Transport Layer Security) é o sucessor moderno do SSL. Começou na versão 1.0 (essencialmente uma evolução do SSL 3.0) e está hoje em versões muito mais seguras (TLS 1.2 e TLS 1.3 são as recomendadas).

Embora o nome SSL ainda seja muito usado no mercado (especialmente em expressões como “certificado SSL”), na prática toda comunicação segura moderna usa TLS. Os dois nomes são, hoje, frequentemente intercambiáveis na linguagem do dia a dia — mas tecnicamente, o que está rodando é TLS.

Como o TLS funciona, em linhas gerais

O TLS resolve um problema clássico de criptografia: como duas partes que nunca se encontraram antes podem combinar um segredo, em um canal que pode estar sendo espionado? A resposta envolve combinar dois tipos de criptografia.

Criptografia simétrica

É a forma mais antiga de criptografia. Existe uma única chave, conhecida pelas duas partes, usada tanto para criptografar quanto para decriptografar. É rápida, eficiente — mas tem um problema crítico: as duas partes precisam, antes, combinar essa chave em segurança. Em um canal aberto como a internet, isso parece impossível.

Criptografia assimétrica (de chave pública)

É a invenção genial dos anos 1970, que tornou a web segura possível. Cada parte tem um par de chaves: uma pública, que pode ser distribuída livremente, e uma privada, que fica secreta. O que é criptografado com a chave pública só pode ser decriptografado pela chave privada correspondente, e vice-versa.

Isso resolve o problema da combinação: para enviar algo secreto ao servidor, basta usar a chave pública do servidor. Apenas o servidor — dono da chave privada — vai conseguir ler.

O handshake TLS

A criptografia assimétrica é segura, mas lenta comparada à simétrica. Por isso, o TLS combina os dois: usa a assimétrica apenas no início, para combinar uma chave simétrica temporária que será usada no restante da conversa.

Esse ritual inicial chama-se handshake TLS. Em linhas gerais (sem entrar em detalhes técnicos profundos), ele acontece assim:

  1. O cliente diz “olá” ao servidor, anunciando as versões de TLS e os algoritmos que suporta.
  2. O servidor responde com sua escolha e envia seu certificado digital.
  3. O cliente verifica o certificado (vamos detalhar em seguida).
  4. Cliente e servidor combinam, com criptografia assimétrica, uma chave simétrica temporária.
  5. A partir desse momento, toda a comunicação é criptografada com essa chave simétrica, rápida e segura.

Tudo isso, em conexões boas, leva poucas centenas de milissegundos — algumas dezenas em redes modernas com TLS 1.3.

Certificados digitais: a prova de identidade

O ponto mais sutil de toda essa engenharia é o seguinte: como o cliente sabe que está mesmo falando com o servidor verdadeiro, e não com um impostor?

A resposta são os certificados digitais. Um certificado é, em essência, um documento eletrônico que diz: “a chave pública XYZ pertence ao domínio leaoeducacao.com.br”, assinado por uma terceira parte de confiança chamada autoridade certificadora.

Autoridades certificadoras (CA)

Uma CA (Certificate Authority, autoridade certificadora) é uma organização reconhecida que tem poder de emitir certificados. Para emiti-los, ela verifica que quem está pedindo realmente controla o domínio para o qual o certificado é emitido. Os navegadores, por sua vez, vêm com uma lista pré-instalada de CAs em que confiam.

Quando o navegador recebe o certificado de um site, ele verifica se foi assinado por uma CA dessa lista. Se sim, e se o nome do site bate com o nome no certificado, e se o certificado ainda está dentro do prazo de validade, então o navegador aceita: a conexão é considerada segura.

Se algo estiver errado — certificado expirado, autoridade desconhecida, nome diferente — o navegador exibe um aviso vermelho e o usuário precisa, deliberadamente, escolher continuar. Esses avisos existem para proteger o usuário, e jamais devem ser ignorados em produção.

Tipos de certificados

Há três níveis principais:

  • DV (Domain Validation) — a CA apenas verifica que o solicitante controla o domínio. É o tipo mais comum hoje e é o que serviços gratuitos como Let’s Encrypt emitem. Suficiente para a maioria dos sites.
  • OV (Organization Validation) — a CA verifica também a existência legal da organização. Mais usado em sites corporativos.
  • EV (Extended Validation) — a CA faz uma verificação aprofundada. Antigamente, navegadores exibiam a barra de endereço em verde com o nome da empresa para certificados EV; hoje, a maioria deles deixou de fazer essa diferenciação visual.

Let’s Encrypt: o divisor de águas

Por décadas, certificados SSL/TLS eram caros. Pequenos sites simplesmente não tinham HTTPS, porque não valia o investimento. Em 2015, surgiu o Let’s Encrypt, uma autoridade certificadora gratuita e automatizada, fundada por organizações como Mozilla, EFF, Cisco e Akamai. Hoje, é a maior CA do mundo em volume de certificados emitidos.

O efeito foi transformador: praticamente qualquer site pode ter HTTPS sem custo. Plataformas de hospedagem (Netlify, Vercel, Cloudflare, etc.) integraram o Let’s Encrypt e automatizaram totalmente o processo. Você publica um site, e em segundos ele já está em HTTPS, sem que você precise fazer nada.

O que isso significa na prática para você

Como desenvolvedor front-end, suas responsabilidades de segurança não são as mesmas de um administrador de sistemas, mas há alguns pontos que tocam diretamente o seu trabalho:

  1. Todo site profissional precisa estar em HTTPS. Não é mais opcional. Navegadores sinalizam HTTP como inseguro, mecanismos de busca penalizam HTTP, e funcionalidades modernas (geolocalização, câmera, notificações) só funcionam em HTTPS.
  2. Conteúdo misto é proibido. Se sua página está em https://, todos os recursos que ela carrega (imagens, scripts, CSS) também precisam estar em https://. Carregar um script via HTTP em uma página HTTPS faz o navegador bloquear o recurso e exibir um aviso. Isso é chamado de mixed content (conteúdo misto).
  3. Cuidado com dados sensíveis em URLs. Apesar de o corpo das requisições HTTPS ser criptografado, a URL fica registrada em logs de servidor, no histórico do navegador, em cabeçalhos Referer. Nunca coloque senhas, tokens ou dados pessoais em query strings.
  4. Cookies devem ser configurados com cuidado. Cookies que carregam dados sensíveis (como tokens de sessão) precisam dos atributos Secure (só enviados via HTTPS) e HttpOnly (não acessíveis via JavaScript), e idealmente SameSite configurado adequadamente. Esses detalhes são responsabilidade conjunta de back-end e front-end.
  5. Atenção a bibliotecas e dependências. Como front-end, você usará bibliotecas de terceiros. Mantê-las atualizadas é uma das formas mais simples — e mais negligenciadas — de manter um site seguro.

Como verificar o certificado de um site

Você pode investigar o certificado de qualquer site usando o próprio navegador:

  1. Acesse o site.
  2. Clique no cadeado à esquerda da URL na barra de endereço.
  3. Escolha algo como “Conexão segura” e depois “O certificado é válido” (ou “Mais informações” → “Ver certificado”, dependendo do navegador).
  4. Você verá: a quem foi emitido (o domínio), quem emitiu (a CA), o período de validade, e os detalhes técnicos (tamanho da chave, algoritmos usados).

Faça esse exercício em três sites diferentes — um banco, uma rede social, um pequeno site qualquer. Observe diferenças: bancos costumam ter certificados emitidos por CAs comerciais grandes, com validades curtas e renovações frequentes; sites pequenos costumam usar Let’s Encrypt, com certificados de 90 dias renovados automaticamente.

Caso ilustrativo: a história resumida do cadeado verde

No início dos anos 2000, HTTPS era exceção. Sites de bancos, e-commerces e poucos outros casos. A barra de endereço, em alguns navegadores, ficava verde para indicar HTTPS, e usuários eram treinados a “procurar o cadeado” antes de digitar senhas.

Em meados dos anos 2010, com o Snowden e as revelações sobre espionagem em massa, ganhou força a ideia de que todo tráfego web deveria ser criptografado, não apenas o sensível. Iniciativas como HTTPS Everywhere (extensão do EFF) e, sobretudo, o Let’s Encrypt mudaram o jogo. Em paralelo, navegadores começaram a sinalizar HTTP como inseguro, em vez de só destacar HTTPS como seguro.

Hoje, a expectativa se inverteu: HTTP é exceção; HTTPS é padrão. Um site sem HTTPS, em 2026, é visto pelo navegador (e pelo usuário) como suspeito por padrão. Para você, como desenvolvedor iniciante, isso é uma boa notícia: a barreira técnica e financeira para um site seguro é menor do que jamais foi.

Episódio histórico contado de forma resumida, com base em documentação pública e em literatura sobre evolução da web.

Momento de aplicação prática

Vamos consolidar o que aprendemos com um pequeno exercício de “tradução”:

Para cada uma das situações abaixo, identifique qual dos três pilares (confidencialidade, integridade, autenticidade) está sendo violado se aquela situação ocorrer:

  1. Em um café, alguém com um equipamento estranho na mesma rede consegue ver as mensagens que você está enviando para um servidor.
  2. Você é redirecionado, sem saber, para um site falso que se parece com o do seu banco e digita sua senha lá.
  3. Um arquivo que você baixou pela internet aparece corrompido, com dados modificados em relação ao original.

Respostas comentadas:

  1. Confidencialidade — o conteúdo está sendo lido por um terceiro.
  2. Autenticidade — você está conversando com um impostor, sem saber.
  3. Integridade — o conteúdo foi alterado no caminho.

Saber identificar qual pilar está em jogo ajuda muito a entender notícias sobre incidentes de segurança e a tomar decisões corretas em projetos.

Armadilha comum

Há um equívoco frequente: muitos profissionais (e usuários) acham que HTTPS = site seguro. Isso é uma simplificação perigosa. HTTPS garante que a comunicação entre o cliente e o servidor é segura. Não garante que:

  • O servidor é confiável (um site de phishing pode ter HTTPS).
  • O código rodando no navegador não tem vulnerabilidades.
  • O servidor armazena os dados de forma segura.
  • O conteúdo do site é honesto.

O cadeado significa “a conversa entre você e este servidor é privada e este servidor é, mesmo, o servidor que diz ser” — e isso é importante. Mas não significa “este site é honesto”. A diferença é sutil, mas crucial.

Fechamento da Aula 01

Você chegou ao final da primeira aula deste curso. Aqui está, em síntese, o que conquistou:

  • Entendeu que internet e web são coisas distintas, e como uma se apoia na outra.
  • Domina, em nível conceitual, a arquitetura cliente-servidor e o que diferencia o front-end, o back-end e o full-stack.
  • Reconhece os protocolos TCP/IP, HTTP e HTTPS e sabe para que cada um serve.
  • Sabe como o DNS traduz nomes em endereços IP, em uma hierarquia distribuída pelo mundo.
  • Lê uma URL identificando esquema, host, porta, caminho, query string e fragmento.
  • Reconhece os métodos HTTP (GET, POST, PUT, PATCH, DELETE) e suas intenções.
  • Interpreta códigos de status (2xx, 3xx, 4xx, 5xx) e os principais cabeçalhos de requisição e resposta.
  • Conhece o pipeline interno de renderização dos navegadores e sabe usar as DevTools para inspecionar requisições.
  • Tem uma visão geral dos modelos de hospedagem, dos servidores web e do papel das CDNs.
  • Entende, em linhas gerais, HTTPS, SSL/TLS e certificados digitais, e sabe por que isso importa para o seu trabalho.

Próxima aula. A partir da Aula 02, vamos sair da teoria e começar a construir. Você vai configurar o ambiente de desenvolvimento, conhecer o editor de código que será seu companheiro diário, e dar os primeiros passos com HTML e CSS — as linguagens que estruturam e estilizam tudo o que você verá no navegador a partir de agora. Sempre que precisar voltar a algum conceito desta primeira aula, ele estará aqui, pronto para a revisão.

Tópico anterior
Back to Aula