Se você serve HTTPS, seu servidor está quase com certeza rodando sobre o OpenSSL (ou uma implementação compatível). Você nunca o toca diretamente, mas quando uma falha é encontrada, um número enorme de servidores é afetado. Eis o que a biblioteca faz e como defendê-la.
Onde ele é usado
O complicado do OpenSSL é que você o usa sem nunca tê-lo escolhido. Seu app delega o TLS ao servidor web, o servidor web delega a criptografia ao OpenSSL, e esse OpenSSL é entregue pelo SO, uma stack aninhada.
Normalmente isso é conveniente: a criptografia fica a cargo de uma implementação compartilhada escrita por especialistas. Mas quando essa biblioteca compartilhada tem uma vulnerabilidade, todo mundo que a usa é afetado de uma vez. É isso que significa uma falha em biblioteca fundamental ter um impacto amplo.
OpenSSL vs SSL/TLS vs certificados
Os nomes soam parecidos e por isso se confundem, mas cada um tem um papel diferente.
| Termo | O que é | Exemplo |
|---|---|---|
| SSL / TLS | As regras (protocolo) para criptografar uma conexão. SSL é a versão antiga; hoje se usa TLS 1.2 / 1.3 | HTTPS é HTTP envolvido em TLS |
| OpenSSL | O programa (biblioteca) que de fato executa o TLS e as operações criptográficas, mais uma ferramenta de linha de comando incluída | O Nginx e o Apache o chamam internamente |
| Certificado | Dados em que uma autoridade certificadora atesta que você é dono de um domínio. Contém uma chave pública | O Let's Encrypt os emite de graça |
Ou seja, o OpenSSL é uma ferramenta que implementa as regras do TLS, e o certificado são dados que essa ferramenta usa durante uma conexão. Outras bibliotecas também implementam TLS (LibreSSL, BoringSSL, Windows Schannel e outras), e qual delas você usa depende do SO e do software.
Por que o impacto é tão amplo: um único bug pôs em risco as chaves de muitos servidores
O Heartbleed de 2014 (CVE-2014-0160) veio de um pequeno erro de implementação do OpenSSL (confiar num comprimento alegado sem validá-lo) que permitia a um estranho ler a memória do servidor — que podia incluir chaves privadas e dados de sessão — um pouco de cada vez. Como o OpenSSL era tão amplamente usado, um número enorme de servidores no mundo todo virou alvo simultaneamente (história completa → Heartbleed).
A lição é clara: quanto mais baixo na stack uma dependência fica, mais amplo o impacto. Então não são só as dependências que seu app importa diretamente — bibliotecas fundamentais como o OpenSSL rodando por baixo merecem a mesma seriedade no monitoramento e na correção.
Como defender: evite o EOL, monitore as bibliotecas fundamentais
Saiba qual OpenSSL sua stack usa
Você não consegue defender o que não consegue enxergar. Faça o inventário de qual OpenSSL (linha de versão e versão) cada servidor, imagem base de contêiner e runtime de linguagem seus dependem.
Não rode versões em fim de suporte (EOL)
Uma vez que uma linha de versão passou do suporte, as novas vulnerabilidades encontradas nela não recebem nenhuma correção. Se você continua rodando EOL, as vulnerabilidades ficam sem correção mesmo depois de descobertas. Planeje as atualizações para uma linha suportada.
Inclua as bibliotecas fundamentais no monitoramento de CVE
As dependências do app são fáceis de acompanhar com o osv-scanner e afins, mas o OpenSSL entregue pelo SO é fácil de esquecer. Garanta que os novos CVEs em bibliotecas fundamentais também apareçam (→ o guia prático de resposta a CVE).
Corrija rápido quando for grave
Bugs da classe do Heartbleed são atacados no momento em que são divulgados. Mantenha seu caminho de atualização leve o bastante para que correções de base possam sair no mesmo dia quando a gravidade exigir — não "na próxima atualização agendada".
Versões suportadas (em outubro de 2026)
O projeto OpenSSL lança uma versão de suporte de longo prazo (LTS) em abril dos anos ímpares e a suporta por pelo menos cinco anos. As versões não LTS lançadas depois da 3.5 têm suporte por 13 meses a partir do lançamento.
| Linha | Tipo | Fim do suporte |
|---|---|---|
| 4.0 | Regular | 14 de maio de 2027 |
| 3.6 | Regular | 1º de novembro de 2026 |
| 3.5 | LTS | 8 de abril de 2030 |
| 3.4 | Regular | 22 de outubro de 2026 |
| 3.0 / 1.1.1 / 1.0.2 | — | Encerrado (apenas suporte estendido pago da OpenSSL Corporation) |
O OpenSSL entregue pelo seu SO é outra história. Muitas distribuições Linux, entre elas as baseadas em Red Hat, incorporam correções sem aumentar o número da versão (backport). Durante o período de suporte do SO, um pacote que ainda informa 3.0 pode continuar recebendo correções do fornecedor do SO. Não conclua "antigo é vulnerável" ou "novo é seguro" só pelo número; consulte os avisos de segurança do fornecedor do seu SO.
Como verificar seu próprio ambiente
Confira o OpenSSL do SO
openssl version -a para ver a versão. Para a versão do pacote, use dpkg -l 'libssl*' openssl no Debian/Ubuntu ou rpm -q openssl em sistemas baseados em Red Hat. Compare essa versão do pacote com os avisos de segurança do fornecedor do seu SO para ver se a correção está incluída.Confira o que seus aplicativos de fato usam
nginx -V para o Nginx, python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" para o Python e node -p process.versions.openssl para o Node.js mostram a versão embutida.Confira também as imagens de contêiner
Assine os comunicados de segurança do OpenSSL
Como ler a gravidade de uma vulnerabilidade
O projeto OpenSSL classifica as próprias vulnerabilidades em quatro níveis e muda a forma de entregar as correções de acordo com eles.
| Gravidade | Significado aproximado | Como a correção é entregue |
|---|---|---|
| Critical | Afeta configurações comuns e é fácil de explorar (vazamento significativo de memória do servidor, roubo de chaves privadas etc.) | Uma correção é lançada imediatamente para todas as versões suportadas |
| High | Menos arriscada que Critical, mas ainda grave (configurações menos comuns, apenas o lado cliente etc.) | Preparada de forma privada e depois lançada para todas as versões suportadas |
| Moderate | Limitada a negação de serviço, protocolos pouco comuns e afins | Incluída na próxima versão agendada |
| Low | Apenas ferramentas de linha de comando, combinações improváveis de condições e afins | Incluída na próxima versão agendada |
Uma falha como o Heartbleed, em que a memória do servidor pode ser lida de fora, se encaixa na definição de Critical. Para Critical e High, comece a preparar a atualização assim que vir o aviso antecipado.
Nossa visão: monitore as bibliotecas fundamentais com máquinas
Você não consegue acompanhar falhas em bibliotecas fundamentais na memória humana. Este site coloca as próprias dependências e bases sob monitoramento de CVE por máquina. Os certificados que você serve via Let's Encrypt ainda rodam sua criptografia por baixo através de uma implementação da família OpenSSL, então listar as bibliotecas fundamentais em que você nunca pensa e monitorá-las é a forma mais direta de evitar incidentes de impacto amplo.
Leia a seguir
- Aprenda com um incidente: Heartbleed (uma falha do OpenSSL que pôs em risco as chaves privadas de muitos servidores)
- Relacionado: O que é o Let's Encrypt (certificados TLS gratuitos + renovação automática) / Glossário: O que é um CVE
- Na prática: o guia prático de resposta a CVE / monitore dependências com o osv-scanner
Fontes (primárias)
- OpenSSL Library, "Release Strategy" — openssl-library.org (política de LTS, datas de fim de suporte de cada linha)
- OpenSSL Library, "Security Policy" — openssl-library.org (quatro níveis de gravidade, aviso antecipado)
- Red Hat, "Backporting Security Fixes" — access.redhat.com (por que só o número da versão não diz se você está vulnerável)
- NIST NVD, "CVE-2014-0160" — nvd.nist.gov (Heartbleed)