Resumo

  • O wolfSSL 5.9.2 divulgou uma falha de alta gravidade em builds com RPK: uma Raw Public Key não negociada podia substituir X.509 e contornar a validação da cadeia. O ajuste presume X.509 sem escolha alternativa e rejeita discrepâncias entre tipo acordado e forma recebida.
  • O RFC 7250 define RPK como tipo TLS legítimo e explícito, que carrega um único SubjectPublicKeyInfo em DER. A assinatura do handshake prova posse da chave privada, mas a SPKI não traz emissor, sujeito assinado, validade, extensões nem papel de negócio.
  • Uma aceitação segura precisa provar o caminho negociado e consultar um vínculo externo atual entre a SPKI e o host, serviço, dispositivo ou papel. O sucesso do tráfego é apenas o resultado posterior, não evidência dessas decisões.

O dado recebido não pode escolher seu próprio juiz

O release 5.9.2 descreve CVE-2026-55960 como High. Quando HAVE_RPK estava habilitado, uma chave pública bruta podia ser processada mesmo sem o tipo ter sido acordado. Como não há cadeia em uma RPK, o caminho de parsing podia terminar sem executar a verificação de confiança esperada para X.509.

O recurso fica desabilitado por padrão no build independente, embora --enable-all o inclua. Não há no material público contagem de exploração, número de instalações ou faixa completa de versões afetadas. Esses números não devem ser inferidos. O que o caso comprova é uma troca indevida de autoridade: a representação oferecida pelo peer passou a decidir qual validador seria usado.

O conserto torna X.509 a expectativa na ausência de negociação alternativa. No cliente, a forma do certificado recebido do servidor é comparada com o tipo selecionado; no servidor, a credencial do cliente recebe a checagem equivalente. Incompatibilidades, inclusive RPK não negociada, terminam em UNSUPPORTED_CERTIFICATE. O PR 10702 acrescenta testes nos dois sentidos.

Um parser pode saber ler certificados e SPKIs. Essa competência técnica não autoriza autodetecção de política. Primeiro o handshake escolhe o contrato; depois, somente a forma autorizada entra no seu verificador.

O conteúdo exato de uma credencial RPK

O RFC 7250 registra Raw Public Key como CertificateType 2 e define extensões separadas para os tipos de cliente e servidor. O endpoint anuncia o que consegue apresentar ou processar; a outra ponta seleciona um tipo comum. Se não houver interseção, a conexão não deve improvisar.

Quando RPK é escolhida, Certificate leva uma única estrutura DER SubjectPublicKeyInfo: identificador de algoritmo, parâmetros quando cabíveis e os bits da chave. É a parte que também vive dentro de um certificado X.509, sem o restante do objeto certificado.

O TLS 1.3 mantém o desenho. O RFC 8446 inclui RawPublicKey(2) e determina no máximo uma CertificateEntry com SPKI depois da negociação. Também preserva a regra-base: o tipo é X.509v3, salvo escolha explícita de outra forma.

Por isso, ausência de cadeia é normal na via RPK corretamente acordada. A mesma ausência é razão para não tratar a SPKI como certificado se X.509 era esperado. Validade sintática não substitui autorização do tipo.

A assinatura conhece a chave; não conhece o equipamento

CertificateVerify vincula uma assinatura ao transcript do handshake e demonstra posse da chave privada correspondente. Finished confirma o estado criptográfico. O peer controla aquela chave nesta conexão: essa é uma afirmação forte.

Ela não nomeia o peer. No RFC 5280, a assinatura da CA certifica a associação entre material de chave e sujeito. O corpo também contém emissor, sujeito, número de série, período de validade e extensões. O cliente ainda deve validar caminho, nome, uso e política; X.509 não concede privilégio de aplicação automaticamente. Mas uma SPKI bruta sequer transporta essas afirmações assinadas.

O RFC 7250, por isso, exige vínculo fora de banda entre chave e entidade e manda verificar o estado do vínculo. Uma impressão digital provisionada na fábrica, um TLSA ou uma entrada criada na primeira conexão são eventos históricos. Rotação, comprometimento, reatribuição ou retirada podem invalidá-los.

O cadastro externo precisa guardar identidade e papel canônicos, escopo de host e serviço, SPKI exata, responsável pela autorização, início, fim, predecessor, sucessor, estado de retirada, caminho de distribuição e evidência de quais verificadores já recusam a chave antiga.

APIs mostram o ponto em que a governança vira execução

No wolfSSL, a aplicação habilita RPK, configura preferências de tipo e fornece callback para autenticar a chave fora do TLS. O exemplo TLS 1.3 interoperável com GnuTLS conclui a conexão, mas informa que o peer não foi verificado antes dessa lógica. Interoperabilidade de protocolo não é identidade aceita.

O GnuTLS oferece verificação de chave armazenada por host e serviço, separa ausência de registro de chave divergente, aceita validade e backend próprio. Sua documentação ressalta que a verificação normal de certificados não funciona para RPK sem corpo de certificado; é preciso comparação fora de banda ou continuidade no estilo TOFU.

Essas funções dão forma ao controle, mas não criam sua fonte de legitimidade. Ainda é necessário provar quem cadastrou a chave, qual atualização foi consumida, se o callback rodou nesta sessão e qual permissão de aplicação foi aberta.

DANE e firmware distribuem a mesma decisão em ritmos diferentes

DANE é uma fonte externa possível. O RFC 6698 permite que um TLSA protegido por DNSSEC selecione SPKI e faça correspondência por valor ou digest. Assim, um nome de serviço pode ser associado à chave em um domínio de autoridade DNS.

O cliente precisa validar DNSSEC, interpretar usage, selector e matching type e comparar o objeto correto. Um registro publicado sem consumidor não decide nenhuma conexão.

O RFC 7671 orienta a rotação: pré-publicar a nova associação, esperar caches antigos expirarem, implantar a chave ou certificado correspondente e só depois remover entradas obsoletas. Durante a transição, visões diferentes podem ser válidas. O operador precisa saber qual geração cada verificador enxerga.

Em dispositivos restritos, o relógio é o firmware. O RFC 7925 admite provisionar antes da conexão a chave do servidor ou seu hash e trata RPK como meio-termo entre PSK e infraestrutura de certificados. Um produto de longa vida ainda precisa receber retirada e sucessão por atualização segura. Reduzir bytes no handshake transfere trabalho para o ciclo de configuração.

Sete fatos antes de chamar a conexão de autenticada

Separe política configurada, lista oferecida, tipo selecionado, forma recebida, prova de posse, vínculo externo com versão e frescor, e autorização de aplicação. Registre a impressão SPKI e a operação concreta; não registre segredo privado.

Um único tls_success pode esconder RPK não negociada, entrada vencida, callback ausente ou papel amplo demais. Já uma recusa de uma chave matematicamente válida pode provar que a fronteira funcionou.

A primazia do código em execução de Heng Lu é uma lente útil e limitada. O RFC atribui significado, a IANA registra números e o cadastro externo publica uma associação. A autoridade prática aparece quando o processo vivo rejeita o tipo errado, consulta a versão atual e limita a ação. O patch de 2026 alterou exatamente esse veto.

Limites da evidência

As fontes permitem afirmar o defeito, a condição de build e o comportamento corrigido. Não permitem afirmar exploração, população atingida ou intervalo total de versões. Também não sustentam que toda RPK seja menos segura que X.509.

Uma RPK negociada e vinculada por uma autoridade protegida pode ser adequada em ambientes controlados. X.509 também falha com validação ruim. A regra durável é não deixar uma credencial herdar a aceitação da outra sem executar as regras correspondentes.

Sources