Varför kryptering ensam inte stoppar ett återuppspelat paket
Ett gammalt paket behåller en giltig autentiseringstagg, så integritet bevisar aldrig färskhet. Sekvenstillstånd och ett mottagarfönster gör det jobbet.
Skyddade paket löper inte ut kryptografiskt, så ett paket som var giltigt för fem minuter sedan är fortfarande giltigt nu, eftersom kryptering och integritetsskydd inte säger något om när byten skapades. En angripare som kan fånga och skicka om trafik behöver inte knäcka chiffern. Därför bär varje seriös tunnelprotokoll sekvenstillstånd vid sidan av sina nycklar.
Mekanismen är liten, och dess fellägen är lätta att förväxla med paketförlust.
Giltig chiffertext är inte färsk chiffertext
Autentisering svarar på en fråga: kom dessa byten oförändrade från någon som har nyckeln. Den svarar inte på om det är första gången mottagaren ser dem. Ett återuppspelat paket klarar det första provet perfekt, och det är just därför enbart integritetskontroll inte kan stoppa en återuppspelning och därför behöver protokollet en andra regel om acceptans. En mottagare som bara autentiserar har inget försvar mot en angripare med en inspelning.
Den regeln är billig att implementera och billig att formulera: acceptera ett givet skyddat paket en gång, under en given nyckel. Allt annat på detta område följer av hur implementationen håller reda på den enda gången.
Att läsa en återuppspelningsförkastning som ett dekrypteringsfel skickar dig till helt fel delsystem.
Ett sekvensnummer och ett fönster
IPsec ESP bär ett sekvensnummer och mottagaren håller ett glidande fönster över nyligen accepterade värden, medan ESP-specifikationen beskriver standardfönstrets storlek och möjligheten att utvidga det. WireGuard tar en annan väg med en räknare per nyckel och en explicit kontroll mot den. Ingen av konstruktionerna förutsätter att paket anländer i ordning, eftersom riktiga nätverk ordnar om dem. Båda tål omordning, och ingen av dem tål upprepning.
Fönstret är det som gör den toleransen möjlig. Ett paket strax bakom det högsta sedda värdet kan fortfarande accepteras om det inte har accepterats tidigare; ett långt bakom, eller ett vars plats redan är markerad, kastas. Öka fönstret så tål du mer omordning till priset av mer tillstånd per association.
Diagnostiska räknare visar vilket fall du är i. Återuppspelningsförkastningar ökar en specifik räknare i stället för ett generiskt fel, och att läsa den räknaren är den första användbara observationen.
nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer
Tillstånd tillhör nyckeln, inte värden
Räknartillstånd är knutet till en säkerhetsassociation eller en nyckelepok, så en nyckelväxling skapar en färsk kontext och sitt eget sekvensrum. Att rensa en räknare utan att byta ut nyckeln, eller att återanvända en association efter en manuell återställning, bryter det antagande som mottagarens fönster vilar på. Därför finns protokollstyrd nyckelväxling i stället för en återställningsknapp som operatören ser.
När en tunnel beter sig illa efter ett manuellt ingrepp, fråga om ingreppet rörde sekvenstillståndet. En konfiguration som ser identisk ut kan bete sig annorlunda eftersom tillståndet den ärvde inte är det förväntade.
Diagnostisera orsaken innan du inaktiverar något
Förlust, omordning, duplicerad trafik och ett implementeringsfel visar sig alla som omsändningar, och bara en av dem är ett återuppspelningsproblem. Att stänga av kontrollen för att tysta brus tar bort egenskapen du förlitade dig på och gör den ursprungliga orsaken svårare att hitta, eftersom omsändningarna nu inte har någon förklaring alls.
Samla avgränsade bevis: associations-ID:n, sekvensnummer och räknare, utan nyttolasterna. Det räcker för att skilja en dubblett från en omordnad ankomst, och det gör inte din diagnostikfil till en kopia av användarens trafik.
Vad kontrollen inte lovar
Återuppspelningsskydd är en egenskap hos paketbehandling inom ett protokoll. Det betyder inte att operatören inte för loggar, att en webbplats inte kan känna igen ett konto eller att en session är anonym. Det är separata frågor om separata system, och en stark anti-återuppspelningsdesign svarar på ingen av dem.
Underhållen programvara med stödda inställningar är den praktiska kontroll en användare har. Protokollet hanterar paketet; allt annat förblir ett driftbeslut.