Resumo

  • A RFC 9729 permite que um cliente provisionado prove sua identidade já na primeira requisição, usando material derivado do TLS em vez de esperar um desafio que denunciaria a existência do recurso.
  • A prova está ligada à conexão e ao contexto da origem, não ao método, caminho ou corpo da requisição; terminação TLS, multiplexação e confiança entre frontend e backend entram no perímetro de autenticação.
  • Uniformizar a resposta externa como “inexistente” exige o movimento oposto internamente: razões de falha, gerações de política, revogação, autorização e entrega precisam continuar separadas e verificáveis.

Considere uma interface operacional que não deve ser enumerável. Um visitante anônimo pede o caminho e recebe a mesma resposta que obteria por uma URL jamais configurada. Um cliente autorizado chega ao mesmo endereço com uma credencial Concealed e recebe o serviço. O servidor não lançou um 401 antes; a prova veio pronta.

A RFC 9729 substitui a novidade de um desafio por um exporter de material criptográfico da conexão TLS. Com isso, o cliente pode assinar antes que o servidor revele que há autenticação disponível. A informação pública diminui, mas o poder de decidir quem recebe chaves, quais origens as aceitam e quem pode atestar a conexão permanece intacto.

O primeiro controle ocorre antes do HTTP

O padrão presume distribuição externa de chaves. O cliente possui identificador e par assimétrico; a origem possui um mapa de identificadores aceitos para chaves públicas. O protocolo não escolhe o emissor, não define a elegibilidade, não guarda a chave privada do dispositivo nem fixa o processo de desligamento, perda ou comprometimento.

Uma assinatura perfeita contra um cadastro antigo é uma prova perfeita da política errada. Remover um arquivo do cliente não revoga o cadastro do servidor. Alterar uma linha de banco não é revogação efetiva enquanto cada verificador capaz de servir o recurso não tiver carregado a nova geração — e uma tentativa sintética não tiver demonstrado a rejeição do estado anterior.

O inventário útil relaciona emissor, classe do sujeito, origem e realm autorizados, fingerprint da chave pública, ativação, validade, motivo de revogação, geração do cadastro e verificadores consumidores. O segredo continua secreto; a trilha da decisão não pode desaparecer.

O que está, e o que não está, no exporter

O rótulo registrado é EXPORTER-HTTP-Concealed-Authentication. Seu contexto inclui algoritmo de assinatura TLS, identificador da chave, chave pública, scheme da URI, host, porta e realm opcional. O resultado tem 48 bytes: 32 entram no material assinado e 16 seguem no parâmetro de verificação v.

A credencial também leva k, a, p e s. O servidor localiza o identificador, compara a chave apresentada à chave armazenada, confere v contra o exporter da conexão e valida a assinatura. As comparações explícitas reduzem confusão de chaves e fazem a aceitação depender do canal esperado.

O contexto não cobre método, caminho nem corpo HTTP. Na mesma conexão, a mesma chave pode produzir uma prova idêntica para requisições distintas. Isso ajuda a compressão, mas amplia a importância do isolamento em HTTP/2 e HTTP/3: um contexto capaz de ler o Authorization de outro pode reproduzi-lo dentro daquela conexão. Separação entre tenants, abas, workers e proxies deixa de ser somente uma escolha de desempenho.

“Recente” também precisa de medida. A prova pode ser tão antiga quanto uma conexão persistente ou retomada. Se o risco exige uma janela menor, o servidor pode forçar nova conexão, aceitando custo de handshake, capacidade e indisponibilidade. Idade, linhagem de resumption e causa de renovação pertencem ao registro da decisão.

O terminador TLS passa a testemunhar identidade

Quando frontend e backend estão separados, o primeiro termina TLS ou QUIC e encaminha o Authorization original junto de Concealed-Auth-Export. O backend não consegue reproduzir, em sua própria conexão, o material do enlace cliente–frontend. Ele aceita uma afirmação do frontend.

Por isso o padrão manda ignorar o campo quando o remetente não é previamente confiável e proíbe o frontend de repassar uma cópia injetada pelo cliente. Um balanceador capaz de produzir o valor que autoriza uma identidade não é “só transporte”. É parte da infraestrutura de autenticação.

Uma ACL ampla de rede raramente basta. A evidência deve identificar o frontend autenticado, versões de software e configuração, conexão do cliente, virtual host, authority normalizada, correlação protegida do exporter e rota de backend. Cabeçalho removido, duplicado ou construído com host diferente pode converter uma falha precisa numa 404 impecavelmente ambígua.

Autenticar não é autorizar nem entregar

O backend analisa os parâmetros, encontra o ID, compara a chave, compara o valor de verificação e valida a assinatura. Qualquer falha recebe o tratamento de credencial ausente. O conjunto completo permite considerar o cliente autenticado; não concede, sozinho, a operação pedida.

Uma chave válida pode pertencer a alguém autorizado apenas para uma função. A conta pode estar suspensa. Uma rota pode usar uma geração antiga. Outra pode expor o recurso sem executar Concealed. Por isso o evento deve separar autenticação, política de autorização e efeito real. Um canário a partir do cliente fecha a lacuna entre “assinatura válida” e “serviço entregue”.

A falha uniforme é política de divulgação

Para uma capacidade não sondável, a falha de autenticação deve coincidir com a resposta de um recurso inexistente. Não basta o código 404. Corpo, cabeçalhos, cache, fechamento de conexão, tamanho e distribuição de latência podem denunciar o ramo.

Verificar assinaturas custa tempo. Se caminhos inexistentes retornam imediatamente e caminhos protegidos consultam cadastro e criptografia, surge um oráculo temporal. A avaliação precisa comparar distribuições sob carga e rede equivalentes. Índices, sitemaps, mensagens, bundles de cliente, telemetria, documentação e DNS também podem publicar o que o desafio deixou de revelar.

A versão do texto também integra a prova

O registro de errata contém um alerta concreto. A errata verificada 8807 corrige um exemplo hexadecimal que codificava HTTP Signature Authentication, embora a construção normativa use HTTP Concealed Authentication. Uma implementação copiada do exemplo pode falhar interoperabilidade e devolver apenas a resposta genérica planejada.

A errata 8843, ainda reportada, observa que a ABNF impressa para o inteiro s exclui valores não nulos de um dígito, enquanto a prosa permite 0 a 65535. A operação precisa registrar interpretação, versão do parser e testes de compatibilidade, além de acompanhar o status.

Os registros IANA do scheme, do campo HTTP e do exporter estabelecem nomes compartilhados. Não provam suporte de clientes, correção da distribuição de chaves, cobertura das rotas nem equivalência de respostas. Autoridade documental e efeito executável ocupam camadas distintas.

Uma superfície pública e outra probatória

O desenho maduro produz duas visões. Para o solicitante não autorizado, reduz distinções. Para operadores responsáveis e auditados, separa credencial malformada, chave desconhecida ou revogada, chave pública divergente, exporter divergente, assinatura inválida, TLS inelegível, frontend não confiável, negação de autorização, erro de rota e falha posterior.

Esses motivos não podem voltar para o corpo público ou para a latência. Devem ser unidos por correlação protegida, com retenção e acesso definidos. A matriz negativa inclui caminhos inexistentes reais, caminho oculto sem credencial, credenciais corrompidas, chaves desconhecidas e revogadas, host ou porta errados, TLS inelegível, campo injetado pelo cliente, frontend não confiável e negação depois de autenticação válida. O exterior converge; o interior continua discriminável.

Fontes