Summary

  • O RFC 9931 deixa claro que terminar um pedido Upgrade ou CONNECT é necessário, mas não suficiente, para mudar o estado de uma conexão HTTP/1.1. Um sucesso recente pode alimentar uma previsão; apenas o 101 Switching Protocols ou o 2xx desta tentativa confirma a transição atual.
  • Quando um cliente HTTP confiável libera, antes da confirmação, bytes escolhidos por uma parte não confiável, a rejeição pode levar o servidor a lê-los como outro pedido HTTP autenticado. A prova operacional necessária registra a espera, a resposta, a regra de liberação e o parser final, sem guardar o conteúdo transportado.

A otimização antecipa dados e também uma conclusão

Enviar cedo pode economizar uma ida e volta inteira. Se o servidor quase sempre aceita o protocolo proposto, esperar a resposta parece desperdício. O cliente encerra o pedido HTTP/1.1 e começa a transmitir dados que espera serem consumidos pelo novo protocolo. Quando a aposta acerta, o serviço útil começa mais cedo.

Publicado em março de 2026 na trilha de padrões da IETF, o RFC 9931 examina o que acontece quando essa aposta falha. O documento atualiza os RFCs 9112 e 9298. Sua intervenção não é uma condenação genérica da baixa latência. É uma separação entre dois eventos que um log apressado pode juntar: concluir o pedido de transição e receber a aceitação da transição.

No mecanismo Upgrade, o cliente propõe outro protocolo de aplicação para a conexão existente. A resposta 101 Switching Protocols informa que o servidor entendeu e aceitou, além de indicar o protocolo que passa a vigorar. Em CONNECT, um 2xx bem-sucedido muda a conexão para túnel depois do cabeçalho da resposta. Qualquer outra resposta significa que o túnel não foi formado.

As regras de HTTP já impediam iniciar o protocolo novo no meio do pedido. O RFC 9931 explicita que terminar o pedido é só uma condição necessária. O servidor pode desconhecer o token, exigir autenticação, rejeitar porta ou destino, falhar ao resolver o nome ou simplesmente preferir continuar em HTTP/1.1. Antes da resposta, há uma expectativa, não um fato de estado.

Memória operacional não é resposta corrente

Um operador responsável deve observar o passado. Compatibilidade documentada, testes, taxa de rejeição e êxitos recentes ajudam a escolher uma coorte, projetar capacidade e comparar o ganho de latência com o custo de proteção. O erro seria tratar toda evidência histórica como inútil.

Mas seu alcance precisa permanecer visível. Entre duas conexões podem mudar credenciais, rota, backend, política de destino ou cadeia de intermediários. Mesmo sem mudança, o serviço remoto pode falhar nesta tentativa. O protocolo entrega ao servidor atual a decisão sobre o pedido atual. Nenhuma média emite um 101 ou um 2xx ausente.

Frases abreviadas fazem a troca de evidência parecer natural. “O proxy aceita CONNECT” passa a significar “este CONNECT foi aceito”. “O token é registrado” vira “a conexão mudou”. “Sempre funcionou” vira permissão permanente para adiantar dados. Em cada passo desaparece uma chave: o identificador da conexão, o pedido, a resposta ou o instante.

Um registro honesto mantém duas superfícies. A primeira guarda sinais preditivos: versão, teste, documentação e histórico. A segunda guarda o evento decisivo: versão HTTP, época da conexão, resposta corrente e protocolo escolhido. As superfícies podem concordar quase sempre e ainda responder a perguntas diferentes.

O terceiro participante muda a autoria dos bytes

O RFC 9931 não afirma que toda transição entre duas partes introduz esse risco. Se ambas já aceitam dados arbitrários uma da outra, errar a previsão pode permanecer um erro de protocolo. A estrutura crítica aparece quando o servidor confia no cliente HTTP, mas o material encaminhado pelo cliente é controlado por uma terceira aplicação não confiável.

Pense em uma aplicação local pedindo a um cliente proxy autenticado que abra um túnel TCP. A aplicação entrega logo seus primeiros bytes destinados ao serviço remoto. O cliente os encaminha antes do 2xx. Se o destino não puder ser alcançado, o proxy rejeita CONNECT e continua esperando outro pedido HTTP/1.1 na mesma conexão.

A aplicação maliciosa pode compor os bytes para que também formem um pedido HTTP válido ao próprio proxy. O servidor os recebe numa conexão associada ao cliente confiável, talvez autenticada por certificado em nível de conexão. Dados escolhidos pela aplicação ganham a identidade que o cliente detinha. O RFC 9112 descreve request smuggling como o uso de diferenças de parsing para esconder pedidos que uma política poderia bloquear.

Há três falhas distintas. A previsão estava errada. Emissor e receptor adotaram gramáticas diferentes. E o servidor atribuiu a ação a quem não escolheu seu conteúdo. Um painel que conta apenas transições rejeitadas enxerga somente a primeira.

Nem todo fluxo precisa formar um pedido completo para ser perigoso. Um parser criado com a premissa de entrada confiável passa a receber material controlado por terceiros. Isso não demonstra uma vulnerabilidade em produto específico. Demonstra por que o momento da liberação faz parte da fronteira de autoridade.

WebSocket, UDP e IP não compartilham uma única política

O WebSocket já exige espera. Depois de enviar o handshake de abertura, o cliente precisa receber e validar a resposta antes de transmitir dados adicionais. O mascaramento de alta entropia nos frames cliente-servidor é outra propriedade que reduz sua reutilização como pedido HTTP.

