Resumo

  • Quatro diretrizes aplicadas aos mesmos 50,7 milhões de registros Server Hello, capturados em uma instituição durante 14 dias, produziram índices de não conformidade de aproximadamente 14% a 80%.
  • A amostra inclui 6,85 milhões de negociações com X25519MLKEM768, um grupo híbrido pós-quântico que nenhuma das quatro diretrizes avaliadas menciona. “Não listado” não significa “quebrado”.
  • O TLSGatekeeper pode observar parâmetros específicos do handshake e, opcionalmente, bloquear conexões sem descriptografar o tráfego da aplicação. O resultado de 100 Gbit/s veio de um teste de laboratório sem bloqueio ativo, não de uma implantação de produção relatada.

A porcentagem depende do manual

Em um painel de segurança, “80% não conforme” parece descrever a rede. Neste estudo, também descreve o manual usado para pontuá-la.

Um artigo convidado do blog da APNIC apresenta uma pesquisa de Henrique Becker Brum e colegas da Universidade de Trento e da Fondazione Bruno Kessler. O trabalho, publicado como arXiv:2605.31020v1, compara duas semanas de tráfego com quatro diretrizes nacionais: ACN, da Itália; ANSSI, da França; BSI, da Alemanha; e NIST, dos Estados Unidos. Nos três campos avaliados, a não conformidade varia de cerca de 14% sob a ANSSI a 80% sob o NIST.

A conexão não muda quando a diretriz muda. O rótulo, sim. Se uma organização converte esse rótulo em bloqueio automático, a interpretação de um documento passa a decidir quais conexões seus usuários podem estabelecer.

As diretrizes não são inúteis nem necessariamente arbitrárias. Elas atendem a ambientes públicos, modelos de ameaça e trajetórias de migração distintos. O problema aparece quando um sistema reúne três situações diferentes: uma fraqueza conhecida, uma proibição explícita e um valor que ainda não foi avaliado. Chamar tudo de “não conforme” facilita automatizar, mas dificulta explicar.

O alcance real da medição

A coleta ocorreu de 13 a 26 de outubro de 2025, no tráfego da rede interna da Fondazione Bruno Kessler para servidores externos. Após a limpeza, os pesquisadores contabilizaram 155.066.707 pacotes; 50.744.009 mensagens Server Hello formaram a base para analisar versão TLS, conjunto de cifras e grupo selecionados pelo servidor.

Esse volume revela padrões naquela instituição; não a transforma em um censo global. Uma contagem de handshakes não é uma contagem de usuários, servidores ou organizações únicas. Estações de trabalho, serviços próprios, visitantes, acesso remoto e o horário da instituição influenciam a amostra. Os autores descrevem a rede como diversa, mas isso não substitui uma amostragem por setor ou geografia.

O estudo verifica três valores do servidor, em sequência: versão, cifra e grupo. Se o primeiro campo falha na diretriz escolhida, os seguintes não são contabilizados como motivo daquela não conformidade. O trabalho não audita todas as configurações do servidor, certificados, software, contexto de implantação ou comportamento após o handshake. Portanto, “conformidade” significa apenas comparação desses valores com regras específicas, não uma certificação completa de segurança do endpoint.

Essa delimitação já mostra um problema operacional: os documentos avaliados não compartilham um vocabulário universal do que é aceitável.

“Não listado” é um estado próprio

O exemplo mais relevante é X25519MLKEM768. O conjunto de dados registra 6.845.778 mensagens Server Hello que selecionaram esse grupo, cerca de 13,5% da amostra. A tabela do artigo o inclui entre os valores que provocaram uma classificação de não conformidade, embora não aparecesse em nenhuma das quatro diretrizes.

O nome combina X25519, um grupo clássico amplamente implantado, com ML-KEM, mecanismo de encapsulamento de chaves pós-quântico padronizado pelo NIST no FIPS 203. Isso não torna cada conexão “segura contra computadores quânticos”. A medição mostra a seleção do servidor nessa amostra; não comprova a segurança de toda a sessão, a implementação do cliente nem a migração ponta a ponta. Tampouco deve ser confundido com X25519Kyber768_Draft00, um valor de rascunho antigo que o artigo analisa separadamente.

A consequência operacional é clara: uma lista de compatibilidade desatualizada pode classificar como não conforme um valor que já aparece no tráfego real, mesmo sem evidência de vulnerabilidade conhecida apresentada pelos pesquisadores. A diretriz encontrou algo fora de seu vocabulário. Isso justifica rever a regra, mas não prova que o valor deva ser bloqueado.

O movimento inverso também importa. O artigo observa que Curve25519 é amplamente usado e aceito pelos principais navegadores, mas não aprovado na diretriz NIST avaliada. Também aponta que ChaCha20-Poly1305 é uma cifra moderna que o NIST desaconselha. Isso não significa ignorar requisitos públicos. Significa que “não atende a esta linha de base” e “está quebrado criptograficamente” são afirmações distintas, com evidências e consequências diferentes.

Um sinal binário é insuficiente. O operador deveria distinguir valor expressamente proibido por uma política identificada e datada; valor permitido; valor não avaliado ou ainda não listado; e vulnerabilidade conhecida segundo uma base técnica específica. Não se deve deduzir vulnerabilidade da ausência na lista. Uma política pode excluir um valor por escopo sem alegar que ele esteja quebrado, mas os registros precisam preservar essa razão.

Quando observar vira bloquear

O TLSGatekeeper é um intermediário de rede baseado em XDP/eBPF. Ele lê campos específicos de mensagens Server Hello ou Server Key Exchange, compara-os com uma política, registra o resultado e pode bloquear a conexão. Não descriptografa o conteúdo da aplicação. Como observa parâmetros escolhidos pelo servidor, o Encrypted Client Hello não esconde os campos analisados, embora oculte o SNI do lado cliente.

