Проследяване на контролни пакети на OpenVPN: tls-auth преди TLS

Отказ на tls-auth обикновено се съобщава като проблем с ръкостискането, а никога не е бил такъв. HMAC се проверява върху контролния пакет преди каквато и да е обработка на TLS, така че несъответстващ ключ или посока дава отказ, който изглежда като проблем със сертификат и се решава два слоя по-рано. Третирането на плика като самостоятелен обект прави диагнозата кратка: прочетете полетата, потвърдете, че проверката се задейства рано, после сравнете трите неща, по които двете страни трябва да се съгласят.

Четете плика в реда, в който се изгражда

Контролният пакет носи идентификатор на сесията, незадължителния HMAC на tls-auth, информация за повторение и потвърждение и надежден идентификатор на съобщението, а след това идва полезният товар на типа съобщение. Когато съобщението е съобщение за ръкостискане, полезният товар се оказва TLS шифротекст. Цялата връзка е точно такава: TLS материалът пътува вътре в съобщение, което пликът вече защитава. Вижте справката за мрежовия протокол на OpenVPN която изброява полетата на контролния канал в този ред.

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

Дръжте това групиране като концепция. То не е диаграма на реда на байтовете и не е достатъчно, за да се изчисли етикет, защото полетата, които влизат в HMAC, зависят от реализацията, версията и режима.

Покажете, че проверката се задейства преди ръкостискането

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

Увеличете подробността на демона и наблюдавайте контролния канал, а не устройството tun:

openvpn --config /etc/openvpn/server.conf --verb 6

Търсите отказ при проверка на HMAC на контролния канал, отчетен на ниво пакет, преди каквото и да е TLS предупреждение. TLS предупреждение в журнала означава, че пликът е приет и отказът се е преместил навътре, което е друго разследване с друго решение.

Обработката на посоката също е тук. Когато статичен ключов файл се използва с tls-auth, двете страни заемат противоположни посоки на ключа и протоколът използва това разделяне, за да не може прихванат пакет да бъде отразен обратно към изпращача. Обърнатата посока оставя ключа същия и въпреки това проваля всеки пакет. Променяйте по една страна наведнъж, после рестартирайте и двата демона, за да се зареди двойката заедно.

Съгласувайте ключ, посока и digest от двете страни

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

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Генерирайте споделената тайна с инструмента, а не с редактор, и дръжте правата стегнати:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

Не бъркайте tls-auth с tls-crypt. И двете защитават контролния канал, но tls-crypt също го криптира и скрива ръкостискането от наблюдатели, и заменя разделянето на посоките със своя собствена обработка на ключове. Профил с едното няма да работи с партньор, конфигуриран за другото, и никакво настройване на digest не запълва тази пропаст.

Възпроизвеждайте етикет само от истинския формат

Възпроизвеждането с точност до байт е отделна задача от пускането на VPN и работи само с истинските входни данни: реализацията и версията, които са изградили пакета, избрания digest, посоката и действителните байтове, включително идентификатора на сесията и масива от потвърждения. Текстово изобразяване на списъка с полета не е тези байтове.

Дължината на етикета следва от digest, така че допускането за фиксирана дължина се счупва в момента, в който някой я промени. Хеширайте пакета както прави реализацията, а не както го представя таблица в блог публикация, и сравнявайте със заснемане от същия партньор, а не с очакване, изведено на ръка.

Дръжте това упражнение далеч от производствени профили. Нищо във възпроизвеждането на етикет не ви казва дали дадено внедряване трябва да включи защитата.

Отменете несъответствие, без да премахвате защитата

Изкушаващият тест е да изтриете tls-auth, да видите, че връзката успява, и да заключите, че ключът е бил грешен. Такъв отговор ви струва защитата и не ви учи на нищо за това коя от трите стойности е била несъответстваща. Вместо това вземете одобрената съответстваща конфигурация от страната на сървъра и сравнете с нея.

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

Накрая помнете какво означава успешна проверка. Тя доказва, че партньорът държи споделения ключ, а не че сертификатът или акаунтът му е оторизиран, и не казва нищо за договорения шифър на канала за данни. Оторизацията и защитата на данните се установяват по-късно, така че чистата проверка на плика е отправна точка, а не присъда.