Двама администратори сравняват тайната на екрана, съгласяват се, че съвпада, а тунелът все още не преминава удостоверяване. Низът, който са сравнили, не е стойността, която която и да е страна подава в извеждането на ключ. Между символите, които виждате, и байтовете, които протоколът хешира, има тип на поле, текстово кодиране, редактор и клипборд и всеки от четирите може да промени входа, без да промени вида му. Сравнете байтовете и разминаването обикновено се появява за секунди.

Какво прави шлюзът с низа

Предварително споделеният ключ не се изпраща по мрежата и не се сравнява. Всяка страна подава своето локално копие в извеждането на ключ за обмена IKE и получените полезни товари за удостоверяване или се проверяват, или не. Този дизайн означава, че двете копия трябва да са байтово идентични, а не визуално подобни, и също означава, че отказът се съобщава на етапа на удостоверяване, а не като съобщение за грешна парола.

Затова полезният въпрос никога не е „изглеждат ли еднакво“, а „каква точна последователност от байтове хешира всяка реализация“.

Откъде идват допълнителните байтове

Завършващият нов ред е класическият виновник и се крие пред очите, защото повечето редактори го добавят невидимо при запазване на файл. Водещ или завършващ интервал, поставен от чат прозорец, прави същото, както и умна кавичка, заменена с права от текстовия процесор. Никое от тези не променя визуалното сравнение, което прави човек.

Сравнявайте с инструмент, който показва байтове, а не глифове. printf '%s' "$PSK" | xxd | tail -2 отпечатва края на стойността в шестнадесетичен вид, където случайният 0a или 20 е очевиден. Направете го на двете страни и сравнете двата дъмпа един до друг. Правете това върху генериран тестов материал, а не върху производствена тайна, която после оставяте в историята на шела.

Кодирано не означава криптирано

Експортът на конфигурация често носи тайната в базово кодиране, понякога с прекъсвания на всеки шестдесет или седемдесет и шест знака, а понякога с допълване. Ако едната страна очаква декодираните байтове, а вие поставите кодирания текст, не сте изпратили различна парола, а много по-дълга парола от печатаеми символи. Base64 не осигурява никаква поверителност, поради което кодирана тайна никога не трябва да се поставя във форум за второ мнение.

Речникът на IPSec на Apple е полезен пример за значението на типа: той документира SharedSecret като данни за метода за удостоверяване със споделена тайна в полезните товари на L2TP и Cisco IPsec. Това е конкретно свойство в конкретен товар, а не общо текстово поле, което можете да използвате повторно за друг протокол, който случайно иска тайна.

Твърдяната граница принадлежи на една комбинация

Старите доклади за таван от тридесет и два знака при един клиент на Apple са реални доклади за една версия на клиента, протокол и форма на профила. Те не са универсална граница за всяка платформа на Apple, всеки доставчик и всеки протокол. Проверете версията, типа на товара и изискването на шлюза заедно, след което тествайте при одобрена схема, вместо да правите изводи от тема. Запишете тестваната комбинация в записа за промени, защото иначе следващият човек ще цитира същата тема с повече увереност, отколкото тя заслужава.

Ако границата наистина се прилага, отговорът е поддържан дизайн на идентификационни данни, който се побира в нея, а не съкратена версия на силна тайна. Подрязването на производствен ключ, за да се удовлетвори предполагаема граница, намалява силата му за постоянно и създава система, чиято документация вече не съответства на сигурността ѝ.

Поправете представянето, не силата

Когато удостоверяването се провали, след като представянето е потвърдено, прочетете действащата политика на етапа на удостоверяване: кой метод се договаря, каква самоличност на партньора се очаква и дали шлюзът съответства на връзката, която мислите. Постепенно по-слабите предположения не са диагностика, а бавно понижаване с прикачен тикет за поддръжка.

Ако изискваните идентификационни данни не могат да отговорят на стандарта на организацията, променете дизайна на такъв, който може. Споделена тайна с достатъчно ентропия, генерирана веднъж, съхранена в управлявано поле и никога не публикувана, е напълно добър отговор; по-кратка нейна версия не е.

Подобни статии