OpenVPN tls-crypt-v2: какво правят ключът на клиента и обвитият blob

Поставянето на профил tls-crypt-v2 в тикет изглежда безобидно, докато не преброите какво съдържа файлът. Ключът за контролния канал на клиента стои до криптирано копие на същия ключ, а трети обект — ключът за обвиване — никога не напуска приемащия сървър. Тези три отговарят на различни въпроси за съхранение, споделяне и оттегляне. Разделянето им решава повечето спорове за политика, преди да са започнали.

Какво всъщност съдържа профилът

Клиентската половина на tls-crypt-v2 е ключ плюс обвито копие от него. Клиентът използва обикновения ключ за защита на контролния канал и предава обвитото копие на сървъра при настройка, така че сървърът възстановява същия ключ, без да съхранява открито копие за всеки клиент. Ключът за обвиване прави това възстановяване възможно и принадлежи само на приемащата страна. Всичко по-долу следва от това къде живеят тези три обекта.

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

Защо обвитото копие не е цялата история

Профилът носи използваемия клиентски материал заедно с обвития му аналог, така че защитата на копието за сървъра не казва нищо за защитата на файла. 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 описва обектите и границата, която те чертаят, докато прилагането остава за оператора.