Ключ IPsec з папярэднім агулам: байты за радком, які вы ўвялі

Два адміністратары параўноўваюць сакрэт на экране, пагаджаюцца, што ён супадае, а тунель усё роўна не праходзіць аўтэнтыфікацыю. Радок, які яны параўналі, не з’яўляецца значэннем, якое любы з бакоў падае ў вылічэнне ключа. Паміж сімваламі, якія вы бачыце, і байтамі, якія хэшуе пратакол, ёсць тып поля, кадаванне тэксту, рэдактар і буфер абмену, і любы з чатырох можа змяніць увод, не змяняючы яго выгляду. Параўнайце байты, і разыходжанне звычайна выяўляецца за секунды.

Што шлюз робіць з радком

Папярэдне агучаны ключ не перадаецца па сетцы і не параўноўваецца. Кожны бок падае сваю лакальную копію ў вылічэнне ключа для абмену IKE, і атрыманыя карысныя нагрузкі аўтэнтыфікацыі альбо праходзяць праверку, альбо не. Такі дызайн азначае, што дзве копіі павінны быць пабайтава аднолькавымі, а не візуальна падобнымі, і гэта таксама азначае, што збой паведамляецца на этапе аўтэнтыфікацыі, а не як паведамленне пра няправільны пароль.

Таму карыснае пытанне ніколі не «ці выглядаюць яны аднолькава», а «якую дакладную паслядоўнасць байтаў хэшуе кожная рэалізацыя».

Адкуль бяруцца лішнія байты

Завяршальны перанос радка — класічны віноўнік, і ён хаваецца на віду, бо большасць рэдактараў незаўважна дадае яго пры захаванні файла. Прабел у пачатку або канцы, устаўлены з акна чата, робіць тое ж самае, як і разумная двукоссе, замененае прамалінейным тэкставым працэсарам. Нішто з гэтага не змяняе візуальнае параўнанне, якое выконвае чалавек.

Параўноўвайце з інструментам, які паказвае байты, а не гліфы. printf '%s' "$PSK" | xxd | tail -2 друкуе хвост значэння ў шаснаццатковым выглядзе, дзе выпадковы 0a або 20 відавочны. Зрабіце гэта на абодвух баках і параўнайце два дампы побач. Рабіце гэта на згенераваным тэставым матэрыяле, а не на працоўным сакрэце, які потым застанецца ў гісторыі абалонкі.

Кадаванае — не зашыфраванае

Экспарты канфігурацыі часта перадаюць сакрэт у базавым кадаванні, часам з пераносамі радкоў праз кожныя шэсцьдзясят або семдзесят шэсць сімвалаў, а часам з дапаўненнем. Калі адзін бок чакае дэкадаваныя байты, а вы ўстаўляеце кадаваны тэкст, вы не адправілі іншы пароль, вы адправілі значна даўжэйшы пароль з друкаваных сімвалаў. Base64 не забяспечвае ніякай канфідэнцыйнасці, і таму кадаваны сакрэт ніколі нельга ўстаўляць на форум для другога меркавання.

Слоўнік IPSec ад Apple — карысны прыклад важнасці тыпу: ён дакументуе SharedSecret як даныя для метаду аўтэнтыфікацыі агульным сакрэтам у карысных нагрузках L2TP і Cisco IPsec. Гэта канкрэтная ўласцівасць у канкрэтнай нагрузцы, а не агульнае тэкставае поле, якое можна перавыкарыстаць для іншага пратакола, што выпадкова просіць сакрэт.

Заяўленая мяжа адносіцца да аднаго спалучэння

Старыя паведамленні пра столь у трыццаць два сімвалы ў адным кліенце Apple — гэта рэальныя паведамленні пра адну версію кліента, пратакол і форму профілю. Яны не ўніверсальная мяжа для кожнай платформы Apple, кожнага правайдра і кожнага пратакола. Праверце версію, тып нагрузкі і патрабаванне шлюза разам, затым праверце на зацверджанай схеме, а не рабіце высновы з галіны форуму. Запішыце праверанае спалучэнне ў запіс пра змены, бо інакш наступны чалавек спашлецца на тую ж галіну з большай упэўненасцю, чым яна заслугоўвае.

Калі мяжа сапраўды дзейнічае, адказ — падтрыманая схема ўліковых даных, якая ў яе ўпісваецца, а не скарочаная версія моцнага сакрэту. Абразанне працоўнага ключа, каб задаволіць меркаваную мяжу, назаўсёды зніжае яго моц і стварае сістэму, дакументацыя якой больш не адпавядае яе бяспецы.

Выпраўляйце прадстаўленне, а не моц

Калі аўтэнтыфікацыя не праходзіць пасля пацверджання прадстаўлення, прачытайце дзейную палітыку на этапе аўтэнтыфікацыі: які метад узгадняецца, якая асоба партнёра чакаецца і ці шлюз супастаўляе тое злучэнне, пра якое вы думаеце. Паступова больш слабыя здагадкі — гэта не дыягностыка, а павольнае паніжэнне з прымацаваным тыкетам падтрымкі.

Калі патрабаваныя ўліковыя даныя не могуць адпавядаць стандарту арганізацыі, змяніце дызайн на такі, што можа. Агульны сакрэт з дастатковай энтрапіяй, згенераваны адзін раз, які захоўваецца ў кіраваным полі і ніколі не публікуецца, — цалкам добры адказ; яго карацейшая версія — не.