OpenSSL 4.0 Acabou de Sair e Vai Quebrar Metade dos Seus Projetos

Quem trabalha com infraestrutura, backend ou qualquer coisa que toque em HTTPS já sabe: o OpenSSL é aquela dependência silenciosa que segura a internet inteira. A versão 3.0 saiu lá em 2021 e causou uma dor de cabeça monumental com a transição do ENGINE para Providers. Agora, cinco anos depois, a versão 4.0 chegou — e se você não prestar atenção, seu servidor pode simplesmente parar de funcionar.

Eu não estou exagerando. A lista de breaking changes é extensa, e algumas das remoções vão atingir em cheio projetos que ainda dependem de APIs legadas. Mas a boa notícia? As features novas são genuinamente empolgantes. Encrypted Client Hello, criptografia pós-quântica, e uma série de melhorias que tornam o TLS mais robusto do que nunca.

Vamos direto ao que importa.

O Que É o Encrypted Client Hello (e Por Que Você Deveria se Importar)

O ECH — Encrypted Client Hello, definido na RFC 9849 — é provavelmente a feature mais significativa dessa release. Para entender o impacto, preciso explicar um problema que existe desde o início do TLS.

Quando seu navegador se conecta a um servidor HTTPS, a primeira coisa que acontece é o “Client Hello” — uma mensagem que diz, entre outras coisas, qual domínio você está tentando acessar. Isso é o SNI (Server Name Indication). O problema? Esse SNI viaja em texto puro. Qualquer pessoa no meio do caminho — seu provedor de internet, o Wi-Fi do aeroporto, aquele firewall corporativo — consegue ver exatamente quais sites você está visitando, mesmo que o conteúdo em si seja criptografado.

É como enviar uma carta em envelope lacrado, mas com o destinatário escrito em letras garrafais do lado de fora.

O ECH resolve isso criptografando o Client Hello inteiro. O SNI, os protocolos suportados, tudo. Para um observador externo, a conexão parece ir para um servidor genérico — ele não consegue mais distinguir se você está acessando um site de notícias ou outra coisa qualquer.

Na prática, configurar o ECH no OpenSSL 4.0 envolve gerar as chaves ECH e configurar o servidor:

# Gerar configuração ECH para o servidor
openssl ech -keygen -out ech_config.pem -public_name public.example.com

# No servidor, carregar a configuração ECH
# (exemplo com s_server para teste)
openssl s_server -cert server.pem -key server.key \
  -ech_config ech_config.pem -accept 443

O cliente, por sua vez, precisa obter a configuração ECH via DNS (registro HTTPS/SVCB) e usar automaticamente:

# Testar conexão com ECH
openssl s_client -connect example.com:443 -ech

Isso é um salto enorme para a privacidade na web. Governos que fazem bloqueio por SNI — como aconteceu recentemente na Espanha com a La Liga bloqueando Cloudflare, Docker e GitHub — terão muito mais dificuldade com o ECH habilitado.

Criptografia Pós-Quântica: Preparando Pra Quando o Quantum Chegar

Se você acompanha segurança digital, já ouviu falar do problema “harvest now, decrypt later”. A ideia é simples e assustadora: atacantes coletam tráfego criptografado hoje e guardam para descriptografar no futuro, quando computadores quânticos forem potentes o suficiente para quebrar RSA e curvas elípticas.

O OpenSSL 4.0 dá mais um passo nessa direção com suporte expandido a algoritmos pós-quânticos:

O mais interessante é o grupo híbrido curveSM2MLKEM768. Ele combina criptografia clássica (SM2, o padrão chinês) com pós-quântica (ML-KEM), garantindo que mesmo que um dos dois algoritmos seja quebrado, a conexão continua segura. Essa abordagem híbrida é o que o NIST recomenda durante o período de transição.

Para testar criptografia pós-quântica no OpenSSL 4.0:

# Listar grupos disponíveis
openssl list -kem-algorithms

# Conectar usando grupo pós-quântico híbrido
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768:X25519

# Verificar qual grupo foi negociado
openssl s_client -connect example.com:443 -groups X25519MLKEM768 2>&1 | grep "Server Temp Key"

A real é que a maioria dos devs não vai precisar mudar nada no código — o OpenSSL negocia automaticamente o melhor algoritmo disponível. Mas se você gerencia servidores, vale configurar os grupos pós-quânticos como preferência.

A Morte do ENGINE: Finalmente

