Resumo
- A RFC 793 aceitava, em estados sincronizados, um RST dentro da janela; a RFC 5961 reservou o reset imediato à igualdade exata com
RCV.NXT. - Um RST dentro da janela, mas não exato, recebe um challenge ACK e é descartado. O par legítimo pode confirmar seu estado; um emissor cego normalmente não vê o desafio.
O defeito vinha de uma pergunta usada para decidir duas coisas. A janela de recepção indica se determinados bytes poderiam pertencer ao fluxo. Pela regra original da RFC 793, essa mesma plausibilidade também podia autorizar a remoção de todo o estado quando o bit RST estivesse presente. Um atacante fora do caminho, sem observar os pacotes, podia variar números de sequência até acertar algum ponto da janela.
A RFC 5961, de 2010, não adicionou criptografia ao TCP. Ela introduziu uma etapa intermediária. Um RST fora da janela continua sendo descartado em silêncio. Um RST exatamente igual ao próximo byte esperado, RCV.NXT, encerra a conexão. Se estiver dentro da janela sem ser exato, o receptor envia um ACK com SEQ=SND.NXT e ACK=RCV.NXT, descarta o segmento suspeito e segue processando o tráfego posterior.
O nome challenge ACK descreve a função: transformar uma afirmação em uma prova de estado. Se o extremo remoto realmente fechou ou reiniciou e perdeu o bloco de controle antigo, o ACK recebido pode fazê-lo enviar outro RST derivado do número de reconhecimento. Esse segundo RST pode coincidir exatamente com o valor esperado. O injetor cego não observa a pergunta e, em geral, não consegue converter um palpite aproximado na resposta precisa.
Assim, a RFC separou admissibilidade de autoridade. Estar na janela basta para merecer resposta, mas não para ordenar uma transição irreversível. Entre ignorar e destruir, o TCP ganhou uma operação reversível: desafiar enquanto preserva a conexão.
A mesma lógica alcança um SYN inesperado em estado sincronizado. A mitigação envia challenge ACK independentemente da sequência apresentada e interrompe o processamento daquele segmento. Um SYN falsificado costuma gerar apenas um ACK extra, tratado como duplicado pelo par estabelecido. Um host que de fato reiniciou não possui mais o estado anterior e pode responder de modo a confirmar que a conexão velha terminou.
Os limites são claros. O desafio não autentica identidade e não bloqueia um adversário no caminho que observe sequências e ACKs. Há ainda um raro caso de reinício com reutilização do mesmo endereço, porta e um número inicial específico. A mudança encarece ataques cegos; não transforma TCP em protocolo criptográfico.
As forças normativas também diferem. As mitigações de RST e SYN são recomendadas, enquanto a checagem mais estreita de ACK contra injeção de dados é opcional. A RFC 9293, base atual do TCP, preserva a formulação geral e aponta a RFC 5961 como reforço. A correção permanece visível como camada histórica, não como reescrita silenciosa do passado.
Fontes primárias
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