O ponto de controle sai de cada navegador ou aplicativo e passa para a borda da rede. Uma organização pode aplicar a mesma regra a muitos dispositivos temporários ou não gerenciados diretamente. A concentração traz eficiência e também um ponto comum de falha: regra errada, limite do parser ou atualização sem revisão pode afetar todos que passam pelo equipamento.

O teste usou duas unidades BlueField-2 conectadas a 100 Gbit/s dentro de um único servidor; com 16 fluxos de tráfego de fundo, o enlace chegou perto do limite do hardware. O artigo registra atraso médio de inspeção de 671 nanossegundos para TLS 1.3 e 795 nanossegundos para TLS 1.2 por pacote de handshake.

Esses números são medições de laboratório, não garantia de linha cheia em qualquer rede. Mais importante: o teste de desempenho deixou o bloqueio desligado. Os pacotes seguiram para a pilha do host por XDP_PASS. O resultado demonstra baixo atraso medido naquele cenário, mas não a confiabilidade de bloqueio ativo em produção, a correção de uma política nem a existência de clientes implantados.

A implementação também não cobre tudo: trata TLS tradicional sobre TCP, mas não QUIC nem DTLS. O operador precisa saber quais fluxos ficam fora da inspeção. “Não descriptografa” é uma proteção relevante de privacidade, mas não significa ausência de poder de controle: um intermediário pode substituir um pacote do handshake por um alerta e impedir que a conexão se forme.

APNIC publica; não opera o estudo

O blog da APNIC é um espaço público de discussão técnica na região Ásia-Pacífico. A publicação convidada não prova que a APNIC tenha desenvolvido, testado ou implantado o TLSGatekeeper. As afiliações dos autores e o aviso editorial distinguem a pesquisa da operação do registro.

Para os operadores regionais, a pergunta não é qual país deve “vencer”. É como uma regra local vira ação na rede. Um governo pode exigir um perfil para certo serviço público; uma universidade pode adotar outra linha de base para dispositivos gerenciados; uma equipe pode precisar permitir uma nova troca de chaves enquanto conclui a revisão. Essas escolhas podem coexistir se o sistema registrar quem tem autoridade, o escopo, o protocolo e a edição do documento aplicável.

Uma lista sem contexto não viaja bem. Um valor permitido em um perfil pode ser rejeitado em outro. Uma atualização pode tornar “não conforme” uma conexão que não mudou. Se o log disser apenas “bloqueada: não conforme”, a equipe talvez não consiga reconstruir a regra ou saber se havia proibição explícita, falta de avaliação ou simples ausência de referência.

Uma decisão auditável deve preservar o campo examinado, o valor observado, a identificação e edição da diretriz, o motivo, o horário e o caminho para exceção ou correção. Sem isso, a execução pode ser determinística enquanto a governança permanece opaca.

Uma tradução mais segura da diretriz para o pacote

Uma abordagem possível é codificar três estados: permitido, proibido e não avaliado. Vulnerabilidades conhecidas devem ter justificativa técnica separada. “Não avaliado” deve gerar visibilidade e revisão, e não herdar silenciosamente o comportamento de “proibido”.

Quando bloquear for obrigatório, uma regra nova pode começar em modo de observação. O operador mede que conexões seriam afetadas, identifica serviços, testa em um segmento limitado e só então amplia o alcance. A regra deve carregar a fonte, a data, um responsável e o prazo de revisão. Exceções precisam de aprovador e vencimento; o caminho de reversão deve ser testado antes da expansão.

São recomendações editoriais, não funções que o estudo afirma que o TLSGatekeeper já oferece. Elas decorrem da distância entre comparar um documento e agir sobre um pacote. Autores de políticas controlam o texto, operadores escolhem a adoção local, mantenedores definem o parser e usuários sentem a conexão falhar. O registro precisa manter essas responsabilidades visíveis, em vez de fazer o intermediário parecer dono de uma verdade universal chamada conformidade.

A Nota 64 de Heng Lu oferece um ângulo de projeto: uma linha de base técnica comum não deveria transformar cada decisão futura em pedido de autorização central. Isso não exige ignorar regras públicas. Exige delimitar seu escopo e avaliar localmente suas consequências. A distinção é especialmente importante quando o “fracasso” mais visível é um valor criptográfico que a diretriz ainda não incorporou.

O que a evidência permite afirmar

Os pesquisadores mostram que uma amostra institucional expressiva contém valores TLS novos e antigos, que as diretrizes divergem e que um intermediário conseguiu inspecionar campos específicos com alto desempenho medido em laboratório. Não mostram quantas organizações bloqueiam esses valores em produção, quantos usuários são afetados, se a amostra representa a Internet ou o que o grupo híbrido significa para a segurança ponta a ponta.

Essas lacunas não anulam o estudo. Elas separam medição útil de alegação de implantação não comprovada. A conclusão mais sólida não é “80% do TLS é inseguro”. É que o mesmo tráfego observado pode receber notas muito diferentes sob quatro regras reconhecidas, e que um operador consegue converter essa diferença em uma decisão de rede.

Quando a diretriz diz “não listado”, o processador não deve inventar o motivo que falta. Alguém precisa decidir se o valor está proibido, não avaliado ou permitido por uma política local mais recente. A decisão deve ser visível, revisável e reversível. Caso contrário, a lista de autorização deixa de aplicar orientação de segurança e se torna, sem aviso, a própria política de segurança.

Fontes