Glossário
O que é o OpenSSL — a biblioteca sob o HTTPS, e como defendê-la
OpenSSL é a biblioteca de código aberto que sustenta o HTTPS (TLS/SSL) e a criptografia. A maioria dos servidores a usa indiretamente, herdada via servidor web ou SO — por isso uma falha repercute no mundo todo (Heartbleed).
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 suas falhas alcançam todo mundo — eis o que é essa biblioteca fundamental e como defendê-la.
Onde ele fica — uma base que você "herda"
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 é uma bênção — a criptografia fica a cargo de uma implementação compartilhada escrita por especialistas. Mas quando essa base compartilhada tem um buraco, todo mundo que está em cima dela é afetado de uma vez. É isso que significa "uma falha em biblioteca fundamental tem um raio de impacto enorme".
Por que assusta: um único bug ameaçou chaves no mundo todo
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 é direta: quanto mais fundamental a dependência, mais amplo o raio de 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 a base
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. Rodar EOL é deixar uma porta que não será fechada nem mesmo depois de um buraco ser descoberto. Planeje as atualizações para uma linha suportada.
Inclua a base 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".
Nossa visão: vigie a base 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 inventariar a "base invisível" e colocá-la sob vigilância é o caminho mais curto para evitar incidentes de raio de impacto alto.
Leia em seguida
- Aprenda com um incidente: Heartbleed (uma falha do OpenSSL que ameaçou chaves no mundo todo)
- 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
FAQ
QNunca instalei o OpenSSL — mesmo assim posso estar usando?
Quase com certeza, sim. O OpenSSL é uma biblioteca fundamental usada internamente por servidores web (Nginx/Apache), sistemas operacionais e runtimes de linguagens. Mesmo que você nunca o referencie no seu código, se você serve HTTPS então é muito provável que o OpenSSL (ou uma implementação compatível) esteja rodando por baixo. Supor que 'eu não uso' é exatamente como as vulnerabilidades fundamentais passam batido.
QQual a diferença para o LibreSSL ou o BoringSSL?
Ambos são forks do OpenSSL. O LibreSSL foi criado pelo projeto OpenBSD depois do Heartbleed para limpar a base de código; o BoringSSL é a variante do Google para uso próprio. A maioria dos usuários não precisa escolher entre eles — o que importa muito mais é manter a implementação que sua plataforma traz em uma versão suportada e atualizada.
QComo verifico a versão ou a atualizo?
Em muitos sistemas o `openssl version` a mostra, e você a atualiza pelo gerenciador de pacotes do SO ou reconstruindo a imagem base do seu contêiner. O ponto-chave é não continuar rodando uma versão em fim de suporte (EOL): uma vez que uma linha de versão chega ao EOL, as novas vulnerabilidades encontradas nela não recebem correção. Acompanhe suas dependências fundamentais do mesmo jeito que você acompanha as dependências do seu app.