OpenSSL 3.x: melhorias de segurança para sistemas de alojamento

Integrar o OpenSSL 3.x no serviço de alojamento

O OpenSSL é uma biblioteca de funções criptográficas e TLS. Entre outras coisas, disponibiliza às aplicações métodos de encriptação, assinaturas, verificação de certificados e o estabelecimento de ligações seguras. Uma atualização para OpenSSL 3.x Por conseguinte, melhora, em primeiro lugar, a infraestrutura criptográfica de um sistema de alojamento, e não automaticamente todas as configurações dos serviços que nele estão a ser executados.

É a própria configuração de cada servidor — seja ele um servidor Web, um servidor de e-mail, um proxy reverso ou um serviço de base de dados — que determina se utiliza efetivamente o TLS e quais as regras aplicáveis. O NGINX, o Apache, o HAProxy, o Postfix, o Dovecot ou um cliente de base de dados, por exemplo, selecionam as versões do protocolo, os certificados, as chaves e os métodos permitidos. A biblioteca instalada fornece funções para esse efeito; não substitui uma política de TLS cuidadosa de cada serviço.

O ganho em termos de segurança resulta, sobretudo, de uma versão da biblioteca suportada, de interfaces de programação modernizadas e de uma delimitação mais clara da criptografia antiga. Isto reduz o risco de as aplicações continuarem a utilizar, inadvertidamente, mecanismos desatualizados. No entanto, as atualizações de segurança devem ser instaladas atempadamente, e as cadeias de certificados, as chaves privadas e os direitos de acesso continuam a ser tarefas operacionais independentes.

Na prática, isto aplica-se tanto às ligações públicas como às internas. Num site, o TLS protege o percurso entre o navegador e o proxy inverso; em segundo plano, podem existir outras ligações TLS entre o proxy e o servidor de aplicações ou entre a aplicação e a base de dados. Cada ligação tem os seus próprios interlocutores e requisitos de compatibilidade. Uma biblioteca moderna constitui uma base importante para tal, mas não é garantia de que todas as ligações estejam protegidas de forma consistente.

As aplicações com integração própria de criptografia requerem uma atenção especial. OpenSSL 3 utiliza fornecedores e privilegia interfaces EVP abstratas, enquanto numerosas APIs de baixo nível e mecanismos ENGINE mais antigos são considerados obsoletos. Por isso, numa atualização, pode ser relevante não só uma configuração de serviço, mas também um plugin, uma ligação de linguagem ou uma extensão proprietária.

Escolher corretamente os ramos 3.x suportados

A afirmação „atualizar para o OpenSSL 3“ é demasiado imprecisa para o planeamento operacional. A 19 de outubro de 2026, a página oficial de downloads apenas listará as versões 3.4, 3.5 e 3.6 como ramos 3.x regularmente disponíveis. As versões não listadas não recebem suporte público do upstream e, segundo o OpenSSL, já não devem ser utilizadas em ambiente de produção. O OpenSSL 3.0 e o 3.3 não constituem, portanto, uma base adequada do upstream para novos planos de produção.

Para novos projetos no âmbito da família 3.x, é OpenSSL 3.5 LTS o ramo relevante. O seu suporte está previsto até 8 de abril de 2030. O OpenSSL 3.4 chega ao fim do suporte já a 22 de outubro de 2026, enquanto o OpenSSL 3.6, como ramo não LTS, chega ao fim do suporte a 1 de novembro de 2026. Quem gere pacotes upstream por conta própria deve, por isso, ter em conta o ramo específico e a respetiva data de fim de suporte.

No caso dos pacotes de uma distribuição Linux, a cadeia de versão do fornecedor original não deve ser avaliada isoladamente. Em vez disso, verifique nas informações oficiais sobre pacotes, segurança e ciclo de vida do respetivo fornecedor da distribuição se a versão específica do pacote ainda é mantida. Com as fontes do OpenSSL disponíveis, não é possível fazer uma afirmação geral sobre os procedimentos de atualização ou backport de distribuições específicas.

No ramo principal 3, a API e a ABI são mantidas nas versões secundárias, de acordo com a política de versões; as versões de correção incluem correções de erros e de segurança. No entanto, são necessários testes de aplicações, especialmente no caso de interfaces desatualizadas, fornecedores próprios, módulos de hardware ou ambientes de execução integrados. Além disso, os contentores e as aplicações ligadas estaticamente podem utilizar uma biblioteca diferente da do sistema anfitrião.

