Зашто само шифровање не зауставља поново послат пакет
Стари пакет задржава важећу ознаку провере аутентичности, па интегритет никада не доказује свежину. Стање низа и прозор примаоца обављају тај посао.
Заштићени пакети криптографски не истичу, па је пакет који је био важећи пре пет минута важећи и сада, јер шифровање и заштита интегритета не говоре ништа о томе када су бајтови настали. Нападачу који може да пресретне и поново пошаље саобраћај није потребно да разбије шифру. Зато сваки озбиљан тунелски протокол носи стање низа уз своје кључеве.
Механизам је мали, а његови начини отказа лако се мешају са губитком пакета.
Важећи шифровани текст није свеж шифровани текст
Аутентикација одговара на једно питање: да ли су ови бајтови дошли неизмењени од онога који има кључ. Она не одговара да ли их прималац види први пут. Поново послат пакет беспрекорно пролази први тест, и управо зато само провера интегритета не може да заустави понављање и зато је протоколу потребно друго правило о прихватању. Прималац који само аутентикује нема одбрану од нападача који држи снимак.
То правило је јефтино за примену и јефтино за формулацију: прихвати дати заштићени пакет једном, под датим кључем. Све остало у овој области произлази из тога како имплементација прати тај један пут.
Читање одбацивања због понављања као грешке дешифровања шаље вас у потпуно погрешан подсистем.
Редни број и прозор
IPsec ESP носи редни број и прималац држи клизни прозор недавно прихваћених вредности, при чему спецификација ESP описује подразумевану величину прозора и могућност његовог проширења. WireGuard иде другим путем са бројачем по кључу и експлицитном провером против њега. Ниједан дизајн не претпоставља да пакети пристижу по реду, јер стварне мреже их преуређују. Оба толеришу преуређивање и ниједно не толерише понављање.
Прозор је оно што ту толеранцију чини могућом. Пакет мало иза највише виђене вредности још може бити прихваћен ако претходно није био прихваћен; пакет далеко иза, или онај чије је место већ означено, одбацује се. Повећајте прозор и толерисаћете више преуређивања по цени више стања по асоцијацији.
Дијагностички бројачи показују у ком сте случају. Одбацивања због понављања повећавају одређени бројач, а не општу грешку, и читање тог бројача је прво корисно запажање.
nstat -az | grep -i XfrmIn
ip -s xfrm state | head -n 30
wg show wg0 transfer
Стање припада кључу, не хосту
Стање бројача је везано за безбедносну асоцијацију или за епоху кључа, па измена кључа ствара свеж контекст и сопствени простор низа. Брисање бројача без замене кључа или поновна употреба асоцијације после ручног ресетовања крши претпоставку на коју се ослања прозор примаоца. Зато постоји измена кључева вођена протоколом, а не дугме за ресетовање видљиво оператеру.
Када се тунел понаша лоше после ручне интервенције, питајте да ли је интервенција дотакла стање низа. Конфигурација која изгледа идентично може се понашати другачије јер наслеђено стање није оно које очекује.
Дијагностикујте узрок пре него што било шта искључите
Губитак, преуређивање, дуплирани саобраћај и дефект имплементације испољавају се као поновна слања, и само једно од њих је проблем понављања. Искључивање провере да би се утишала бука уклања својство на које сте се ослањали и отежава проналажење првобитног узрока, јер поновна слања сада немају никакво објашњење.
Прикупите ограничене доказе: идентификаторе асоцијације, редне бројеве и бројаче, без корисног терета. То је довољно да се разликује дупликат од преуређеног доласка, и не претвара вашу дијагностичку датотеку у копију саобраћаја корисника.
Шта провера не обећава
Заштита од понављања је својство обраде пакета унутар једног протокола. Она не значи да оператер не води евиденцију, да сајт не може да препозна налог или да је сесија анонимна. То су одвојена питања о одвојеним системима, и снажан дизајн против понављања не одговара ни на једно од њих.
Одржавани софтвер са подржаним подешавањима је практична контрола доступна кориснику. Пакетом се бави протокол; све остало остаје оперативна одлука.