Следење на контролните пакети на 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 исто така ја шифрира и го крие ракувањето од набљудувачи, и го заменува разделувањето на насоките со сопствено ракување со клучеви. Профилот со едното нема да работи со партнер конфигуриран за другото и никакво дотерување на digest-от не ја затвора таа празнина.

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

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

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

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

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

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

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

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