O objetivo não é, portanto, obter uma cadeia de versão o mais elevada possível, mas sim garantir uma versão comprovadamente suportada e atualizável para cada componente efetivamente utilizado. Uma compilação própria a partir de fontes upstream aumenta a responsabilidade: as atualizações, os caminhos das bibliotecas e dos fornecedores, os links, bem como os testes de compatibilidade, têm então de ser controlados pelo operador.

O TLS não é uma encriptação de suporte de dados

O TLS protege os dados durante a sua transmissão entre pontos finais definidos. Ao aceder a um site, isto diz respeito, por exemplo, à ligação entre o navegador e o servidor web; no caso do SMTP, pode proteger a transmissão entre servidores de e-mail ou a consulta de uma caixa de correio. O OpenSSL disponibiliza módulos criptográficos para esse efeito, mas a utilização concreta do TLS é controlada pelo respetivo serviço.

As ligações internas também merecem a mesma separação. Uma aplicação pode utilizar TLS para aceder à base de dados, um proxy inverso para o backend ou um servidor de e-mail para um relé. Nesses casos, a verificação de certificados, a verificação de nomes de anfitrião e a gestão de certificados fiáveis são tão importantes como nos serviços acessíveis ao público. No entanto, a encriptação na rede não protege automaticamente os dados que são processados ou armazenados no terminal.

A encriptação de dados em repouso pertence a outra camada. Criptografia no Linux pode incluir, por exemplo, volumes encriptados com LUKS; as bases de dados podem utilizar as suas próprias funções de encriptação e as cópias de segurança requerem um procedimento específico. Estas medidas determinam o que fica protegido em caso de perda de um suporte de dados, acesso não autorizado a ficheiros de cópia de segurança ou acesso a dados armazenados. Uma atualização do OpenSSL não configura automaticamente nenhum destes níveis.

Uma estratégia de encriptação robusta combina, por isso, a proteção durante a transmissão e a proteção em armazenamento, sem as equiparar. Para o TLS, são necessários certificados válidos, chaves privadas protegidas e uma política de protocolos adequada ao serviço. No caso dos dados armazenados, acrescentam-se ainda a gestão de chaves, as autorizações, os procedimentos de recuperação e a proteção das cópias de segurança. Se as chaves forem armazenadas sem proteção juntamente com cópias de segurança encriptadas, a proteção prática permanece limitada.

A pergunta-chave correta é, portanto, para cada fluxo de dados: onde é que os dados são gerados, por que percurso circulam, onde é que ficam armazenados de forma permanente e quem pode utilizar as chaves correspondentes? O OpenSSL pode estar envolvido no TLS e noutras operações criptográficas. No entanto, não é um substituto da encriptação de volume, nem constitui uma gestão completa de chaves, nem uma garantia de cópias de segurança seguras.

Compreender o modelo de prestador de serviços e os níveis de segurança

Com o OpenSSL 3, as implementações criptográficas são feitas através de Fornecedor fornecidos e selecionados com base nas suas características. Isto separa a questão de saber qual o algoritmo necessário da implementação concreta. Para os sistemas de alojamento, isto é relevante porque a aplicação, o contexto da biblioteca e a configuração do OpenSSL determinam, em conjunto, quais os métodos disponíveis e selecionáveis.

O provedor legado não é carregado automaticamente. Se uma aplicação antiga necessitar de um algoritmo disponível exclusivamente nesse provedor, a chamada em questão poderá falhar após a atualização. Como exceção a curto prazo, a sua ativação deve ser limitada ao serviço em questão, documentada e associada a um prazo para a sua substituição.

Se os fornecedores forem ativados expressamente, o fornecedor predefinido deixa de estar automaticamente disponível. Este terá de ser carregado adicionalmente, caso a aplicação necessite das suas implementações. No entanto, o simples facto de carregar o provedor legado não significa que um serviço de rede utilize automaticamente procedimentos legados; o que é determinante são os algoritmos solicitados, as consultas de propriedades e o respetivo contexto da biblioteca.

