Resumo

  • Content-Digest confere o conteúdo efetivo da mensagem; Repr-Digest confere os dados completos da representação selecionada. A igualdade não identifica quem escolheu os bytes.
  • Uma trilha decisória separa domínio de bytes, algoritmo, recálculo, cobertura da assinatura, autoridade da chave, validade temporal, repetição, regras de negócio e ação final.

A luz verde tinha um alcance curto

O recálculo confirmou o valor apresentado. Esse resultado era verdadeiro. O salto indevido veio depois: o sistema interpretou a igualdade como permissão para executar o documento.

Quem controla o corpo e o campo de resumo não precisa quebrar SHA-256. Basta calcular o hash do próprio conteúdo hostil. O receptor repete a operação e encontra o mesmo valor. A conta prova coerência entre duas entradas; não cria uma fonte confiável.

Por isso, verified=true é uma descrição incompleta. Registros de decisão devem dizer content_digest_matched, signature_verified, key_authorized ou replay_rejected. Sem o objeto, uma conclusão estreita ganha autoridade que nunca recebeu.

Conteúdo e representação não são a mesma promessa

A RFC 9530 define Content-Digest sobre o conteúdo real da mensagem HTTP e Repr-Digest sobre todos os dados da representação selecionada. Codificação de conteúdo, intervalos, métodos e metadados podem separar os dois domínios.

Um gateway pode conferir bytes comprimidos enquanto a aplicação acredita que a representação descomprimida foi verificada. Ambos relatam sucesso sobre objetos diferentes. A primeira escolha, portanto, não é SHA-256 ou SHA-512. É o invariante: quais bytes, em qual etapa, precisam permanecer iguais?

A substituição da RFC 3230 reforça a lição. O antigo termo “instância” foi interpretado de maneiras incompatíveis, especialmente entre conteúdo da mensagem e dados da representação. Nomes melhores ajudam somente quando telemetria e testes os preservam.

Um dicionário válido não concede confiança

Os campos usam dicionários de Structured Fields. A chave identifica o algoritmo; o valor leva a sequência de bytes do resumo. Vários algoritmos podem coexistir para apoiar uma migração.

Analisar a sintaxe não é aprovar o algoritmo. O receptor precisa de uma lista permitida, uma regra para valores múltiplos e um resultado terminal claro. O registro da IANA informa o estado. A RFC 9530 recomenda algoritmos ativos para muitos usos e proíbe os obsoletos em situação potencialmente adversária.

Base64 apenas representa bytes. Hash, codificação e assinatura são operações distintas. Da mesma forma, Want-Content-Digest e Want-Repr-Digest exprimem preferências que podem ser ignoradas. Se a aplicação exige integridade, a obrigação pertence à sua política.

Assinar o campo não dispensa recalcular o corpo

HTTP Message Signatures pode incluir Content-Digest, método, alvo e outros componentes selecionados. Quando o campo entra na assinatura, seu valor declarado fica ligado a uma chave verificada.

Ainda assim, a assinatura não cobre automaticamente toda a mensagem. Se o campo ficou fora dos componentes selecionados, a assinatura nada conclui sobre ele. Se foi incluído, o receptor ainda deve recalcular o resumo do conteúdo recebido.

Imagine que um defeito troque o corpo e preserve o campo assinado. A assinatura pode continuar válida porque o campo não mudou. Só o recálculo independente encontra a divergência. No sentido oposto, recalcular sem validar a assinatura permite que um desconhecido apresente corpo e resumo novos e coincidentes.

Depois disso ainda resta a autorização. A chave pode ser autêntica e não ter poder para publicar, pagar ou alterar uma rota. Componentes obrigatórios, algoritmo, criação, expiração, nonce e política contra repetição precisam de decisões próprias.

O trailer adia o momento da prova

A RFC 9530 permite o campo em cabeçalho ou trailer. O trailer serve a transmissões nas quais o resumo só fica pronto no fim. Para o receptor, significa que a evidência chega depois do corpo.

Se a aplicação grava estado durante a leitura e só então examina o trailer, um erro aparece tarde demais. O conteúdo deve ficar em preparação, dentro de uma transação reversível, até todas as verificações terminarem.

HTTP/1.1, HTTP/2 e HTTP/3 transportam trailers de formas diferentes. Proxies e frameworks podem descartá-los ou expô-los de outro modo. O caminho de produção deve provar que o componente decisor recebe o campo antes do compromisso.

Bytes íntegros ainda podem estar vencidos

Uma resposta em cache pode conservar exatamente os mesmos bytes e um resumo válido, embora esteja velha. A RFC 9111 reserva frescor, revalidação e uso de resposta obsoleta para regras de cache separadas.

Uma requisição assinada também pode ser repetida intacta. Corpo, resumo e assinatura passam novamente. Janela temporal, nonce, identificador e idempotência é que decidem se a segunda execução é permitida.

O significado segue outra contabilidade. Um arquivo pode respeitar o esquema e conceder privilégios perigosos. Um pacote pode combinar com o resumo publicado e conter código vulnerável. Integridade preserva o objeto; não aprova seu efeito.

O teste negativo define a fronteira

Comece enviando conteúdo hostil com o resumo correto. A conferência deve passar e a autorização deve negar a ação. Depois altere um byte, preserve o resumo e exija falha antes da mudança de estado.

Assine uma requisição que não inclua Content-Digest; depois inclua o campo, mas altere o corpo. Teste algoritmos múltiplos, desconhecidos e obsoletos sem permitir rebaixamento por ordem. Atravesse compressão, intervalos e reconstrução de representação.

Por fim, envie trailers por cada versão HTTP e intermediário, repita uma requisição válida e ofereça bytes de cache vencidos com resumo correto. Cada controle deve responder apenas pela sua própria pergunta.