Eu sei que muita gente vai sentir essa. O sistema de ENGINE existe desde o OpenSSL 0.9.6, lá em 2000. Era a forma de plugar aceleradores de hardware, HSMs e implementações customizadas de criptografia. O problema é que o ENGINE era uma API frágil, cheia de armadilhas, e que há anos já tinha uma substituição superior: os Providers.

Com o OpenSSL 3.0 em 2021, o Provider virou o padrão. O ENGINE foi deprecado. Agora, no 4.0, ele foi finalmente removido.

Se o seu projeto ainda usa alguma dessas funções, prepare-se:

// REMOVIDO no OpenSSL 4.0 — NÃO COMPILA MAIS
ENGINE *e = ENGINE_by_id("pkcs11");
ENGINE_init(e);
ENGINE_set_default(e, ENGINE_METHOD_ALL);

// MIGRAÇÃO: Use Provider
OSSL_PROVIDER *prov = OSSL_PROVIDER_load(NULL, "pkcs11");
// Pronto. O provider registra automaticamente seus algoritmos.

A diferença é brutal em termos de simplicidade. Mas o bicho pega quando você depende de bibliotecas de terceiros que ainda usam ENGINE internamente. Muitos wrappers de HSM, por exemplo, ainda não migraram. Antes de atualizar para o OpenSSL 4.0, verifique todas as suas dependências.

Uma busca rápida no seu projeto:

# Verificar se seu código usa ENGINE
grep -rn "ENGINE_" src/ include/
grep -rn "engine.h" src/ include/

# Se encontrar algo, você tem trabalho pela frente

Todas as APIs Que Morreram (Lista Completa)

Além do ENGINE, várias outras APIs foram removidas ou tiveram mudanças incompatíveis. Aqui vai a lista que você vai querer salvar:

Funções Removidas

Mudanças de Comportamento

A estrutura ASN1_STRING agora é opaca. Isso significa que você não pode mais acessar os campos diretamente:

// ANTES (OpenSSL 3.x) — acessava direto
ASN1_STRING *str = ...;
printf("length: %d\n", str->length);
printf("data: %s\n", str->data);

// DEPOIS (OpenSSL 4.0) — use acessores
ASN1_STRING *str = ...;
printf("length: %d\n", ASN1_STRING_length(str));
printf("data: %s\n", ASN1_STRING_get0_data(str));

Parece bobagem, mas esse tipo de mudança quebra muita coisa em projetos C que manipulam certificados diretamente.

Outra mudança sutil: X509_V_FLAG_X509_STRICT agora inclui verificação de AKID (Authority Key Identifier) e checagem de CRL aumentada. Se você usa validação estrita de certificados, prepare-se para falhas em certificados que antes passavam.

Protocolos Removidos

Para reabilitar curvas deprecadas (não recomendado, mas às vezes necessário):

# No build do OpenSSL
./Configure enable-tls-deprecated-ec enable-ec_explicit_curves

Novas Features Menores (Mas Úteis)

Nem tudo é breaking change. Tem feature nova que vai facilitar a vida:

cSHAKE (SP 800-185) — Uma variante customizável do SHAKE, que permite adicionar strings de customização ao hash. Útil para derivação de chaves em protocolos específicos.

SNMP KDF e SRTP KDF — Funções de derivação de chaves para SNMP e SRTP (o protocolo que protege chamadas de voz e vídeo em WebRTC). Se você trabalha com VoIP ou monitoramento de rede, isso é ouro.

FFDHE no TLS 1.2 (RFC 7919) — Finite Field Diffie-Hellman Ephemeral negociado. Antes, FFDHE só estava disponível no TLS 1.3. Agora o 1.2 também ganha esse upgrade de segurança.

Self-tests FIPS adiáveis — Com a flag -defer_tests, o módulo FIPS pode adiar os self-tests para quando for realmente necessário, acelerando a inicialização de aplicações que precisam de compliance FIPS.

# Carregar provider FIPS com testes adiados
openssl fipsinstall -out fipsmodule.cnf -module fips.so -defer_tests

Como Migrar Sem Quebrar Tudo

Vou ser direto: não atualize em produção sem testar. Parece óbvio, mas eu já vi gente fazendo apt upgrade numa sexta-feira à noite sem nem olhar o changelog.

Aqui vai um checklist prático:

1. Verifique suas dependências

