Oracle revela atualização do Database 19c com TLS 1.3 em 2026

A Oracle atualizou seu roteiro público de criptografia e passou a detalhar que uma futura atualização do Oracle Database 19c deve trazer TLS 1.3 com troca de chaves resistente a computadores quânticos (ML‑KEM, sozinho ou em modo híbrido com ECDHE) e certificados com ML‑DSA no 2º semestre de 2026.

O movimento chama atenção porque o 19c segue amplamente usado como “versão de longo prazo” em bancos e grandes empresas. Na prática, a Oracle tenta levar recursos de criptografia pós‑quântica para ambientes que ainda não migraram para linhas mais novas do banco.

O detalhamento aparece no roteiro criptográfico do Oracle Database com previsão de TLS 1.3 e ML‑KEM/ML‑DSA no 19c, que também indica mudanças em modos FIPS e descontinuação de algoritmos antigos.

O que este artigo aborda:

• O que muda no Oracle Database 19c a partir do 2º semestre de 2026
• Por que o anúncio é relevante para empresas que ainda dependem do 19c
• Impactos práticos: compatibilidade, auditoria e política de criptografia
• O que observar a partir de agora (e como se preparar)

O que muda no Oracle Database 19c a partir do 2º semestre de 2026

Segundo o roteiro, a entrega planejada mira o tráfego criptografado entre clientes e o banco via TLS. Isso inclui a migração para TLS 1.3 e a adoção de algoritmos pós‑quânticos padronizados.

O ponto central é a possibilidade de negociar chaves com ML‑KEM (um mecanismo de encapsulamento de chaves) e, em alguns cenários, combinar ML‑KEM com ECDHE, mantendo compatibilidade e reduzindo riscos de transição.

Além da troca de chaves, o roteiro cita ML‑DSA para certificados, um tema sensível porque a camada de autenticação (cadeia de certificados) tende a ter dependências operacionais e de auditoria.

• TLS 1.3 como base para conexões seguras com o banco
• Troca de chaves pós‑quântica com ML‑KEM (pura ou híbrida)
• Certificados com assinaturas ML‑DSA, conforme o roteiro
• Ajustes de conformidade ligados a FIPS, afetando algoritmos legados

Por que o anúncio é relevante para empresas que ainda dependem do 19c

Em muitas organizações, o 19c é o “chão de fábrica” de sistemas críticos, e atualizações estruturais de versão podem levar anos. Levar criptografia pós‑quântica a esse ambiente reduz a pressão por migração imediata.

O risco que motiva esse tipo de mudança é o chamado “colher agora, descriptografar depois”: tráfego capturado hoje pode ser aberto no futuro, caso algoritmos clássicos fiquem vulneráveis.

Nos materiais técnicos, a Oracle tem defendido a adoção do modo híbrido como uma forma pragmática de transição — combinando um algoritmo clássico (ECDHE) com um pós‑quântico (ML‑KEM) para evitar depender de um único pilar criptográfico.

Em textos recentes do time de banco de dados, a empresa também reforça que já vem incorporando ML‑KEM e suporte híbrido em linhas mais novas, e que a expansão para o 19c é o próximo passo para “espalhar” o recurso para a base instalada.

1. Quem usa 19c ganha uma rota de modernização sem troca de versão no curto prazo.
2. Times de segurança conseguem planejar inventário criptográfico e impacto em clientes.
3. Equipes de rede e compliance precisam revisar políticas TLS e padrões de certificado.
4. Fornecedores e integrações legadas podem exigir validação extra em TLS 1.3.

Impactos práticos: compatibilidade, auditoria e política de criptografia

A migração para TLS 1.3 costuma mexer com bibliotecas de cliente, appliances de inspeção, balanceadores e proxies. Em ambientes regulados, a mudança também passa por auditorias e critérios de certificação.

Outro ponto do roteiro é a intenção de endurecer o modo FIPS (citando FIPS 140‑3) e desabilitar 3DES quando o banco estiver configurado nesse modo. Isso pode quebrar integrações antigas que ainda dependem de suites legadas.

Na prática, empresas devem tratar a novidade como um projeto de transição criptográfica e não apenas como “um patch”. O trabalho envolve inventário, testes de regressão, e validação de cadeias de certificados.

Para quem opera infraestrutura em nuvem, a discussão de versões TLS e descontinuação de protocolos antigos já vem acontecendo em serviços gerenciados. Em um exemplo recente, a própria comunidade técnica da Oracle alertou que o serviço de Load Balancer na OCI recomendou eliminar TLS 1.0 e TLS 1.1 até 15 de junho de 2026, empurrando clientes para TLS 1.2/1.3.

Esse aviso foi publicado em orientação para migração de listeners e backends do OCI Load Balancer antes de 15/06/2026, reforçando uma tendência de endurecimento do “padrão mínimo” de criptografia.

O que observar a partir de agora (e como se preparar)

O roteiro fala em “atualização futura” e janela “2H 2026”, o que exige acompanhamento de notas de versão e comunicados de patch quando a entrega for formalizada.

Para empresas brasileiras, a preparação passa por testar clientes JDBC/ODP, middlewares e aplicações que terminam TLS, além de definir se a organização pretende usar o modo híbrido por padrão.

Também será essencial alinhar decisões com governança: exigências de FIPS, padrões corporativos de certificados e integrações com HSM, quando existirem.

• Mapear onde TLS termina (app, proxy, LB, gateway, banco).
• Inventariar suites e versões TLS em uso hoje.
• Separar ambiente de teste com TLS 1.3 e políticas equivalentes às de produção.
• Planejar janela de atualização do 19c e validação com fornecedores.

Do lado técnico, a Oracle tem divulgado que suas implementações se baseiam em algoritmos padronizados pelo NIST, como ML‑KEM e ML‑DSA. A própria documentação de segurança do Oracle Database 26 descreve suporte a esses dois algoritmos pós‑quânticos.

Essa referência está em documentação do Oracle Database 26 que cita ML‑KEM e ML‑DSA como algoritmos pós‑quânticos suportados, usada por equipes para orientar testes e escolhas de configuração.