O FIPS Provider não é um selo de segurança genérico. Características como fips=yes orientam a escolha de implementações adequadas, mas, por si só, não garantem a conformidade. O que é determinante é um módulo validado de forma concreta e a sua política de segurança. Na altura da pesquisa, a página de downloads do OpenSSL indicava o OpenSSL 3.1.2 como a versão validada segundo a norma FIPS 140-3.

O Nível de segurança está separada disso. Além das conjuntos de encriptação, influencia também as assinaturas, os tamanhos das chaves e os parâmetros. Uma configuração global como @SECLEVEL=2 pode, por isso, excluir certificados ou entidades remotas. Verifica se uma alteração é compatível com os serviços e clientes afetados, em vez de concluir que uma lista de algoritmos de encriptação mais curta implica maior segurança.

Configurar a política TLS por serviço

O OpenSSL fornece regras e funções criptográficas, mas a aplicação eficaz Política de TLS é implementado por cada serviço na sua própria configuração. No caso dos serviços Web públicos, bem como dos proxies inversos e dos serviços de correio eletrónico, isto diz respeito, entre outros aspetos, aos protocolos mínimos, certificados, chaves e ao tratamento de diferentes entidades remotas. No caso das ligações internas, por exemplo, entre o proxy, a aplicação e a base de dados, aplicam-se as mesmas questões fundamentais, embora muitas vezes com um conjunto de clientes mais facilmente controlável.

Em primeiro lugar, um serviço só deve permitir as versões de protocolo que sejam suportadas pelos seus interlocutores previstos. Seguem-se, em seguida, uma cadeia de certificados completa e um tipo de chave adequado à utilização. Estas decisões não podem ser tratadas de forma sensata como uma única configuração global do OpenSSL: um servidor Web público, o transporte SMTP e um backend de base de dados operado internamente têm limites de compatibilidade e confiança diferentes.

Nas configurações de encriptação, o limite do protocolo é determinante. As cadeias de encriptação do OpenSSL controlam o TLS 1.2 e as versões anteriores do TLS; as conjuntos de encriptação TLS 1.3 são configurados separadamente. Além disso, a seleção de encriptação não determina qual a versão do protocolo TLS que um servidor negocia. Quem alterar apenas uma lista de encriptação não desativa, portanto, automaticamente os protocolos antigos, nem avalia plenamente o TLS 1.3.

A edição de openssl ciphers não constitui uma prova da política ativa do servidor. Descreve apenas o que a biblioteca CLI utilizada reconhece, em princípio, nos seus parâmetros; o certificado, os parâmetros DH e a configuração do serviço podem restringir ainda mais os conjuntos de certificados que podem ser efetivamente negociados. Só é fiável um teste realizado com o serviço específico, utilizando o nome de servidor, o certificado e o perfil de cliente previstos.

No caso dos serviços de e-mail, uma exceção necessária não deve enfraquecer a política de segurança de todos os anfitriões virtuais ou de todas as ligações de saída. É preferível uma exceção documentada e temporária para o destinatário conhecido, acompanhada de um pedido de migração dirigido ao seu operador. Além disso, as alterações TLS em arquiteturas de proxy e de sessão de alta disponibilidade requerem uma transição planeada e um plano de contingência documentado. Se a plataforma utilizar o Redis para sessões ou filas, devem também ser consideradas as Estratégias de failover do Redis para sistemas de alojamento em produção deve ser tido em conta, para que um reinício motivado pelo TLS não seja agravado por uma mudança de backend não preparada.

Preparar e verificar a migração de forma controlada

Uma migração controlada começa com um Inventário. Registe processos da Web, de e-mail, de proxy, de bases de dados e de aplicações, bem como pontos de ligação TLS e dependências criptográficas específicas. Distinga o pacote do sistema operativo das bibliotecas que vêm incluídas em contentores, painéis de alojamento ou ambientes de execução integrados.

Aplique primeiro a alteração num ambiente de teste com cadeias de certificados, nomes e perfis de cliente que reflitam a realidade. O estado dos pacotes, a configuração, os ficheiros do fornecedor e a ordem de reinicialização devem estar definidos antes do período de manutenção. Preste especial atenção aos parceiros de correio eletrónico externos, aos equipamentos mais antigos e aos serviços internos cujos certificados ou protocolos não sejam geridos centralmente.

