Resumo

  • O certificado usado numa conexão TLS com autenticação mútua é acrescentado pelo proxy à requisição encaminhada. A mensagem original caber não significa que haja espaço para a mensagem ampliada.
  • Tamanho binário em DER, texto dos campos depois da descompressão HTTP, bytes transmitidos e capacidade da tabela dinâmica medem recursos distintos.
  • Reservar espaço depende dos acréscimos e do receptor efetivos. Retirar silenciosamente um certificado ou uma cadeia pode diminuir a mensagem sem preservar o acordo da aplicação.

A diferença entre receber e entregar

Imagine uma requisição que chega ao proxy dentro da capacidade que ele aceita. A conexão externa já negociou TLS com autenticação mútua. Antes de encaminhar a requisição, o proxy acrescenta o certificado do cliente para a aplicação. Se os campos resultantes excederem a capacidade do destino, não é necessário que a negociação TLS tenha falhado. A mensagem mudou entre os dois pontos de admissão.

Esse é um exemplo hipotético, não um incidente documentado nem um teste executado. Ele permite perguntar quem assumiu o custo do acréscimo. O cliente pode ter respeitado a orientação recebida e, ainda assim, não controlar os dados que o próximo participante insere. O receptor pode aplicar sua própria capacidade sem contradizer o que o proxy aceitou antes.

RFC9440, publicado em julho de 2023 como documento Informational da IETF, trata justamente da representação desse transporte. Não pertence à trilha Internet Standards Track. Seu objetivo é codificar uma prática existente e reduzir obstáculos de interoperabilidade entre componentes independentes. Não é uma medição de desempenho nem uma aprovação da capacidade de qualquer implantação real.

Os campos descrevem o certificado apresentado pelo cliente original na conexão TLS mutuamente autenticada com o proxy de terminação. Saltos internos adicionais não os transformam em descrições do certificado do último enlace. O servidor de origem pode usar aquela informação em sua lógica, embora a conexão original não se estenda fisicamente até ele.

A confiança no caminho continua necessária. Aqui, porém, a questão principal é uma obrigação adicional: transportar a representação do certificado dentro do orçamento de campos HTTP. Mesmo uma rota confiável pode chegar a um receptor com capacidade insuficiente. Autenticidade da informação e disponibilidade de espaço não são resultados intercambiáveis.

O acréscimo precisa de uma reserva anterior

Se o proxy divulgar ao cliente todo o limite de seu backend, pode deixar que a requisição original ocupe a margem inteira. O certificado será inserido depois. Uma entrada admissível pode gerar uma saída excessiva sem que o cliente tenha desobedecido ao limite anterior. Repetir a mesma cifra nas duas pontas não reserva o custo da transformação.

RFC9440 recomenda aos intermediários que anunciam tamanho máximo aceitável considerar os dados que acrescentam e divulgar a seus clientes um valor suficientemente menor. Essa orientação não define uma quantidade fixa para subtrair em todo lugar. Tampouco cria uma configuração obrigatória universal. O espaço necessário depende do que a rota adiciona e de quem recebe o resultado.

Um acordo operacional deveria identificar os acréscimos, a unidade de contagem e as mudanças que exigem revisão. Uma cadeia de validação diferente, uma nova serialização, outros campos ou outro destino podem alterar a relação entre entrada e saída. São possibilidades de projeto, não migrações observadas nesta pesquisa. A reserva feita sob certas condições não comprova que todas as condições futuras sejam iguais.

O certificado também não ocupa uma mensagem vazia. Seus campos compartilham capacidade com os campos enviados pelo cliente e com outros acréscimos do intermediário. A prova de que um objeto isolado pode ser analisado não demonstra que o conjunto inteiro caiba. Um exemplo que funciona tampouco assegura todas as rotas e combinações de informação.

A unidade de contagem não pode mudar no meio da conversa

RFC9440 representa certificados X.509 codificados em DER como Byte Sequences de Structured Fields. No texto do campo, o binário aparece em base64 delimitado por dois-pontos, sem espaços nem quebras de linha. A quantidade de bytes no objeto original e a quantidade na representação textual são diferentes.

O custo inclui a expansão da codificação, os delimitadores, os nomes e, quando houver uma lista, sua sintaxe. É possível calcular relações de comprimento a partir da serialização escolhida. Esse cálculo não estabelece o limite que toda aplicação deve aceitar; descreve a representação que precisa ser comparada à capacidade pertinente.

Há outra distinção dentro da palavra “decodificar”. HPACK ou QPACK recompõem nomes e valores textuais a partir de campos comprimidos. O valor do certificado ainda está em base64 nessa etapa. Decodificar depois esse base64 para obter DER é uma operação distinta. Não se deve substituir o tamanho dos campos textuais pelo tamanho menor do objeto binário ao avaliar o limite HTTP.

