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