O comando de diagnóstico seguinte não altera a configuração do servidor e só deve ser executado num domínio de teste autorizado. Este comando ativa o SNI e a verificação do nome do anfitrião; -verify_return_error interrompe a chamada em caso de erro de validação, em vez de prosseguir com a ligação.

openssl s_client -connect <hostname>:443 -servername <hostname> -verify_hostname <hostname> -verify_return_error -brief

Esta chamada verifica uma negociação TLS específica para o nome de anfitrião indicado. Não substitui os testes de outras portas, anfitriões virtuais, ligações internas ou classes de clientes. Para uma aceitação fiável, é, por isso, necessário testar todas as vias de serviço relevantes com contrapartes representativas.

Após a migração, monitorize os registos de serviço, os erros de certificado e os handshakes falhados. Atribua inicialmente as falhas ao certificado, ao protocolo, à seleção da cifra ou a dependências da aplicação. Uma redução global do nível de segurança ou a ativação permanente do provedor legado pode ocultar a causa e não constitui uma solução alternativa padrão adequada.

Analisar de forma específica os problemas de compatibilidade

Após uma atualização do OpenSSL, é frequente que um problema de compatibilidade só se manifeste durante o estabelecimento da ligação: um navegador, um programa de e-mail ou um cliente interno recebe um erro TLS, apesar de o próprio serviço estar em funcionamento. Nessa altura, não altere imediatamente as listas de algoritmos de encriptação nem os níveis de segurança. Primeiro, classifique o erro num dos quatro níveis: certificado, protocolo, negociação de encriptação ou aplicação. Isso limita as exceções à causa real.

No que diz respeito aos certificados, é particularmente importante ter em conta que os certificados «leaf» assinados com SHA-1 não são aceites a partir do nível de segurança 1. Parâmetros de chave demasiado pequenos ou uma cadeia de certificados incompleta também podem impedir o handshake. Por isso, verifica o certificado efetivamente fornecido, incluindo a cadeia e o algoritmo de assinatura, em vez de te limitares a analisar apenas o ficheiro de certificado armazenado no servidor.

Se a ligação com um terminal antigo falhar, a versão máxima do protocolo deste pode ser a causa. O OpenSSL 3 já não considera o SSL 3.0, o TLS 1.0, o TLS 1.1 e o DTLS 1.0 como utilizáveis no nível de segurança predefinido 1. Uma situação deste tipo exige uma decisão sobre substituição, atualização ou compatibilidade transitória estritamente limitada — e não, automaticamente, uma redução global dos requisitos de segurança.

Se faltar um resumo ou um método de encriptação, a causa é frequentemente um Algoritmo antigo. O «Legacy Provider» não é carregado automaticamente e contém procedimentos que já não são de uso comum ou que são considerados inseguros. A sua ativação temporária pode manter uma aplicação antiga acessível para uma migração documentada; no entanto, não se trata de uma medida de reforço de segurança regular e deve ter uma data de validade.

No caso de software próprio ou proprietário, deve verificar adicionalmente a sua integração com a criptografia. Os ENGINEs, bem como inúmeras chamadas de baixo nível para RSA, EC e outros algoritmos, são considerados obsoletos no OpenSSL 3; as aplicações devem migrar para interfaces EVP abstratas. Isto é mais importante do que ocultar uma mensagem de erro através da configuração do fornecedor, porque as chamadas antigas podem contornar a seleção do fornecedor pretendida.

A Configuração do fornecedor tem de estar completa. Assim que uma configuração ativar expressamente outros fornecedores, o fornecedor predefinido deixa de ser carregado automaticamente. Se, por exemplo, for configurado apenas o «Legacy», as implementações padrão modernas podem faltar e um serviço pode falhar inesperadamente. Por isso, carregue os fornecedores necessários de forma deliberada, teste o processo de serviço específico após um reinício e remova as regras de transição assim que o componente dependente for atualizado.

Avaliar corretamente os FIPS e os casos especiais

O Fornecedor FIPS só constitui um componente útil para sistemas de alojamento quando uma exigência contratual, regulamentar ou interna específica requer criptografia validada pela FIPS. Não se trata de um selo de qualidade geral para a segurança TLS. O OpenSSL oferece um conceito de fornecedor FIPS; as implementações podem ser definidas através de propriedades como fips=yes ser selecionado. No entanto, isso por si só não torna nem a instalação nem o ramo OpenSSL 3.5 num módulo FIPS validado.

