tls-auth срещу tls-crypt: какво пази всяка от двете в OpenVPN

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

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

Какво всъщност пази общият ключ

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

tls-auth използва тази тайна, за да изчисли HMAC върху контролните пакети. Пакет без валиден подпис се изхвърля, преди да достигне по-скъпата обработка на TLS, поради което опцията често се описва като първи филтър, а не като замяна на TLS.

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

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

Къде двете опции се различават

Наблюдаемата разлика е какво вижда наблюдателят. С tls-auth ръкостискането е видимо, но не може да се провери без ключа. С tls-crypt ръкостискането е непрозрачно за всеки, който не притежава ключа.

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

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

По-нов вариант, tls-crypt-v2, обвързва всеки клиент със собствения му обвит ключ, така че отмяната на един клиент да не изисква преиздаване на груповия ключ. Заслужава да се знае, но е различна опция и не е синоним на нито една от двете тук.

Защо несъответствието изглежда като да не се случва нищо

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

Клиентът опитва отново, сървърът не казва нищо и симптомът изглежда като мрежов проблем. Тогава хората рестартират услугата, въвеждат отново паролата на акаунта или премахват директивата за защита, за да я «тестват», което променя разгръщането, вместо да го диагностицира.

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

Премахването на директивата не е безопасен ремонт. То изключва слой защита за всеки клиент и работещ тунел след това доказва само, че този слой е бил несъответствието.

Какво още трябва да се настрои отделно

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

Те също не избират шифъра за данни. Това е отделно договаряне, управлявано от настройките на канала за данни на двата възела, и тунел, защитен с tls-crypt, все още може да използва шифър, който не сте предвидили.

Накрая, самият общ ключ се нуждае от грижа. Отнасяйте се с него като с тайна, разпространявайте го по одобрен канал и го сменяйте, когато някой, който го е притежавал, напусне. Понеже е общ, излагането му е излагане на всяка крайна точка, която го използва.