Праћење OpenVPN контролних пакета: tls-auth пре TLS-а

Неуспех tls-auth обично се пријављује као проблем руковања, а никада није био. HMAC се проверава на контролном пакету пре било какве TLS обраде, па неусаглашен кључ или смер даје неуспех који изгледа као проблем сертификата и решава се два слоја раније. Третирање коверте као засебног објекта скраћује дијагнозу: прочитајте поља, потврдите да се провера активира рано, затим упоредите три ствари око којих обе стране морају да се сложе.

Читајте коверту редом којим се гради

Контролни пакет носи идентификатор сесије, опциони tls-auth HMAC, податке о понављању и потврди, и поуздан идентификатор поруке, а након тога следи садржај типа поруке. Када је порука порука руковања, садржај је 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 га и шифрује те скрива руковање од посматрача, и замењује поделу смерова сопственим руковањем кључевима. Профил који користи једно неће радити са партнером конфигурисаним за друго, и никакво подешавање digesta не затвара тај јаз.

Репродукујте ознаку само из стварног формата

Репродукција тачна до бајта одвојен је задатак од покретања VPN-а и ради само са стварним улазима: имплементацијом и верзијом које су изградиле пакет, одабраним digestom, смером и стварним бајтовима укључујући идентификатор сесије и низ потврда. Текстуални приказ листе поља нису ти бајтови.

Дужина ознаке следи из digesta, па претпоставка о фиксној дужини пада у тренутку када је неко промени. Хеширајте пакет како то чини имплементација, а не како га приказује табела у блог посту, и упоредите са снимком узетим од истог партнера, а не са очекивањем које сте извели ручно.

Држите ту вежбу даље од продукционих профила. Ништа у репродукцији ознаке не говори вам треба ли имплементација да укључи заштиту.

Вратите неслагање без уклањања заштите

Примамљив тест је избрисати tls-auth, видети да веза успева и закључити да је кључ био погрешан. Такав одговор кошта вас заштите и не учи ништа о томе која се од три вредности разликовала. Уместо тога узмите одобрену одговарајућу конфигурацију са серверске стране и упоредите са њом.

Припремите промену тако да буде реверзибилна. Сачувајте претходну конфигурацију сервера и датотеку кључа, примените исправљени пар, проверите да клијент заврши руковање и тек онда уклоните сигурносну копију. Ако клијенти не успеју након промене, вратите претходне датотеке уместо да импровизујете трећу варијанту током прекида. Враћање треба да буде једна команда коју већ знате пре него што почнете.

На крају, запамтите шта значи положена провера. Она доказује да партнер има заједнички кључ, а не да су његов сертификат или налог ауторизовани, и не говори ништа о договореној шифри канала података. Ауторизација и заштита података успостављају се касније, па је чиста провера коверте почетна тачка, а не пресуда.