Entendendo SSL/TLS: funcionamento, segurança e vulnerabilidades.

Lucas Nascimento
23 de jul.
7 min de leitura

Atualizado: 21 de ago.

SSL (Secure Sockets Layer) e seu sucessor TLS (Transport Layer Security) são protocolos criptográficos que oferecem comunicação segura sobre redes, como a internet. Eles operam acima do TCP, permitindo que protocolos de aplicação como HTTP, SMTP e IMAP sejam transmitidos de forma segura sem alterações em sua estrutura. Isso da origem, por exemplo, ao HTTPS que é apenas HTTP sobre TLS.

Imagem exemplificando como funciona o SSL / TLS cores azul para os protocolos e amarelo para o SSL / TLS — Exemplificação

As versões SSL 2.0 e SSL 3.0 são obsoletas e inseguras. Hoje, utiliza-se principalmente TLS 1.2 e TLS 1.3.

História

O protocolo SSL (Secure Sockets Layer) foi desenvolvido pela Netscape em meados de 1994 com o objetivo de estabelecer uma camada de segurança para as comunicações na web. A versão 1.0 jamais chegou a ser lançada publicamente devido a falhas internas.

A primeira versão distribuída foi o SSL 2.0, em 1995, mas ela apresentava diversas vulnerabilidades. Em resposta, a Netscape lançou rapidamente o SSL 3.0 em 1996, trazendo avanços significativos em segurança e confiabilidade.

A partir dessa versão, o protocolo passou a ser amplamente adotado em ambientes de comércio eletrônico, incluindo por instituições financeiras e operadoras de cartão, que buscavam meios mais seguros para realizar transações pela internet.

O SSL foi projetado com uma arquitetura modular e extensível, o que facilitou sua compatibilidade com versões anteriores e com futuras implementações. Seu funcionamento baseia-se no uso de criptografia e certificados digitais emitidos por autoridades certificadoras confiáveis.

Esses certificados permitem autenticar as partes envolvidas — geralmente o servidor — e estabelecer um canal seguro entre cliente e servidor, garantindo a confidencialidade, a integridade e, em certos casos, a autenticidade da comunicação. Embora a autenticação do cliente também seja possível, na prática, ela é utilizada apenas em contextos mais restritos, como sistemas corporativos de alta segurança.

O SSL representou um marco na proteção de dados transmitidos pela internet, e sua evolução natural resultou no surgimento do TLS, que hoje é o padrão predominante em segurança de rede.

O objetivo de um certificado SSL é simples: ele foi criado para proteger a troca de informações entre computadores, evitando que esses dados sejam interceptados ou capturados por terceiros.

Seu funcionamento na prática

O cliente SSL ou TLS envia uma mensagem chamada Client Hello, que contém:

A versão do protocolo SSL ou TLS que o cliente suporta (ex: TLS 1.2, TLS 1.3);
Um conjunto de algoritmos criptográficos que o cliente aceita, ordenados por preferência (ex: AES, ChaCha20, etc.);
Uma sequência de bits aleatórios (chamada random) usada posteriormente na criação das chaves criptográficas;
Um ID de sessão, caso esteja tentando retomar uma conexão anterior;
E, opcionalmente, métodos de compactação e extensões adicionais (como o SNI — Server Name Indication, usado para indicar o domínio que o cliente deseja acessar).

Essa mensagem serve como um convite para iniciar uma comunicação segura, mostrando tudo o que o cliente suporta. Em resposta, o servidor SSL ou TLS envia uma mensagem chamada Server Hello, que contém:

A versão do protocolo que será usada (com base nas versões aceitas pelo cliente);
O algoritmo de criptografia escolhido entre os oferecidos pelo cliente;
Sua própria sequência de bits aleatórios;
O ID de sessão (confirmando ou negando a retomada da sessão anterior);
E também pode incluir extensões adicionais.

Após essa troca inicial, as próximas etapas envolvem o envio do certificado digital do servidor, verificação da identidade, geração da chave compartilhada e, finalmente, o início da comunicação criptografada.

O servidor envia seu certificado digital (normalmente emitido por uma Autoridade Certificadora, como a Let’s Encrypt ou DigiCert). Esse certificado comprova que o servidor é quem diz ser. Ele contém a chave pública do servidor e é usado para verificar sua identidade.

Depois acontece a troca de Chaves (Key Exchange), e a forma dessa etapa depende da versão do TLS. Vamos simplificar usando o TLS 1.2 como exemplo comum:

O cliente gera uma chave secreta de sessão, criptografa com a chave pública do servidor (vinda do certificado) e envia ao servidor.
Apenas o servidor consegue descriptografar essa chave, porque só ele tem a chave privada correspondente.

Portanto, agora (você) cliente e o servidor têm a mesma chave secreta, que será usada para criptografar a comunicação a partir daqui. Em TLS 1.3, essa etapa é otimizada usando troca de chaves com algoritmos como Diffie-Hellman.

O Diffie-Hellman é um método de troca de chaves usado para que duas partes (como um cliente e um servidor) possam gerar uma chave secreta compartilhada, mesmo se comunicando por um canal inseguro.

Depois da troca de chaves, ambos os lados, enviam uma mensagem chamada Finished, já usando a criptografia da sessão, mensagens que servem para confirmar que tudo correu bem no handshake e que estão prontos para se comunicar com segurança.

Tipos existentes de certificados SSL por validação

Imagem mostra os tipos de validação do SSL/TLS - Sendo DV (Domain Validation) , OV (Organization Validation) e o EV (Extended Validation) — Tipos de validação SSL/TLS

Problemas de segurança SSL

