Зашто 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 референца документује облике генерисања и одељке о кључном материјалу, што је бољи извор од копиране наредбе са форумске објаве.