Bytes transmitidos e estado retido formam ainda outros custos. Uma referência curta a uma entrada de tabela pode reconstruir um valor longo. Uma transmissão literal pode dispensar a inserção na tabela sem remover o valor da requisição. Cada resultado é válido em sua unidade, mas não quita uma restrição de outra natureza.

Capacidade do analisador não é promessa de aceitação

Structured Fields ilustra o problema de trocar unidades. RFC8941 e seu sucessor RFC9651 exigem que analisadores de Byte Sequences suportem pelo menos 16.384 octetos depois da decodificação binária. Essa é uma capacidade do tipo de dado. Não obriga o servidor HTTP a admitir uma requisição completa que contenha um objeto desse tamanho, uma cadeia e outros campos, independentemente de seus limites.

O texto da requisição conserva o base64 após a descompressão HTTP. Nomes, delimitadores e valores adicionais continuam presentes. Copiar o mínimo do analisador para uma configuração textual trataria uma capacidade de interpretação como um orçamento da mensagem e, ao mesmo tempo, mudaria o que está sendo contado.

Uma implementação pode cumprir a capacidade exigida do analisador e aplicar uma margem operacional menor a uma requisição específica. Por outro lado, receber uma seção grande não demonstra a validade de um certificado, a identidade pretendida ou a autorização da aplicação. São condições separadas. O orçamento de volume não pode assumir a função de uma política de confiança.

O limite anunciado tem um dono e um contexto

RFC9110 não define um teto universal para linhas, valores ou seções de campos. Reconhece limites dos receptores e exige uma resposta apropriada de classe 4xx quando campos de uma requisição excedem o que o servidor quer processar. A advertência sobre ignorar esses campos diz respeito ao aumento da exposição a ataques de contrabando de requisições. Não é uma autorização para eliminar uma entrada de autenticação e continuar como se nada tivesse mudado.

No HTTP/2, RFC9113 usa SETTINGS_MAX_HEADER_LIST_SIZE. O ajuste é informativo: soma os comprimentos não comprimidos de nomes e valores, mais 32 octetos por linha de campo. Um limite inferior ao anunciado pode ser aplicado a determinada requisição. O valor inicial sem limite não estabelece capacidade infinita para aplicações, proxies ou rotas reais.

No HTTP/3, o nome é SETTINGS_MAX_FIELD_SECTION_SIZE. RFC9114 também conta nomes e valores não comprimidos, com mais 32 bytes por campo. O par que recebe o parâmetro deve evitar ultrapassá-lo, nos termos da recomendação do documento. Mas cada implementação do trajeto aplica suas próprias restrições; ficar abaixo de uma indicação não garante que a mensagem será aceita adiante.

Os nomes não são intercambiáveis entre versões e os números não medem simplesmente o bloco comprimido transmitido. A representação pode ser pequena no enlace e grande quando recomposta. Pode respeitar um ajuste de transporte e encontrar um limite operacional menor. Conhecer um máximo significa conhecer uma informação daquele receptor, não obter uma reserva irrevogável para todo o caminho.

Essa diferença importa para a revisão de mudanças. Alterar um destino pode mudar a capacidade pertinente sem alterar o tamanho do certificado. Alterar a codificação pode mudar o tamanho textual sem mudar o objeto DER. Nenhuma dessas possibilidades autoriza concluir que uma medida isolada representa a prontidão do conjunto. A pergunta precisa nomear o receptor, a representação e a requisição.

A cadeia opcional preserva condições específicas

Client-Cert só aparece em requisições e contém o certificado da entidade final. É um campo de valor único, sem lista nem ocorrências repetidas. Client-Cert-Chain é uma lista opcional de Byte Sequences na ordem de certificados do TLS. Exclui o certificado já transportado pelo primeiro campo e não pode aparecer sem ele.

A opcionalidade permite um acordo de configuração. Não torna uma ausência posterior neutra para a aplicação que esperava aquela informação. Se o problema de tamanho for resolvido com sua retirada, será necessário avaliar o novo acordo, não apenas verificar que a mensagem ficou menor. O objetivo é evitar que uma escolha de capacidade reescreva uma premissa da aplicação sem avisar seus responsáveis.

RFC9440 permite omitir a raiz quando se sabe que o servidor de origem destinatário possui a âncora de confiança omitida. Querer economizar bytes não satisfaz essa condição. A permissão também não justifica retirar arbitrariamente elementos de cadeia necessários até obter um volume conveniente. Trata-se de uma condição específica do receptor.

A lista pode ser distribuída em várias ocorrências de Client-Cert-Chain, com possível vantagem de compressão. Contudo, a contagem de campos também cobra nomes e parcelas fixas para as linhas adicionais. O formato favorável à reutilização pode deslocar custos para a seção inteira. É preciso conhecer o contador decisivo antes de escolher a representação.

A tabela maior não aumenta o orçamento da aplicação

