--- name: azion-verifique-a-troca-de-chaves-pos-quantica description: >- Confira se as conexões TLS 1.3 com o seu domínio negociam a troca de chaves híbrida pós-quântica X25519MLKEM768, pelo navegador ou com OpenSSL. --- # Verifique a troca de chaves pós-quântica Você pode conferir pelo navegador ou com OpenSSL se as conexões com um domínio servido pela Azion usam troca de chaves pós-quântica. A Azion negocia criptografia pós-quântica (PQC) em toda conexão TLS 1.3 sem nenhuma configuração: nenhuma troca de certificado, nenhum ajuste e nenhuma mudança na sua aplicação. Para escolher as versões de TLS e as cifras que um workload aceita, consulte [Defina o conjunto de cifras TLS](/pt-br/documentacao/guias/seguranca-de-aplicacoes/tls-e-certificados/cifras/). --- ## Pré-requisitos - Um domínio servido por um [workload](/pt-br/documentacao/plataforma/workloads/). - Para a verificação no navegador, um navegador com suporte a ML-KEM: Chrome 131 ou posterior, Edge 131 ou posterior, Firefox 135 ou posterior, ou uma versão recente do Safari. - Para as verificações por linha de comando, o OpenSSL. --- ## Confira a troca de chaves no navegador Um navegador com suporte a ML-KEM negocia o algoritmo híbrido sozinho quando se conecta a um domínio servido pela Azion. Para conferir a troca de chaves no navegador: 1. Abra o seu domínio no navegador. 2. Abra as ferramentas de desenvolvedor com **F12**. 3. Selecione a aba **Security**. O campo **Key Exchange** mostra **X25519MLKEM768**. --- ## Confira a troca de chaves com OpenSSL O comando abre uma conexão TLS 1.3 com o seu domínio e imprime o grupo que a conexão negociou. Substitua `your-domain.com` pelo seu domínio: ```bash echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 2>&1 | grep "group" ``` A saída mostra o grupo híbrido pós-quântico: ```text Negotiated TLS1.3 group: X25519MLKEM768 ``` --- ## Confira o fallback clássico Um cliente sem suporte a PQC volta para um algoritmo clássico, e a Azion aceita a conexão. O comando oferece só o grupo clássico `X25519`, como um cliente desse tipo faz: ```bash echo "Q" | openssl s_client -connect your-domain.com:443 -tls1_3 -groups X25519 2>&1 | grep "group" ``` A saída mostra o grupo clássico: ```text Negotiated TLS1.3 group: X25519 ``` A conexão funciona sem a camada pós-quântica. --- ## Troca de chaves na Azion A Azion negocia PQC no caminho do cliente até a Azion. As bibliotecas TLS dela suportam o algoritmo que o NIST padronizou na FIPS 203, o ML-KEM. ### O modelo híbrido O grupo negociado, **X25519MLKEM768**, combina duas camadas. Se uma camada for quebrada, a outra continua protegendo a sessão, então a conexão é tão segura quanto a mais forte das duas. | Camada | Algoritmo | O que faz | | ------------ | ---------- | --------------------------------------------------------------------------------------------- | | Clássica | X25519 | Criptografia de curva elíptica, testada e segura contra adversários convencionais | | Pós-quântica | ML-KEM-768 | O algoritmo que o NIST padronizou na FIPS 203, resistente a ataques de computadores quânticos | A PQC protege a troca de chaves contra o "harvest now, decrypt later": um adversário grava o tráfego criptografado hoje e o decifra quando existirem computadores quânticos. Uma troca de chaves pós-quântica mantém esse tráfego gravado ilegível. ### Ordem de prioridade A Azion oferece os grupos de troca de chaves nesta ordem: | Prioridade | Algoritmo | Tipo | | ---------- | ----------------- | ------------------------ | | 1 | X25519MLKEM768 | Híbrido pós-quântico | | 2 | X25519 | Clássico, curva elíptica | | 3 | P-256 (secp256r1) | Clássico, curva NIST | | 4 | X448 | Clássico, curva elíptica | | 5 | P-384 (secp384r1) | Clássico, curva NIST | O X25519MLKEM768 vem primeiro porque os navegadores mais usados enviam por padrão um key share desse grupo no ClientHello. Com outro grupo em primeiro lugar, como o SecP256r1MLKEM768, o servidor responderia com um HelloRetryRequest. Isso acrescenta uma ida e volta completa a cada nova conexão. ### Compatibilidade - Um cliente com suporte a PQC negocia **X25519MLKEM768**. - Um cliente sem suporte a PQC volta para **X25519** ou **P-256**. - A Azion não recusa nenhuma conexão por causa da troca de chaves. O servidor aceita o melhor algoritmo que os dois lados suportam. A PQC só existe no TLS 1.3, porque o TLS 1.2 e as versões anteriores não têm troca de chaves ML-KEM. Um workload pode aceitar o TLS 1.2 como versão mínima e continuar aceitando o TLS 1.3. Com essa configuração, só as conexões TLS 1.3 ficam protegidas com PQC. Uma conexão TLS 1.2 usa o conjunto de cifras configurado para o workload. ### Conexões com a origem No caminho de uma aplicação até a origem dela, a Azion negocia PQC quando o servidor de origem aceita TLS 1.3 com X25519MLKEM768. Uma origem sem suporte a PQC recebe uma troca de chaves clássica. As conexões de Functions com uma origem não negociam PQC. ### Certificados Os certificados TLS continuam RSA ou ECDSA, porque as autoridades certificadoras públicas não emitem certificados pós-quânticos. Um certificado protege contra um adversário ativo com um computador quântico no momento da conexão, e esse computador não existe hoje. A troca de chaves protege contra a gravação do tráfego hoje, e por isso vem primeiro. --- ## Próximos passos - [Defina o conjunto de cifras TLS](/pt-br/documentacao/guias/seguranca-de-aplicacoes/tls-e-certificados/cifras.md): Defina a versão mínima de TLS e as cifras que um workload aceita. - [Crie um certificado digital](/pt-br/documentacao/guias/seguranca-de-aplicacoes/tls-e-certificados/criar-certificado-digital.md): Adicione o certificado RSA ou ECDSA que um workload serve. - [mTLS](/pt-br/documentacao/plataforma/workloads/mtls.md): Exija certificados de cliente nas conexões com um workload. - [Workloads](/pt-br/documentacao/plataforma/workloads.md): Entenda como um workload recebe conexões TLS para os seus domínios.