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 сепак може да користи шифра што не сте ја имале намера.

На крајот, самиот заеднички клуч бара постапување. Третирајте го како тајна, распределете го преку одобрена нишка и заменете го кога ќе замине секој што го имал. Бидејќи е заеднички, неговото откривање е откривање на секој крај што го користи.