Co korporátní firewall ve VPN vidí a co ne

Stejný notebook se z domova k VPN připojí a z kanceláře ne, takže někdo ten provoz čte. Blokování a čtení jsou oddělené pravomoci a jen ta druhá potřebuje místo na cestě plus certifikát, kterému klient věří. Prostředník, který zahodí váš handshake, se nedozvěděl nic o tom, co byste poslali. Rozhodnout, se kterou z těch dvou věcí se potýkáte, je celá práce.

Blokování a čtení jsou různé pravomoci

Odmítnutí je levné a hlasité: socket se otevře a nic neodpovídá, nebo hned dorazí reset. Nic z toho neznamená inspekci, protože po drátě nepřešla žádná data.

Čtení vyžaduje koncový bod, který ochranu ukončí, prokáže se certifikátem a zahájí nové spojení dál. Ten bod musí stát na cestě a klient mu musí věřit. Firewall, který jen přeposílá pakety, nemá ani pozici, ani pověření.

Co obal prozradí zdarma

Každý paket tunelu má vnější stranu a ta musí být směrovatelná. To znamená dvě adresy, protokol, port a délku, k tomu časování a objem. Každý router už tato pole zpracovává a NAT přepisuje adresu a port, aby jeho mapovací tabulka zůstala konzistentní. Data zůstávají zapečetěná, takže pozorování končí u faktu, že mezi dvěma hostiteli existuje tunel.

Jméno hostitele mezi nimi není. Weby prosakují jinými dveřmi a nejširší je DNS: pokud se notebook stále ptá místního resolveru, jména se objevují v otevřené podobě.

Časování a objem si zaslouží respekt, ale bez přehánění. Bajtů za minutu mohou ukázat, že velký přenos začal ve 14:20; nemohou ukázat, který soubor odešel. To je skutečné prozrazení chování a jiná kategorie než čtení obsahu.

Intercepce TLS potřebuje kořen, kterému už věříte

Inspekční zařízení TLS neláme; ukončuje ho. Klientovi odpovídá certifikát z kořene, který organizace vlastní, a druhé spojení jde k pravému cíli. Klient to přijímá, protože ten kořen je v jeho úložišti důvěry, a proto spravovaný notebook nezobrazí žádné varování. Kryptografie nebyla nikdy poražena; koncový bod se přesunul.

Proto po sobě to uspořádání nechává důkazy. Vydavatel na předloženém řetězu patří organizaci, ne veřejné CA, a klient to vidí bez zvláštních nástrojů. Řetěz končící v interním kořeni je podpis intercepce, ne porucha.

Proč VPN kanál není relace HTTPS

Datový kanál VPN nedává inspektorovi takovou oporu. IKEv2 a WireGuard vedou vlastní handshaky a plány klíčů, bez TLS k ukončení, zatímco OpenVPN si TLS vypůjčuje pro svůj řídicí kanál v upravené podobě, než data ochrání po svém. Proxy postavená pro HTTPS tu relaci nepozná jako něco, co by mohla parsovat.

Zařízení, které relaci nedokáže parsovat, ji přesto umí zahodit. Proto blokování VPN obvykle vypadá jako časový limit, a ne jako varování o certifikátu, a proto výjimka nic nezmění.

Ověření z vlastního počítače

Začněte řetězem, který web předkládá. Podrobnosti o webu v prohlížeči ukazují vydavatele a příkazový řádek hlásí totéž bez shrnutí:

openssl s_client -connect example.com:443 -servername example.com

Pak oddělte odmítnutý handshake od filtrovaného vnitřního provozu pomocí čítačů. Zalogujte transportní port před každým pravidlem pro zahazování a po pokusu je přečtěte:

iptables -I OUTPUT 1 -p udp --dport 1194 -j LOG --log-prefix ovpn-out
iptables -vnL OUTPUT --line-numbers

Žádný řádek v logu na vnějším socketu znamená, že handshake vůbec neodešel, takže cesta tunel odmítá. Dokončený handshake, kdy selhávají jen některé cíle, znamená, že tunel funguje a vnitřní politika ne. Ani jeden z výsledků nevyžadoval přečíst bajt dat.

Čtení, které opravdu probíhá, sedí na okrajích: rozdělený tunel předává vnitřní HTTPS korporátní proxy a koncentrátor ve vlastnictví zaměstnavatele odhaluje na výstupu vše. Ať najdete cokoli, nevypínejte ověřování certifikátů, abyste si vynutili spojení, protože tahle kontrola je jediná věc, která odděluje inspekci od útočníka.