O RFC 9298 permitia iniciar de maneira otimista o envio de pacotes UDP antes da resposta do proxy. O RFC 9931 restringe essa permissão a HTTP/2 ou posterior e a proíbe em HTTP/1.x. O RFC 9484 faz distinção semelhante para pacotes IP. Um intermediário que converte HTTP/2 ou HTTP/3 em HTTP/1.1 deve segurar as cápsulas até analisar uma resposta de proxy bem-sucedida.

O motivo é estrutural. Em HTTP/1.1, os pedidos são sequenciais e a fronteira seguinte é inferida do término da anterior. HTTP/2 e HTTP/3 separam pedidos por streams explícitos. Assim se evita esta ambiguidade específica, em que dados da transição rejeitada ocupam a posição sintática de outro pedido HTTP/1.1. Não se prova a segurança geral da versão nova, do destino ou do conteúdo do túnel.

Para futuros tokens Upgrade, o RFC 9931 aponta escolhas possíveis: proibir o envio otimista, iniciar o novo protocolo com um preâmbulo fixo que encerre sem dúvida o parsing HTTP/1.1 ou aplicar mascaramento de alta entropia. Quando o método HTTP perde relevância após a troca, usar GET sem conteúdo também reduz a matéria exposta a duas interpretações.

O registro de tokens da IANA fornece nomes e referências. Ele não verifica conexões. Um token registrado tem proveniência de especificação, não confirmação de que um endpoint o aceitou agora.

O caminho de rejeição em CONNECT é responsabilidade dos dois lados

Para um cliente proxy HTTP/1.1 que atua em nome de um cliente TCP não confiável, o RFC 9931 exige pelo menos uma de duas condutas. Esperar o 2xx antes de encaminhar payload TCP, ou incluir Connection: close no pedido. A segunda opção impede que uma rejeição preserve a conexão para interpretar bytes antecipados como pedido seguinte. As duas podem ser usadas juntas.

O servidor proxy que rejeita CONNECT também deve fechar a conexão subjacente sem processar pedidos posteriores. Essa defesa contém clientes que enviaram cedo demais. Há um custo: uma resposta 407 de autenticação pode exigir nova conexão em vez de reutilizar a existente.

Por isso o RFC permite ao servidor desativar a mitigação quando sabe que o cliente espera o 2xx. O texto menciona User-Agent e documentação do fornecedor para identificar clientes conformes. Já o RFC 9110 descreve User-Agent como informação sobre o software originador e desencoraja disfarces; não o define como identidade autenticada.

Uma exceção de desempenho precisa ser datada. Ela deve indicar produto e versão, documento avaliado, teste local, intermediários cobertos, responsável, prazo e condição de rollback. Uma atualização pode mudar a ordem de envio. A frase “cliente conhecido” não pode atravessar essa mudança sem nova verificação.

Um recibo da fronteira, não uma cópia do tráfego

A resposta decisiva já existe no protocolo. O problema é que tentativa, liberação de bytes e estado final costumam ficar em registros distintos. Daniel Kade propõe um recibo compacto de confirmação de transição para caminhos que transportam dados de terceiros.

O primeiro bloco identifica época da conexão e versão HTTP. Registra Upgrade ou CONNECT, token ou tipo de túnel e, quando necessário, uma referência protegida ao destino. Classifica a origem do material como controle próprio, subsistema limitado ou terceiro não confiável, sem copiar o payload.

O segundo descreve a barreira. Qual implementação e política decidiram a liberação? O caminho esperou 101 ou 2xx, exigiu fechamento, usou preâmbulo, mascaramento ou stream separado? Algum byte cruzou antes da resposta? Se cruzou, qual construção permitida sustentava isso, em vez de uma mera confiança no histórico?

O último bloco liga resposta, protocolo escolhido, parser ou túnel efetivo, destino da conexão rejeitada e ação de contenção. Exceções carregam evidência, escopo, dono, validade e gatilhos de invalidação. Mudanças em cliente, servidor, intermediário, autenticação ou política abrem nova decisão.

O recibo não guarda tráfego, certificados, credenciais, cabeçalhos de autorização ou segredos. Também não transforma 2xx em autorização de negócio: ele confirma a formação do túnel. As ações internas ainda dependem das políticas da aplicação e do serviço.

Essa é uma proposta editorial, não um requisito do RFC 9931 nem um novo campo HTTP. Sua função é preservar um fato pequeno: qual resposta corrente abriu a fronteira para quais bytes e sob qual regra.

Limites do que as fontes permitem dizer

As fontes não identificam produto vulnerável, exploração real, prevalência ou taxa de implementação incorreta. Também não elegem uma mitigação universal. Espera, fechamento, buffer, preâmbulo, mascaramento e migração de versão têm custos diferentes.

Latência e recursos são restrições legítimas. Uma otimização governável não precisa ser lenta; precisa falhar sem confundir parser, autor e estado. O controle adequado preserva o resultado e oferece correção quando a previsão não se cumpre.

A conclusão verificável permanece estreita: um sucesso anterior pode melhorar a previsão. Só a resposta da tentativa atual confirma a próxima transição.

Sources

  1. RFC 9931: considerações de segurança para transições otimistas em HTTP/1.1
  2. Página do RFC 9931 no RFC Editor
  3. RFC 9110: semântica HTTP
  4. RFC 9112: HTTP/1.1
  5. RFC 9298: proxy de UDP em HTTP
  6. RFC 6455: protocolo WebSocket
  7. RFC 9484: proxy de IP em HTTP
  8. RFC 9113: HTTP/2
  9. RFC 9114: HTTP/3
  10. Registro de tokens HTTP Upgrade da IANA
  11. Heng Lu, “The Policy Mirror”
  12. Heng Lu, “Minimum Initial Specification, Localized Future Decision, Voluntary Adoption”
  13. Heng Lu, “On Why BTW Media Exists, and Why Reality, Not Advocacy, Is the Product”