Čo firemný firewall vo VPN vidí a čo nie

Ten istý notebook sa z domu k VPN pripojí a z kancelárie nie, takže niekto ten tok číta. Blokovanie a čítanie sú oddelené právomoci a len tá druhá potrebuje miesto na ceste plus certifikát, ktorému klient dôveruje. Prostredník, ktorý zahodí váš handshake, sa nedozvedel nič o tom, čo by ste poslali. Rozhodnúť, s ktorou z tých dvoch vecí sa stretávate, je celá práca.

Blokovanie a čítanie sú rôzne právomoci

Odmietnutie je lacné a hlasné: socket sa otvorí a nič neodpovedá, alebo hneď dorazí reset. Nič z toho neznamená inšpekciu, pretože po drôte neprešla žiadna záťaž.

Čítanie vyžaduje koncový bod, ktorý ukončí ochranu, preukáže sa certifikátom a začne nové spojenie ďalej. Ten bod musí stáť na ceste a klient mu musí dôverovať. Firewall, ktorý iba preposiela pakety, nemá ani pozíciu, ani poverenie.

Čo obal prezradí zadarmo

Každý paket tunela má vonkajšiu stranu a tá musí byť smerovateľná. To znamená dve adresy, protokol, port a dĺžku, k tomu časovanie a objem. Každý router už tieto polia spracúva a NAT prepisuje adresu a port, aby jeho mapovacia tabuľka zostala konzistentná. Záťaž zostáva zapečatená, takže pozorovanie sa končí pri fakte, že medzi dvoma hostiteľmi existuje tunel.

Meno hostiteľa medzi nimi nie je. Weby presakujú inými dverami a najširšie je DNS: ak sa notebook stále pýta miestneho resolvera, mená sa objavujú otvorene.

Časovanie a objem si zaslúžia rešpekt bez preháňania. Bajtov za minútu môžu ukázať, že veľký prenos začína o 14:20; nemôžu ukázať, ktorý súbor sa pohol. To je skutočné prezradenie správania a iná kategória než čítanie obsahu.

Inšpekcia TLS potrebuje koreň, ktorému už dôverujete

Inšpekčné zariadenie TLS neláme; ukončuje ho. Klientovi odpovedá certifikát z koreňa, ktorý organizácia vlastní, a druhé spojenie ide k pravému cieľu. Klient to prijíma, pretože ten koreň je v jeho úložišti dôvery, a preto spravovaný notebook nezobrazí žiadne varovanie. Kryptografia nebola nikdy porazená; koncový bod sa presunul.

Preto po sebe toto usporiadanie necháva dôkazy. Vydavateľ na predloženom reťazi patrí organizácii, nie verejnej CA, a klient to vidí bez špeciálnych nástrojov. Reťaz končiaca v internom koreni je podpis inšpekcie, nie porucha.

Prečo kanál VPN nie je relácia HTTPS

Dátový kanál VPN nedáva inšpektorovi takú oporu. IKEv2 a WireGuard vedú vlastné handshaky a plány kľúčov, bez TLS na ukončenie, zatiaľ čo OpenVPN si požičiava TLS pre svoj riadiaci kanál v upravenej podobe, kým ochráni dáta po svojom. Proxy postavená pre HTTPS tú reláciu nepozná ako niečo, čo by mohla parsovať.

Zariadenie, ktoré reláciu nevie parsovať, ju však stále dokáže zahodiť. Preto blokovanie VPN zvyčajne vyzerá ako časový limit a nie ako varovanie o certifikáte, a preto výnimka nič nemení.

Overte to z vlastného počítača

Začnite reťazou, ktorú web predkladá. Podrobnosti o webe v prehliadači ukazujú vydavateľa a príkazový riadok hlási to isté bez zhrnutia:

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

Potom oddelte odmietnutý handshake od filtrovanej vnútornej prevádzky pomocou počítadiel. Zaznamenajte transportný port pred každým pravidlom zahadzovania a prečítajte ich po pokuse:

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

Žiadny riadok v logu na vonkajšom sockete znamená, že handshake vôbec neodišiel, takže cesta tunel odmieta. Dokončený handshake, pri ktorom zlyhávajú len niektoré ciele, znamená, že tunel funguje a vnútorná politika nie. Ani jeden z výsledkov nevyžadoval prečítať bajt záťaže.

Čítanie, ktoré naozaj prebieha, sedí na okrajoch: rozdelený tunel odovzdáva interný HTTPS firemnej proxy a koncentrátor vo vlastníctve zamestnávateľa odhaľuje na výstupe všetko. Čokoľvek nájdete, nevypínajte overovanie certifikátov, aby ste si vynútili spojenie, pretože tá kontrola je jediná vec, ktorá oddeľuje inšpekciu od útočníka.