Para uma avaliação de conformidade robusta, deve verificar separadamente os requisitos e a tecnologia: o texto da especificação, a versão do módulo especificamente validada, incluindo o certificado e a política de segurança, o processo de compilação e instalação prescrito, o pacote da distribuição, bem como o suporte por parte de cada serviço envolvido. A página de downloads do OpenSSL apresenta, a 19 de outubro de 2026, o OpenSSL 3.1.2 como versão validada segundo a norma FIPS 140-3 e exige que se sigam as instruções da política de segurança correspondente para o download, a compilação e a instalação.

Mesmo no caso de um módulo validado e corretamente implementado, a conformidade depende do funcionamento efetivo. A documentação indica que, com fips=yes os algoritmos carregados podem, mesmo assim, não ser considerados autorizados em determinadas condições. A aplicação, as consultas de propriedades, os algoritmos utilizados e o caminho de ligação concreto têm, por isso, de estar em conformidade com as especificações; o simples carregamento de um fornecedor ou de um fragmento de configuração não é suficiente.

É necessário ter especial cuidado com uma ativação global. Um servidor Web pode, posteriormente, iniciar o seu funcionamento, enquanto um serviço de e-mail, um agente ou uma aplicação falha ao aceder a um algoritmo que se encontra fora do FIPS Provider. Além disso, nem todas as aplicações carregam necessariamente a mesma configuração do OpenSSL. Por isso, testa o modo por serviço e por caminho de ligação real num ambiente de teste adequado, antes de o implementar como padrão operacional.

Comum Reforço do TLS Isso é uma questão à parte: pacotes de bibliotecas suportados, certificados atualizados, protocolos mínimos adequados e uma política TLS específica para o serviço são necessários mesmo sem o FIPS. Por outro lado, o modo FIPS não substitui nem a gestão de certificados nem a gestão de patches. Por isso, planeie-o como um projeto de conformidade autónomo, com responsabilidades, comprovativos e procedimentos de contingência — e não como um botão para uma instalação genericamente mais segura.

Definir o modelo de funcionamento do OpenSSL

O Modelo de funcionamento determina quem supervisiona as atualizações e qual a biblioteca que um serviço utiliza efetivamente. No caso de um pacote de distribuição, deve verificar o estado específico do pacote com base nas informações oficiais de segurança, pacotes e ciclo de vida fornecidas pelo fornecedor. As fontes do OpenSSL disponíveis não comprovam como uma determinada distribuição Linux disponibiliza correções nem durante quanto tempo mantém um pacote.

Uma migração para OpenSSL 3.5 LTS Faz sentido quando é necessária uma ramificação upstream definida e o operador é responsável pela sua manutenção. O OpenSSL suporta a versão 3.5 até 8 de abril de 2030. Por outro lado, a escolha entre um pacote de distribuição ou uma versão upstream própria depende das responsabilidades e requisitos documentados do sistema.

Os contentores podem conter uma versão da libcrypto diferente da do sistema anfitrião; uma atualização do sistema anfitrião não altera necessariamente este ambiente de execução. No caso de implementações personalizadas, acrescentam-se caminhos de fornecedores, unidades de serviço e ligações dinâmicas. As garantias relativas à API e à ABI no ramo principal não substituem os testes às aplicações, às ligações ENGINE obsoletas ou aos componentes de criptografia externos.

Antes de tomar uma decisão, identifique todos os processos que envolvam ligações TLS externas e internas. Atualize-os através do fornecedor responsável para uma versão suportada e teste percursos de serviço reais no ambiente de teste. As exceções inevitáveis serão limitadas ao serviço em causa e documentadas, indicando o risco, o responsável e a data de término.

Durante alterações que afetam a produtividade, monitorize não só os erros TLS, mas também o estado do processo, os tempos de resposta e o consumo de memória. Os reinícios e as reconexões com erros podem causar picos de carga temporários. O artigo sobre Pressão de memória no kernel do Linux ajuda a distinguir os erros criptográficos da pressão simultânea sobre os recursos.