Защо openssl rand не може да създаде ключа, който tls-crypt иска

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

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

Файлът със статичен ключ на OpenVPN е текст. Започва с коментарен ред, който обявява какво е, носи шестнадесетични данни в редове с фиксирана ширина и наброява общо 256 байта ключов материал. OpenVPN го чете като споделената тайна на контролния канал, не като сертификат, не като парола и не като нещо, което TLS библиотека би разпознала.

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

Нищо от това не е тайно знание и форматът не е въпросът. Въпросът е, че файлът трябва да съвпада точно с това, което читателят очаква: заглавка, ширина на реда, завършващ нов ред и обща дължина. Файл, който е с един ред встрани, се зарежда като боклук или се проваля напълно. Затова сравняването на два партньора байт по байт е законен първи тест и е по-бързо от четенето на който и да е от двата конфигурационни файла.

Поддържаният начин да се направи един

Генерирайте обикновения статичен ключ с инструмента, който ще го използва, и след това се обърнете към него от двата края:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Изписването на опцията се промени с времето: по-старите инсталации от ерата на 2.4 използваха форма с отделен флаг преди името на файла, докато текущите компилации приемат по-кратката. Както и да е, полученият файл е същият тип обект, така че проверката е дали двамата партньори държат идентични байтове.

Второто поколение добавя структура, която никой външен генератор не може да измисли. Сървърен ключ се създава веднъж и всеки клиент получава обвит ключ, извлечен от него:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

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

Къде се провалят ръчно направените байтове

Отпечатването на 256 случайни байта като шестнадесетични под правилна заглавка теоретично би дало файл със статичен ключ, който се зарежда. Все пак е лоша идея. Всеки детайл на форматирането става шанс да се произведе материал, който се проваля при зареждане или, по-лошо, оставя двама партньори с различни стойности, които се разкриват само като неуспех при удостоверяване.

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

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

Ротация, без да заключим всички навън

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

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

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