Proč openssl rand nedokáže vytvořit klíč, který tls-crypt chce

OpenSSL je už nainstalovaný, host má entropii a generovat s ním klíč vypadá jako zjevná zkratka. Výstup bude náhodný a tajný a úplně nepoužitelný a selhání přijde jako chyba řídicího kanálu, ne jako něco, co zmiňuje formát klíče. Právě toto zavádění je ta drahá část, protože posílá lidi zkoumat jejich šifry. To, co VPN čte, je určitá struktura souboru, ne libovolný blok bajtů, a jednu variantu této funkce vůbec nelze vyrobit mimo server.

Čím soubor na disku skutečně musí být

Soubor statického klíče OpenVPN je text. Začíná komentářovým řádkem, který prohlašuje, co je, nese hexadecimální data v řádcích pevné šířky a celkem obsahuje 256 bajtů klíčového materiálu. OpenVPN ho čte jako sdílené tajemství řídicího kanálu, ne jako certifikát, ne jako přístupovou frázi a ne jako něco, co by rozpoznala knihovna TLS.

Stejný typ objektu slouží oběma funkcím řídicího kanálu. U tls-auth potřebuje každý peer také směr, aby pakety jedné strany nemohly být odraženy zpět na ni. U tls-crypt jedno sdílené tajemství šifruje a autentizuje řídicí kanál v obou směrech, což handshake skrývá a zároveň chrání.

Nic z toho není tajná znalost a formát není pointa. Pointa je, že soubor musí přesně odpovídat tomu, co čtenář očekává: hlavička, šířka řádku, závěrečný konec řádku a celková délka. Soubor, který je o jeden řádek vedle, se načte jako smetí nebo úplně selže. Porovnat dva peery bajt po bajtu je proto legitimní první test a je rychlejší než čtení kteréhokoli ze dvou konfiguračních souborů.

Podporovaný způsob, jak jeden vytvořit

Vygenerujte prostý statický klíč nástrojem, který ho bude spotřebovávat, a pak na něj odkažte z obou konců:

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

Pravopis volby se v čase měnil: starší instalace z éry 2.4 používaly formu se samostatným příznakem před názvem souboru, zatímco současné buildy přijímají kratší. V každém případě je výsledný soubor stejný typ objektu, takže kontrolou je, zda oba peery drží identické bajty.

Druhá generace přidává strukturu, kterou žádný externí generátor nedokáže vymyslet. Klíč serveru se vytvoří jednou a každý klient dostane zabalený klíč odvozený z něj:

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

To, co klient dostane, není duplikovaný vlastní klíč serveru. Je to zabalený objekt nesoucí metadata, která dokáže rozbalit jen server, a právě to zabalení je důvod, proč lze soubor pro jedno zařízení odvolat, aniž by se dotkl jakéhokoli jiného zařízení. Uchovávejte klíč serveru na serveru a berte ho jako kořen této důvěry pro jednotlivá zařízení.

Kde se ručně vyrobené bajty hroutí

Vytisknout 256 náhodných bajtů jako hex pod správnou hlavičkou by teoreticky dalo soubor statického klíče, který se načte. Pořád je to špatný nápad. Každý detail formátování se stává příležitostí vyrobit materiál, který při načtení selže, nebo, hůř, nechá dva peery s rozdílnými hodnotami, které se projeví až jako selhání autentizace.

S variantou v2 není nic ekvivalentního možné. Zabalený klientský klíč existuje jen jako výstup procesu klíče serveru a server si ponechává materiál potřebný k jeho rozbalení. Náhodný blok bude odmítnut nebo prostě selže při dešifrování a ani jedna ze zpráv nezmíní náhodnost.

Kompatibilita verzí stojí na tom všem. První generace potřebuje vydání, které ji podporuje na obou koncích, a druhá zase potřebuje novější vydání. Klient sestavený před existencí funkce nemůže dokončit handshake se serverem, který přijímá jen zabalený materiál, a selhání, které hlásí, ukazuje na řídicí kanál, ne na verzi.

Rotace bez zamčení všech ven

Rotace jednoho sdíleného tajemství je cvičení v koordinaci, ne technické. Každý klient potřebuje náhradní soubor v ruce dřív, než server stáhne předchozí, a každý stroj, který ještě drží starou hodnotu, selže v okamžiku, kdy se to stane. Nezačínejte tuto rotaci uprostřed pracovního dne.

S uspořádáním v2 je rotace po zařízeních: vydejte nový zabalený klíč pro jeden stroj a vyřaďte starý jen pro ten stroj. To je hlavní argument pro přechod, jakmile je každý klient na vydání, které to podporuje.

Oprávnění souborů patří do stejné konverzace. Klíč by měl být čitelný jen pro účet, který spouští službu, a neměl by žít ve stejném repozitáři jako profily, které chrání. Referenční příručka OpenVPN 2.6 dokumentuje formy generování a sekce o klíčovém materiálu, což je lepší zdroj než zkopírovaný příkaz z příspěvku na fóru.