OpenVPN tls-ciphersuites versus tls-version-min: co které vynucuje

Tři různé skutečnosti se ve většině diskusí o OpenVPN a TLS slijí do jednoho řádku: co umí vaše klientská sestava, co dovoluje profil a co si relace skutečně vyjednala. Krátký seznam sad TLS 1.3 odpovídá jen napůl na prostřední otázku a o spodní hranici verze protokolu neříká nic. Projděte níže uvedené kontroly popořadě a zastavte se u první, která neobstojí, protože každá další předpokládá, že předchozí jsou vyřešené.

Zkontrolujte sestavu, než začnete číst jakýkoli seznam

Konfigurační direktiva nemůže binárce přidat podporu protokolu, kterou nemá. Začněte verzním bannerem, který uvádí zkompilovanou kryptografickou knihovnu:

openvpn --version

Sestava 2.6 slinkovaná s OpenSSL přijímá jak tls-cipher, tak tls-ciphersuites. Sestava s mbed TLS nemá vůbec žádný výběr sad TLS 1.3 a manuál 2.6 označuje tls-ciphersuites jako volbu OpenSSL. Pokud je server přebudován s jiným backendem, stejný profil může změnit chování, aniž by se změnil jediný řádek konfigurace.

Dokud jste tady, spusťte openvpn --show-tls a výstup si uložte. Je to inventář, se kterým budete později porovnávat, a zachytit ho předtím, než někdo začne upravovat profily, je levné.

Zapište banner i seznam do tiketu změny, ne do chatovacího okna. Když se dva lidé přou, zda klient bude za šest týdnů moci nabídnout sadu, zachycený výstup to vyřeší jedním řádkem.

Držte mezní verze odděleně od seznamů šifer

V manuálu 2.6 to jsou tři ovládací prvky, ne jeden:

• tls-cipher nastavuje politiku šifer pro TLS 1.2 a starší a předává se seznamu šifer OpenSSL;
• tls-ciphersuites vybírá sady TLS 1.3;
• tls-version-min a tls-version-max omezují verze protokolu, které smí spojení použít.

Pečlivě ořezaný seznam sad TLS 1.3 tedy nic nedokazuje o tom, že starší verze je stále povolena. Pokud je požadavkem „pouze TLS 1.3“, nese ho spodní hranice verze a seznam sad jen zužuje volby uvnitř této hranice:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Tato dvojice dělá dvě věci. Smazání jednoho z řádků nechá druhý vynucovat méně, než si myslíte, a to je právě selhání, kvůli jehož zachycení celá tato kontrola existuje.

Datový kanál je čtvrtý ovládací prvek. data-ciphers vyjednává symetrickou šifru uvnitř tunelu a jeho výsledek neříká nic o verzi TLS řídicího kanálu. Vidět v souhrnu relace AES-256-GCM není důkaz o TLS 1.3 ani v jednom směru.

Čtěte show-tls jako místní inventář

--show-tls vypisuje sady podporované kryptografickou knihovnou, se kterou je tato binárka slinkovaná, v pořadí preferencí. Není to zpráva z brány. Manuál výslovně říká, že seznam pochází z místní knihovny, což znamená, že notebook s OpenSSL 3.x a router se starší sestavou vypíšou různé seznamy, i když mluví se stejným serverem.

Předpokládejte, že klient podporuje sady A, B a C a jedna relace zvolí B. To nic neříká o tom, zda server povoluje A nebo C, ani o tom, zda B je jeho jediná povolená volba. Držte tři řádky odděleně a většina matoucích vláken o TLS se vyřeší sama.

Inventář se přesto vyplatí uchovat. Když relace selže, porovnání seznamu knihovny se seznamem profilu ukáže, zda klient měl vůbec šanci nabídnout to, co server chtěl. Ukáže také, zda změna backendu potichu neodstranila TLS_CHACHA20_POLY1305_SHA256 z fondu, na který se starší klienti spoléhají — druh regrese, který se projeví jako hrstka uživatelů, jimž se nedaří připojit, zatímco ostatní nic nezaznamenají.

Ptejte se brány na něco, co umí zodpovědět

Pokud službu spravujete, prohlédněte si efektivní konfiguraci běžící instance, ne soubor na disku. OpenVPN mohl být spuštěn s jinou cestou --config, může načítat vkládané soubory a nemusel být od úpravy restartován. Politikou, se kterou se klienti setkávají, je politika běžícího démona.

Pokud ji nespravujete, požádejte operátora o podporované požadavky na klienty nebo o vymezený akceptační test. Odmítnutý pokus není automaticky odmítnutá sada: spodní hranice verze, kontroly identity certifikátu jako remote-cert-tls nebo nesoulad mezi tls-auth a tls-crypt mohou ukončit výměnu dřív, než výběr sady vůbec začne hrát roli. Přečtěte si chybu serveru, než změníte seznam klienta, protože „handshake failed“ pokrývá čtyři různé příčiny a jen jedna z nich je nesoulad šifry.

Nasměrování openssl s_client na port VPN také otázku nezopakuje. Řídicí kanál běží uvnitř vlastního rámování OpenVPN, takže surová TLS sonda testuje jiný protokol na portu, který očekává něco jiného. Jakýkoli závěr z ní je o sondě, ne o tunelu.

Zaznamenejte dva výsledky a držte je odděleně

Čerstvá povolená relace vytvoří řádek řídicího kanálu s verzí protokolu a zvolenou šifrou a samostatný řádek datového kanálu s šifrou tunelu. Zachyťte oba s verzí klienta a názvem profilu a poznamenejte, která instance serveru odpověděla:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Potom oba řádky čtěte z toho souboru, ne z paměti. Dvojice je důkaz; samotný název sady je preference a mez verze je samostatné tvrzení o tom, co server odmítá.

Proveďte kontroly v tomto pořadí. Potvrďte sestavu a backend pomocí --version. Zachyťte --show-tls, než cokoli změníte. Uveďte požadovanou spodní hranici verze odděleně od seznamu sad. Potvrďte efektivní politiku běžící instance s jejím vlastníkem. Sledujte jednu povolenou relaci a, pokud to plán dovoluje, jeden odmítnutý pokus se starší verzí. Zaznamenejte výsledky řídicího a datového kanálu jako samostatná zjištění.

Pokud požadovaný klient nedokáže splnit nové minimum, udělejte to rozhodnutí o migraci nebo výjimce výslovně, místo abyste potichu snižovali nesouvisející pravidlo přijetí, aby nasazení vypadalo hotové.