# Listar tudo que depende do OpenSSL no seu sistema
ldd /usr/bin/your-app | grep libssl
apt rdepends libssl-dev 2>/dev/null || rpm -q --whatrequires openssl-libs

2. Compile em modo de depuração para pegar deprecations

# Compilar com warnings para APIs deprecadas
gcc -DOPENSSL_API_COMPAT=40000 -Werror=deprecated-declarations \
    -o test_app test_app.c -lssl -lcrypto

A macro OPENSSL_API_COMPAT=40000 faz o compilador tratar qualquer uso de API deprecada como erro. Se compilar limpo, você está seguro.

3. Teste o handshake TLS

# Testar se seu servidor ainda responde corretamente
openssl s_client -connect seuservidor.com:443 -tls1_2 -brief
openssl s_client -connect seuservidor.com:443 -tls1_3 -brief

4. Verifique certificados com validação estrita

openssl verify -x509_strict -CAfile ca.pem cert.pem

Se algo falhar aqui que antes passava, é a mudança no X509_V_FLAG_X509_STRICT.

5. Atualize o rehash

# O script c_rehash foi removido
# Use o comando nativo
openssl rehash /etc/ssl/certs

Quem Deveria Atualizar Agora (e Quem Deveria Esperar)

Atualize agora se:

• Você precisa de ECH para privacidade
• Seu compliance exige criptografia pós-quântica
• Você está começando um projeto novo e quer partir da API mais moderna
• Você já migrou de ENGINE para Providers no 3.x

Espere se:

• Seu projeto depende de bibliotecas que usam ENGINE (HSMs, PKCS#11 wrappers antigos)
• Você tem código C que acessa ASN1_STRING diretamente
• Seu sistema está em produção com OpenSSL 3.x estável e sem necessidade imediata das features novas
• Você usa distribuições que ainda não empacotaram o 4.0 (a maioria, neste momento)

As distros Linux maiores devem levar alguns meses para incluir o OpenSSL 4.0 nos repositórios estáveis. Fedora provavelmente será a primeira — o wiki do Fedora já tem uma página de transição detalhada.

O Impacto Real: Quem Vai Sofrer Mais

Se eu tivesse que apostar, diria que o maior impacto vai ser em:

1. Aplicações embarcadas e IoT — Muitas usam OpenSSL com ENGINE para aceleradores de hardware dedicados. A migração para Provider pode exigir reescrever drivers inteiros.

2. Sistemas legados corporativos — Aquele servidor interno que ainda aceita SSLv3 “por compatibilidade” com um sistema de 2008? Vai parar. E honestamente, deveria ter parado há anos.

3. Linguagens de alto nível — Python, Ruby, Node.js, PHP — todas usam OpenSSL por baixo. Os mantenedores dessas linguagens precisam atualizar seus bindings. Python 3.12+ já removeu suporte a SSLv3, então está bem posicionado. Ruby e PHP podem ter um caminho mais acidentado.

4. Proxies e load balancers — Nginx, HAProxy, Envoy — todos dependem fortemente do OpenSSL. Atualizações nesses softwares costumam demorar algumas semanas após uma major release.

O ponto positivo? A maioria das mudanças segue a mesma direção do OpenSSL 3.0: modernizar, tornar opaco, remover legado. Quem já fez a migração do 1.1.1 para o 3.0 vai achar essa transição muito mais suave.

O Elefante na Sala: LibreSSL e BoringSSL

Vale mencionar que o OpenSSL não é o único jogo na cidade. O LibreSSL (fork do OpenBSD) e o BoringSSL (fork do Google, usado no Chrome e Android) seguem caminhos próprios. O BoringSSL já tem ECH há algum tempo — foi o Google que liderou a especificação. E o LibreSSL tem sua própria API, diferente tanto do OpenSSL 3.x quanto do 4.0.

Se você usa BoringSSL, essa release não te afeta diretamente. Mas se você está no ecossistema OpenSSL puro — que é a vasta maioria dos servidores Linux — o 4.0 é o futuro inevitável.

A longa história do OpenSSL mostra que major versions demoram para serem adotados, mas eventualmente se tornam o padrão. O 3.0 levou quase três anos para dominar. O 4.0 provavelmente seguirá a mesma curva. Quem se antecipa, sofre menos lá na frente.

Fonte de inspiração: OpenSSL 4.0 Released With Encrypted Client Hello, RFC 8998 Support — Phoronix e release notes oficiais do OpenSSL 4.0.0.