OpenVPN tls-crypt-v2: што прават клучот на клиентот и завитканиот blob
Профилот tls-crypt-v2 содржи контролен клуч на клиентот и завиткана копија што само серверот може да ја отвори. Чувајте го секој објект и секој чекор на повлекување одделно.
Вметнувањето на профил tls-crypt-v2 во тикет изгледа безопасно додека не изброите што содржи датотеката. Контролниот клуч на каналот на клиентот стои до шифрирана копија од истиот клуч, а третиот објект, клучот за завиткување, никогаш не го напушта серверот што прифаќа. Овие три одговараат на различни прашања за чување, споделување и повлекување. Нивното одвојување решава повеќето политички спорови пред да почнат.
Што всушност содржи профилот
Клиентската половина на tls-crypt-v2 е клуч плус завиткана копија од него. Клиентот го користи обичниот клуч за заштита на контролниот канал и за време на поставувањето ја предава завитканата копија на серверот, така што серверот го враќа истиот клуч без да чува копија во чист текст за секој клиент. Клучот за завиткување го овозможува тоа враќање и припаѓа само на страната што прифаќа. Сѐ подолу произлегува од тоа каде живеат тие три објекти.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Читајте ја табелата по чување, а не по име, и последиците сами се откриваат. Губењето на клучот за завиткување е скапиот настан, бидејќи ништо во профилот не може да го реконструира, а чесното враќање е повторно издавање на групата. Истечен профил е поевтин, но многу почест, бидејќи луѓето лепат профили во тикети верувајќи дека завитканата копија ја прави датотеката безбедна за споделување. Двата неуспеси бараат различни одговори, и тоа е причината објектите да се чуваат одделно.
Зошто завитканата копија не е целата приказна
Профилот го носи употребливиот клиентски материјал заедно со неговиот завиткан пар, па заштитата на копијата за серверот не кажува ништо за заштитата на датотеката. Blob е безбеден за пренос и небезбеден за објавување. Метаподатоците во него се видливи за секој што ќе го прими blob, вклучително и секој што подоцна ќе го прочита тикетот во кој бил вметнат.
Третирајте го профилот како акредитив, а не како пример за конфигурација. Истечената датотека му дава на својот носител работен клиентски идентитет додека серверот не престане да го прифаќа тој идентитет, а завиткувањето не прави ништо за тој прозорец. Издадете еден профил за секој клиент за да остане повлекувањето одлука за една датотека, и направете резервна копија од клучот за завиткување одделно од конфигурацијата на серверот што ја овозможува. Ниту една навика не поправа компромитиран профил, но двете одредуваат колку брзо ќе биде ограничен следниот.
Каде стои куката за верификација во ракувањето
Куката за верификација се извршува пред да се открие TLS стекот, а нејзината задача е да ги провери метаподатоците што се носат во завитканиот blob. Таа ги добива тие метаподатоци плус мала, документирана околина, и има помалку со што да работи од куката за автентикација. Претпоставката дека гледа кориснички имиња, состојба на сесија или променливи на приклучок е вообичаениот начин оваа кука да биде лошо напишана. Прочитајте го сопствениот дел од прирачникот на куката наместо да позајмувате очекувања од друга кука.
Нејзиниот излезен статус е одлуката: резултат различен од нула го одбива клиентот, а нултиот резултат дозволува ракувањето да продолжи. Затоа политиката мора да каже што се случува кога метаподатоците недостасуваат, не можат да се анализираат или се неочекувани. Прво напишете го патот на одбивање, потоа одлучете кои вредности се прифатливи.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shТие два реда се површината на политиката на серверот: едниот го именува клучот за завиткување, другиот ја именува програмата што го оценува секој клиент. Сѐ интересно живее во скриптата, која заслужува контрола на верзии и ист преглед како секое друго правило за пристап.
Сметката, сертификатот и контролниот клуч се повлекуваат одделно
Раното прифаќање на контролниот канал не е автентикација, бидејќи се случува пред проверката на TLS идентитетот и пред каква било авторизација на сметката. Оневозможувањето сметка, отповикувањето сертификат и одбивањето клиентски контролен клуч се три дејства со три механизми. Распоредот што извршува само едно од нив има празнина, а не политика. Усогласете ги трите намерно и запишете кој чекор кое овластување го применува.
Времето е втората разлика. Променетиот список за прифаќање се применува на нови ракувања, додека веќе воспоставените сесии продолжуваат да работат додека нешто не ги прекине. Броењето записи во новиот список како доказ дека старите сесии завршиле е начинот на кој отстранетиот клиент останува поврзан со часови.
Неусогласените овластувања оставаат две дупки што лесно се наоѓаат во практиката. Сметката може да биде оневозможена додека нејзиниот контролен клуч сѐ уште отвора ракување, а сертификатот може да биде отповикан додека политиката за метаподатоци сѐ уште го прифаќа истиот клиент. Двете се истата грешка на различни места, бидејќи операторот го сметал едниот список за целото овластување. Ставете ги трите списоци еден до друг при отстранувањето и грешката станува видлива.
Издавање и повлекување на профил
Издавањето е полесната половина: создадете клиентски клуч на страната што прифаќа, предадете го профилот на точно еден сопственик, држете го материјалот за завиткување ограничен и извршете ја истата програма за верификација на секој сервер што прифаќа. Евтиното прифаќање е својство на целата група, а не на најновиот домаќин. Втор сервер со постар или полабав скрипт тивко станува најслабиот пат во распоредот.
Повлекувањето бара три чекори во намерен редослед. Одбијте го клиентот во куката за верификација за да не успеат новите ракувања, отповикајте го неговиот сертификат ако се користи PKI и оневозможете ја сметката за подоцнежната авторизација да нема што да авторизира. Потоа прекинете ги сесиите што ги дозволуваше старото прифаќање, бидејќи тие нема да забележат ниту едно од трите. Вежбајте ја низата на клиент што можете да си дозволите да го скршите.
Метаподатоците во профилот се влез за таа политика, а не доказ дека контролата на пристап веќе постои. Документот за дизајн на OpenVPN 2.6 ги опишува објектите и границата што ја влечат, додека спроведувањето останува кај операторот.