RFC9440 aborda uma carga condicional: requisições de vários clientes multiplexadas numa conexão entre proxy e origem que usa compressão de campos. Valores grandes e variáveis de certificado podem reduzir significativamente a eficiência. Isso é uma consideração publicada no documento, não uma medição desta pesquisa nem uma conclusão sobre todos os sistemas de encaminhamento.

O RFC menciona que a origem poderia aumentar sua tabela dinâmica. Também sugere que um proxy, ao considerar a tabela insuficiente, talvez prefira enviar o valor sempre como literal em vez de registrá-lo nela. Uma alternativa disponibiliza mais estado para reutilização; outra evita reter valores pouco úteis à carga. Não há declaração de que uma delas vença em todas as situações.

RFC7541 define o cálculo de uma entrada HPACK pelo comprimento do nome e do valor antes de Huffman, mais 32 octetos. O protocolo limita a capacidade máxima permitida, e o codificador pode usar menos. Trata-se de contabilidade da tabela. Torná-la maior não altera automaticamente o limite que a aplicação aplica aos campos de uma requisição.

Em QPACK, RFC9204 limita a capacidade dinâmica máxima pela indicação SETTINGS_QPACK_MAX_TABLE_CAPACITY do decodificador. Um máximo zero impede inserções. Isso não é o máximo de seção de campos do HTTP/3 e não significa que toda forma de compressão seja impossível. Não se afirma que QPACK bloqueie obrigatoriamente requisições com certificados, nem se recomenda uma configuração universal.

O padrão de repetição é relevante. Uma série de certificados diferentes e um certificado estável reutilizado oferecem oportunidades distintas. A decisão sobre estado retido e bytes transmitidos precisa considerar esse padrão, sem assumir a função do limite de admissão. Mesmo quando uma única equipe opera as pontas, os recursos continuam separados.

O código de recusa não é um diagnóstico TLS

RFC6585 define 431 para o servidor que não quer processar campos grandes demais, como conjunto ou por uma linha específica. A requisição pode ser reenviada após redução; se um campo isolado causar o problema, a representação deveria indicá-lo. Mas o uso de 431 é opcional. Sob ataque, o texto admite descartar conexões ou tomar outras medidas. Não há promessa de um único resultado visível em todos os excessos.

O cliente talvez não controle os bytes adicionados pelo proxy. Repetir uma requisição inalterada não cria espaço. Apagar dados de certificado pode fazer o conjunto caber, mas pode mudar a entrada que a aplicação usa para autenticação ou seleção de resposta. “Coube” não demonstra que o comportamento da aplicação conservou o mesmo fundamento.

Há arranjos legítimos em que esses campos estão ausentes, inclusive com outros mecanismos de autenticação. A análise não exige negar qualquer requisição sem certificado. Exige que a ausência tenha um significado escolhido e compreendido, em vez de ser uma consequência escondida de um ajuste de capacidade. Esse significado pertence ao acordo da aplicação, não ao interesse momentâneo do compressor.

A retomada de sessão revela outra escolha. Algumas implementações TLS não retêm as informações de certificado ao retomar. RFC9440 recomenda que, se não puderem fornecer valores consistentes, desativem a retomada nessas conexões ou omitam desde o início um campo que possa faltar depois. São alternativas condicionais de desenho, não uma instrução para modificar serviços atuais nem uma afirmação de perda em toda retomada.

Cache de resposta e estado de compressão não são a mesma coisa

Quando Client-Cert determina a resposta, RFC9440 exige que ela não seja armazenável ou que sua reutilização se limite a requisições com o mesmo valor por Vary: Client-Cert. Para o proxy de terminação que encontre campos de certificado em Vary, a recomendação é transformar o valor em * para impedir o cache pelo agente do usuário. Respostas 431 não podem ser armazenadas em cache.

Essas regras tratam da reutilização de respostas, não de entradas HPACK/QPACK. Ampliar uma tabela não implementa a separação de respostas selecionadas por certificado. E uma ausência inesperada pode mudar o critério da aplicação, mesmo que o transporte continue operando. Capacidade, presença e seleção precisam permanecer reconhecíveis como condições diferentes.

O caminho confiável também mantém suas obrigações independentes: impedir a injeção dos campos, aceitá-los apenas pelo trajeto autorizado e proteger a comunicação contra observação ou alteração indevida. A conformidade com um limite de tamanho não demonstra essas proteções. O orçamento HTTP complementa, mas não substitui, o acordo de segurança do encaminhamento.

Fontes e alcance da análise

Os cenários são hipotéticos e não foram executados. A pesquisa usa especificações públicas, não telemetria operacional. Não relata incidente, parâmetro padrão de fornecedor, ganho medido, tamanho universal seguro ou teste negativo concluído. As propostas de operação são interpretação editorial, não novas exigências normativas.