Por que a encriptação por si só não impede um pacote reenviado

Os pacotes protegidos não expiram criptograficamente, por isso um que era válido há cinco minutos continua válido agora, porque a encriptação e a proteção de integridade não dizem nada sobre quando os bytes foram produzidos. Um atacante que consegue capturar e reenviar tráfego não precisa de quebrar a cifra. É por isso que cada protocolo de túnel sério transporta estado de sequência ao lado das suas chaves.

O mecanismo é pequeno, e os seus modos de falha confundem-se facilmente com a perda de pacotes.

O texto cifrado válido não é texto cifrado fresco

A autenticação responde a uma pergunta: estes bytes vieram, sem alteração, de alguém que detém a chave. Não responde se é a primeira vez que o recetor os vê. Um pacote reenviado passa perfeitamente no primeiro teste, e é exatamente por isso que a verificação de integridade sozinha não consegue travar um reenvio e que o protocolo precisa de uma segunda regra sobre a aceitação. Um recetor que apenas autentica não tem defesa contra um atacante que possui uma gravação.

Essa regra é barata de implementar e barata de enunciar: aceitar um dado pacote protegido uma vez, sob uma dada chave. Todo o resto nesta área decorre de como a implementação acompanha essa única vez.

Ler um descarte por reenvio como uma falha de decifragem envia-o para o subsistema completamente errado.

Um número de sequência e uma janela

O IPsec ESP transporta um número de sequência e o recetor mantém uma janela deslizante dos valores aceites recentemente, com a especificação ESP a descrever o tamanho de janela predefinido e a opção de a ampliar. O WireGuard segue outro caminho, com um contador por chave e uma verificação explícita contra ele. Nenhum dos desenhos assume que os pacotes chegam por ordem, porque as redes reais reordenam-nos. Ambos toleram a reordenação, e nenhum tolera a repetição.

É a janela que torna essa tolerância possível. Um pacote ligeiramente atrás do valor mais alto visto ainda pode ser aceite se não tiver sido aceite antes; um muito atrás, ou um cujo lugar já está marcado, é descartado. Aumente a janela e tolera mais reordenação ao custo de mais estado por associação.

Os contadores de diagnóstico mostram-lhe em que caso está. Os descartes por reenvio incrementam um contador específico em vez de um erro genérico, e ler esse contador é a primeira observação útil.

nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer

O estado pertence à chave, não ao anfitrião

O estado do contador está ligado a uma associação de segurança ou a uma época de chave, por isso uma renovação de chave cria um contexto novo e o seu próprio espaço de sequência. Apagar um contador sem substituir a chave, ou reutilizar uma associação após um reinício manual, quebra a suposição de que depende a janela do recetor. É por isso que existe renovação de chaves conduzida pelo protocolo em vez de um botão de reinício visível ao operador.

Quando um túnel se comporta mal após uma intervenção manual, pergunte se a intervenção tocou o estado de sequência. Uma configuração que parece idêntica pode comportar-se de forma diferente porque o estado herdado não é o estado que espera.

Diagnostique a causa antes de desativar seja o que for

Perda, reordenação, tráfego duplicado e um defeito de implementação manifestam-se todos como retransmissões, e apenas um deles é um problema de reenvio. Desativar a verificação para silenciar o ruído remove a propriedade em que confiava e torna a causa original mais difícil de encontrar, porque agora as retransmissões não têm qualquer explicação.

Recolha provas limitadas: identificadores de associação, números de sequência e contadores, sem as cargas úteis. Isso basta para distinguir um duplicado de uma chegada reordenada, e não transforma o seu ficheiro de diagnóstico numa cópia do tráfego do utilizador.

O que a verificação não promete

A proteção contra reenvio é uma propriedade do processamento de pacotes dentro de um protocolo. Não significa que o operador não guarde registos, que um sítio web não possa reconhecer uma conta ou que uma sessão seja anónima. São questões separadas sobre sistemas separados, e um desenho sólido contra reenvio não responde a nenhuma delas.

O software mantido com definições suportadas é o controlo prático de que um utilizador dispõe. O protocolo trata do pacote; tudo o resto continua a ser uma decisão operacional.