O protocolo TLS (Transport Layer Security) substituiu o SSL (Secure Sockets Layer) há bastante tempo devido às sérias falhas de segurança que comprometiam a integridade da comunicação online. A principal virada ocorreu em 2014, quando foi comprovado que o SSL podia ser quebrado por meio de uma vulnerabilidade crítica conhecida como POODLE (Padding Oracle On Downgraded Legacy Encryption).

Essa falha permitia que atacantes interceptassem dados transmitidos por conexões SSL, como cookies de sessão, credenciais de login e outras informações sensíveis.

Além do POODLE, outras vulnerabilidades graves ajudaram a acelerar a obsolescência do SSL. Um exemplo é o ataque BEAST (Browser Exploit Against SSL/TLS), que afetava versões iniciais do TLS e SSL ao explorar falhas no modo de operação CBC (Cipher Block Chaining), permitindo a captura e decodificação de dados criptografados. Esses riscos tornaram evidente que os antigos padrões criptográficos já não ofereciam a proteção necessária diante das técnicas modernas de ataque.

Como resposta, a comunidade de tecnologia adotou medidas firmes. As principais empresas e desenvolvedores de navegadores — como Google, Apple, Microsoft e Mozilla — anunciaram a descontinuação do suporte aos protocolos TLS 1.0 e 1.1, considerados inseguros.

Desde então, a recomendação passou a ser o uso exclusivo do TLS 1.3, lançado oficialmente em 2018, que trouxe melhorias significativas em segurança, desempenho e simplicidade, eliminando algoritmos vulneráveis e etapas propensas a erros.

Como usar os certificados TLS

Além disso, é importante realizar a renovação periódica dos certificados e monitorar constantemente as configurações de segurança, garantindo que os algoritmos e práticas estejam atualizados de acordo com os padrões recomendados pela comunidade de segurança da informação.

Para utilizar os certificados TLS, é necessário adquiri-los de uma autoridade certificadora confiável (como Let’s Encrypt, Sectigo, ou DigiCert), instalá-los no servidor web e configurá-los corretamente para aceitar apenas conexões seguras, preferencialmente com suporte a TLS 1.3. No entanto, para que a segurança tenha maior cobertura , muitas plataformas de hospedagem como a HostGator ou WIX já oferecem aos sites criados a versão mais atual do TLS 1.3, sem a necessidade de configuranções adicionais.

Exemplo prático: analisando uma conexão TLS com openssl (Linux)

Nosso objetivo é usar o openssl para simular uma conexão com um site HTTPS e visualizar a negociação SSL/TLS, incluindo o certificado digital e a versão do protocolo.

Para começar vamos abrir o terminal e instalar o utilitário OpenSSL

sudo apt update
sudo apt install openssl
OU
sudo apt update && apt install openssl

Conectando em um servidor HTTPS

openssl s_client -connect google.com:443

O que vamos encontrar com isso

Trecho do código: openssl s_client - connect google.com:443 - mostrando a cadeia de versão dos certificados do TLS usado pelos servidores do Google — Cadeia de Certificados

Certificate chain - Indica o início da cadeia de confiança dos certificados apresentados pelo servidor.

0 s:CN = *.google.com - Certificado do site acessado (neste caso, qualquer subdomínio do Google). O “CN” (Common Name) é o nome principal protegido.

i:C = US, O = Google Trust Services, CN = WR2 - O certificado acima foi emitido pela autoridade intermediária Google Trust Services - WR2.

a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256 - O site usa chave pública ECC de 256 bits, assinada com o algoritmo RSA com SHA-256.

Segundo trecho do código: openssl s_client -connect google.com:443 - mostrando a versão do TLS usado pelos servidores do Google — Versão TLS

No client certificate CA names sent - Não enviamos um certificado. Isso é comum em conexões que só exigem autenticação do servidor.

Peer signing digest: SHA256 - O certificado do servidor é assinado com SHA256.

Peer signature type: ECDSA - O tipo de assinatura do certificado usa ECDSA (algoritmo com curvas elípticas).

Server Temp Key: X25519, 253 bits - A chave temporária usada para troca de chaves é X25519, uma curva moderna e segura (253 bits reais).

SSL handshake has read 6625 bytes and written 396 bytes - Durante o handshake TLS, o cliente leu e escreveu essa quantidade de dados.

Verification: OK - A verificação do certificado foi bem-sucedida – tudo certo com a identidade do servidor.

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 - A conexão está usando o TLS 1.3, com cifra moderna e segura: AES 256 bits em modo GCM com SHA384.

Muitas pessoas acham que só porque um site tem "cadeado", está tudo certo — mas um certificado pode estar vencido, mal configurado ou até ser falso. Saber ler essas informações te permite verificar pontualmente se o certificado é válido e confiável ou checar se a criptografia usada está atualizada e forte. Além disso, como profissionais de cibersegurança isso é importante para analisar se os servidores seguem boas práticas (ex: PCI-DSS exige TLS forte).

✅ O que você aprendeu

Neste artigo,"Entendendo SSL/TLS: funcionamento, segurança e vulnerabilidades", você aprendeu os fundamentos e a importância dos protocolos SSL e TLS na proteção das comunicações pela internet. Entendeu como funcionam os certificados digitais e como ocorre, passo a passo, o processo de handshake que estabelece uma conexão segura.

Você também viu a evolução histórica do SSL para o TLS, por que as versões antigas se tornaram obsoletas e como ataques como POODLE e BEAST impulsionaram a adoção de padrões mais seguros como o TLS 1.3. Além disso, exploramos um exemplo prático utilizando o comando openssl s_client, que mostrou como verificar manualmente:

A cadeia de certificação digital;

A versão do protocolo TLS utilizada;

Os algoritmos de criptografia empregados;

E a validade e autenticidade dos certificados.