Capítulo 20 — Segurança quântica e pós-quântica: diagnóstico de problemas
Mapa da aula
Aula 20 publicada. Mapa, exemplo, EX039.
flowchart TD
N0["20.1 Método"]
N1["20.2 Atividade prática — Laboratório H"]
N2["20.3 Causas comuns"]
N3["20.4 Documentando"]
N4["20.5 Caso resolvido"]
N5["20.7 Escalando para os fornecedores"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX039"]
Desenho lógico
flowchart LR
N0["20.1 Método"]
N1["20.2 Atividade prática — Laboratório H"]
N2["20.3 Causas comuns"]
N3["20.4 Documentando"]
N4["20.5 Caso resolvido"]
N5["20.7 Escalando para os fornecedores"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX039"]
[20.1 Método]
|
v
[20.2 Atividade prática — Laboratório H]
|
v
[20.3 Causas comuns]
|
v
[20.4 Documentando]
|
v
[20.5 Caso resolvido]
|
v
[20.7 Escalando para os fornecedores]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX039]
Objetivos de aprendizagem
Você vai (1) aplicar um método sistemático de diagnóstico às falhas de handshake; (2) fazer a triagem dos logs de falha em causas prováveis; (3) diagnosticar problemas de middlebox, de tamanho, de incompatibilidade de grupos e de certificados; e (4) documentar as correções e os problemas residuais.
20.1 Método
Reproduzir, isolar, formular hipóteses, testar, corrigir, verificar, documentar. Reproduza em laboratório com o mesmo cliente e o mesmo caminho; isole removendo saltos; forme uma hipótese ligada às evidências; mude uma coisa só; verifique com os logs de negociação; documente a causa e a correção.
Aplicadas na KLS, as etapas impedem a correção reflexa de desabilitar o híbrido. O caso do proxy-b foi reproduzido com uma réplica de laboratório, isolado enviando o mesmo cliente diretamente, e a hipótese, um segundo segmento descartado, foi confirmada antes de qualquer mudança. A verificação usou os logs de negociação, e não a ausência de reclamações.
20.2 Atividade prática — Laboratório H
# Lab H (ch 20): triage synthetic handshake failure logs into likely causes.
import re, collections
logs = """2026-10-01T10:00Z client=10.0.4.7 err=handshake_timeout size_clienthello=1530 path=proxy-b
2026-10-01T10:01Z client=10.0.4.9 err=handshake_timeout size_clienthello=1530 path=proxy-b
2026-10-01T10:02Z client=10.0.7.2 err=no_shared_group offered=x25519mlkem768
2026-10-01T10:03Z client=10.0.4.8 err=handshake_timeout size_clienthello=1530 path=proxy-b
2026-10-01T10:04Z client=10.0.9.1 err=bad_certificate alg=mldsa65
2026-10-01T10:05Z client=10.0.4.3 err=handshake_timeout size_clienthello=300 path=direct""".splitlines()
causes = collections.Counter()
for line in logs:
f = dict(re.findall(r"(\w+)=(\S+)", line))
if f["err"] == "handshake_timeout" and int(f.get("size_clienthello", 0)) > 1400: c = "large ClientHello dropped (" + f["path"] + ")"
elif f["err"] == "no_shared_group": c = "client/server group mismatch"
elif f["err"] == "bad_certificate": c = "client cannot verify PQ certificate"
else: c = "other / investigate"
causes[c] += 1
for c, n in causes.most_common(): print(f"{n} {c}")
Saída esperada:
3 large ClientHello dropped (proxy-b)
1 client/server group mismatch
1 client cannot verify PQ certificate
1 other / investigate
Três falhas se concentram num único proxy, com ClientHellos grandes; esse padrão aponta para um middlebox que trata mal as mensagens de vários segmentos.
As regras de triagem são ordenadas do específico para o geral. Um timeout com um ClientHello acima de 1.400 bytes é atribuído ao caminho, o que agrupa as três linhas do proxy-b; o timeout idêntico com 300 bytes no caminho direto cai em "other", porque um hello pequeno não pode ser explicado pelo tamanho. O no_shared_group aponta o cliente que oferece apenas o grupo híbrido contra um servidor que não o aceita, e o bad_certificate com alg=mldsa65 aponta para um cliente que não consegue verificar a nova cadeia. O valor do script está no agrupamento: um único caminho explica metade das falhas.
20.3 Causas comuns
ClientHello grande descartado por firewalls ou proxies antigos: atualizar, contornar ou ajustar. Nenhum grupo em comum: as listas do cliente e do servidor não se sobrepõem (por exemplo, um servidor configurado apenas com o híbrido e um cliente apenas clássico). Falha na verificação do certificado: o cliente não consegue verificar o ML-DSA ou não tem a nova raiz. Laços ou latência do HelloRetryRequest: a previsão de key share do cliente não coincide. Desempenho: picos de CPU em dispositivos com recursos limitados.
Para cada causa, a KLS registra a evidência que a distingue: os limites de tamanho de segmento e o caminho, para os descartes; as duas listas de grupos, para as incompatibilidades; o algoritmo do certificado e o repositório de confiança do cliente, para as falhas de verificação; o tempo com um HelloRetryRequest, para a latência; e os gráficos de CPU, para o desempenho.
20.4 Documentando
Cada registro de incidente declara os sintomas, as evidências, a causa, a correção, a verificação e os problemas residuais. Os padrões entre incidentes alimentam os pedidos aos fornecedores e os planos de implantação.
A KLS mantém os registros de incidentes no mesmo repositório dos runbooks. Depois de três casos de proxy com o mesmo modelo de appliance, o registro do padrão se tornou um pedido ao fornecedor e uma verificação prévia à implantação: qualquer local atrás desse modelo recebe um teste de laboratório antes que o perfil chegue a ele.
Cada registro tem um link para a sua reprodução em laboratório e para o runbook que ele alterou. Um chamado fechado sem evidência de verificação é reaberto pela revisão semanal, porque "nenhuma nova reclamação" não é evidência de que as negociações se recuperaram.
20.5 Caso resolvido
Chamado da KLS: "O escritório do armazém não consegue acessar o portal desde terça-feira." Evidências: timeouts apenas pelo proxy-b; ClientHello de 1.530 bytes; o caminho direto funciona. Hipótese: o proxy-b descarta o segundo segmento. Teste: uma réplica de laboratório do firmware do proxy-b reproduz o problema. Correção: atualização do firmware do proxy; provisoriamente, uma regra de contorno do portal para aquele escritório. Verificado: as negociações híbridas a partir do escritório voltam. Residual: outros dois escritórios com o mesmo modelo de proxy, com atualização agendada.
O contorno provisório foi limitado à faixa de endereços de um escritório e recebeu uma data de expiração, para que não pudesse se tornar permanente sem ninguém perceber. A etapa de verificação conferiu as duas pontas: as negociações híbridas a partir do escritório apareceram nos logs do portal, e a contagem de falhas do proxy-b caiu a zero ao longo da semana seguinte.
20.6 Erros comuns e limites
- Desabilitar o híbrido globalmente para corrigir um único caminho.
- Mudar várias coisas ao mesmo tempo.
- Correções sem verificação.
Durante o chamado do proxy-b, alguém propôs remover o X25519MLKEM768 do perfil do portal; isso teria corrigido um escritório e voltado a expor todos os outros clientes a colher agora, decifrar depois. Um segundo engenheiro atualizou o proxy e mudou o perfil do portal na mesma janela, o que tornou impossível atribuir a causa. E um chamado anterior tinha sido fechado como corrigido depois que as reclamações pararam, embora os logs mostrassem que o escritório simplesmente estava num feriado.
20.7 Escalando para os fornecedores
Quando a causa está num produto que você não controla, escale com evidências: produto e versão de firmware, uma reprodução mínima em laboratório, capturas apenas do tráfego de laboratório e o comportamento esperado, com referência à norma relevante (por exemplo, a RFC 8446 sobre o tratamento do ClientHello, ou a RFC 10024 para o grupo híbrido). Relatórios precisos são corrigidos mais rápido e passam a fazer parte do registro de risco residual até que a correção seja entregue.
O relatório da KLS sobre o modelo do proxy-b trouxe a versão do firmware, o ClientHello de laboratório de 1.530 bytes e a exigência da RFC 8446 de tratar mensagens de handshake em vários registros.
Exercícios
- EX039 — Diagnosticar. Um parceiro reporta
no_shared_groupdepois que a KLS mudou as configurações do SFTP. Dê a causa provável e a correção. Rubrica: 3 = apenas híbrido ou clássico removido, restaurar o recuo ou atualizar o parceiro. - EX040 — Estender o Laboratório H. Acrescente uma regra que classifique
err=hrr_timeoutcomo "HelloRetryRequest latency". Rubrica: 3 = código e saída corretos.
Síntese
O diagnóstico sistemático, a triagem de logs e as correções documentadas resolvem as falhas de handshake pós-quânticas sem abandonar a proteção globalmente.
Continue estudando — capítulo 20 de 30
← Capítulo 19 · Índice de capítulos do curso · Capítulo 21 →
Siga para a próxima lição escrita.