Je neúspěšný handshake VPN opravdu downgrade útok?

Handshake, který skončí chybou, vypadá jako útok, dokud se nepodíváte na zprávu, a většinou jde o aritmetiku: žádná společná nabídka, certifikát po expiraci nebo paket, který nikdy nedorazil. Downgrade útok je konkrétní věc: protivník tlačí oba konce k slabšímu chování, než by si vybrali, a zanechává jiné důkazy. Když každý neúspěch považujete za zlý úmysl, hledáte oběť, která možná neexistuje, a když skutečný downgrade považujete za chybu konfigurace, slabší výsledek zůstane na místě. Ty dvě chyby stojí různě a jen jedna z nich se dá levně opravit.

Co downgrade útok vlastně mění

Cílem není prolomit šifru ani uhodnout klíč. Cílem je ovlivnit vyjednávání tak, aby se obě strany zastavily na starší verzi nebo slabším algoritmu, se kterým si útočník poradí, nebo aby jedna strana uvěřila, že druhá podporuje jen to.

Mění se dohoda, ne autentizace. Pokud útočník může změnit nabídku, aniž by byl odhalen, protistrany mohou stále dokončit handshake a stále se navzájem autentizovat, ale s parametry, které útočník preferuje. Proto je zajímavá otázka, zda je samotné vyjednávání pokryto ochranou integrity.

Proč musí být samotné vyjednávání autentizováno

TLS 1.3 tuto ochranu činí explicitní. Klient, který nabídl novější verzi, dokáže odhalit server, jenž tiše ustoupil, protože náhodná hodnota serveru nese pevný vzor, když vyjednává 1.2 nebo nižší, a klient musí při jejím spatření přerušit. Celý přepis je také pokryt závěrečnými zprávami, takže úprava kdekoli ve vyjednávání selže později, místo aby tiše prošla.

Starší verze protokolu měly slabší příběhy, a právě proto záleží na pravidlech návratu. Koncový bod s TLS 1.0 ve stejné konfiguraci není downgrade útok; je to povolený výsledek, který jste se rozhodli povolit. Rozdíl je v tom, zda slabší výsledek vzešel z chráněného rozhodnutí, nebo z nechráněné cesty, kterou mohl prostředník ovlivnit. Jakmile to takto formulujete, většina incidentů se změní na otázku konfigurace.

IKEv2 se chová jinak, ale stojí na stejné myšlence. Nabídka se přenáší ve výměně, která později autentizuje obě strany, takže mezilehlé zařízení, které přepisuje algoritmy, láme autentizaci, místo aby ji řídilo. Řídicí kanál OpenVPN chrání své vyjednávání pomocí TLS a pak tento kanál používá k dohodě šifer datového kanálu, a proto je zajímavý řádek z logu řídicího kanálu.

Nakonfigurovaná kompatibilita není útok

Správce může záměrně povolit starší volby na podporu dokumentovaného klienta a toto rozhodnutí je v konfiguraci vidět. Útočník takovou konfiguraci nevytvoří; může jen zneužít cestu, která mu umožní ovlivnit nabídku.

Nebezpečná oprava je ta, která odstraňuje důkaz rozdílu. Zapnutí všech starších voleb, vypnutí ověřování certifikátů nebo přijímání jakékoli šifry, aby chyba zmizela, rozšiřuje to, s čím koncový bod bude souhlasit, a odstraňuje kontroly, které by slabší výsledek nahlásily.

Pokud musíte jednu starou volbu zachovat, uveďte důvod a klienta v komentáři konfigurace a pak volbu omezte na profil, který ji potřebuje. Výjimka kompatibility omezená na jeden listener je auditovatelná; ta uplatněná globálně je jen slabší výchozí hodnota, o níž si nikdo nepamatuje, že ji zvolil.

Přečtěte si selhání, než pojmenujete příčinu

Před jakoukoli změnou uchovejte přesný řetězec chyby, verze klienta a serveru a čas. Pak klasifikujte: neshodly se strany na nabídce, selhala cesta paketů, nebo jedna strana odmítla parametr, který dřív přijímala?

Nesoulad nabídky obvykle pojmenuje problematické verze nebo algoritmy a selhává pokaždé ve stejném bodě. Problém se směrováním nebo MTU se zasekne nebo vyprší a často se mění podle sítě. Prošlý certifikát dává chybu ověření, ne vyjednávání.

Nic z toho není důkaz útočníka. Přisoudit zlý úmysl při prvním selhání je chyba, protože skrývá deterministickou chybu, která zítra selže znovu.

Potvrďte, co se skutečně vybralo

Po každé opravě si přečtěte vyjednaný výsledek, místo abyste věřili, že spojení naskočilo. Spojení, které uspěje proto, že bylo odstraněno ověřování, je výsledek, kterému jste se chtěli vyhnout. Následující dva příkazy ukazují zvolenou verzi a šifru pro koncový bod s TLS a také řádek řídicího kanálu z logu serveru OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Porovnejte výsledek s konfigurací, kterou jste zamýšleli, ne s tím, co se teď připojuje. Pokud je zvolená verze starší než povolené minimum, hledejte v profilu nebo v seznamu návratu a odpověď je opravit tento seznam, ne vyhlásit útok a přestavět vše kolem.