Чаму 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 дакументуе формы стварэння і раздзелы ключавага матэрыялу, што з'яўляецца лепшай крыніцай, чым скапіяваная каманда з паведамлення на форуме.