SSTP és SSL 3.0: a címke szemben az egyeztetett verzióval

Két ember ugyanazt az SSTP-telepítést nézheti, és ellentétes következtetésre juthat. Az egyik elolvassa a termék dokumentációját, meglátja az SSL betűket, és feltételezi, hogy az alagút egy évekkel ezelőtt kivezetett protokollt futtat. A másik egy modern kézfogásra mutat, és lezártnak tekinti a kérdést. Mindketten címkék alapján érvelnek, nem az egyeztetett verzió alapján, és ezek közül csak az egyik bizonyíték. Az összehasonlítás, amit érdemes megtenni, a név ígérete és a szolgáltatás tényleges választása között van.

Két válasz ugyanarra a kérdésre

A címkeérv könnyen megfogalmazható: az SSTP-t biztonságos socket-alagút protokollként írják le, a történelmi név SSL-t mond, tehát a kapcsolatnak SSL 3.0-nak kell lennie. Azért marad fenn, mert a név valóban ebből a vonulatból származik, és mert a legtöbben, akik ismétlik, sosem néztek meg egy kézfogást. Azért is fennmarad, mert a következtetés óvatosnak hangzik, mintha a legrosszabbat feltételezni lenne a biztonságos választás. A legrosszabbat feltételezni és a tényleges verziót mérni két különböző tevékenység, és csak az egyik változtat valamin.

A bizonyítékérv szűkebb kérdést tesz fel. Melyik protokollverzióban egyezett meg ez a kliens és ez a szerver, ezen a végponton, ebben az időpontban? A válasz attól a szolgáltatástól jön, amely lezárja a TLS-t, nem egy marketingoldaltól és nem egy böngészőtől, amely egy hasonló nevű webhelyre jutott.

A két érv abban különbözik, mit tud bizonyítani. A címke nem tud különbséget tenni régi és javított telepítés között, a kézfogás pedig nem mondja meg, mit tesz egy független szolgáltatás ugyanazon a gazdagépen. Használja a másodikat, és hagyja abba az elsőt.

Olvassa ki a verziót, amelyet a szolgáltatás valóban kiválaszt

Kezdje a komponensek megnevezésével: a kliens implementációja, a szerver implementációja, a TLS-végpont és minden köztes elem, amely lezárja és újra felépíti a TLS-t. Egy terheléselosztó, amely lezárja a TLS-t és sima HTTP-t beszél a backenddel, megváltoztatja, hogy melyik eszköz házirendjét kell olvasnia.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Jegyezze fel a végpontot és az időt az eredmény mellé, mert egy későbbi házirend-módosítás használhatatlanná tesz egy dátum nélküli megfigyelést. Ismételje meg a vizsgálatot olyan kliensről, amely ugyanazon a hálózati útvonalon van, mint az Ön számára fontos felhasználók, mert egy elfogó eszköz saját beállításaival lezárhatja a TLS-t. Ha a két álláspont eltér, megtalálta az érintett komponenst. Ha megegyezik, bizonyítéka van szlogen helyett.

Válassza szét a rekordmezőt az egyeztetéstől

Egy régiesnek tűnő verziószám az egyik mezőben nem ugyanaz a tény, mint egy SSL 3.0-s munkamenet. RFC 7568 a rekordréteg verzióját és az egyeztetett protokollt külön kérdésként kezeli, és pontosan ebből a megkülönböztetésből származnak a magabiztos téves válaszok. Olvassa ki az egyeztetett protokollt, aztán a titkosítást, és csak ezután vonjon le következtetést a munkamenetről.

Ugyanaz a dokumentum egyértelmű magáról a protokollról: SSL 3.0 nem használható, az egyeztetés vagy a visszaesés rá tilos. Az ok a hibás CBC-konstrukció, amelyet a POODLE-támadás kihasznált, és ez a protokoll tulajdonsága, nem egyetlen alkalmazás konfigurációja.

Ezért „ezt a terhelést valószínűleg nehéz kihasználni” nem érv az SSL 3.0 bekapcsolva tartása mellett. A követelmény a protokoll eltávolítása, nem egy bemutatóról szóló vita megnyerése.

Vonja ki az SSL 3.0-t olyan házirenddel, amelyet vállalni tud

Windowson a Schannel protokollbeállításai a Protocols kulcs alatt találhatók, és kliens- és szerver-szerepkörönként külön olvassák őket, ezért egy irányt javító módosítás érintetlenül hagyhatja a másikat. Az aktuális beállításokat és újraindítási követelményeiket a Microsoft dokumentálja, és egy harmadik féltől származó TLS-könyvtár ugyanazon a gazdagépen teljesen figyelmen kívül hagyja őket.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Módosítsa a házirendet a támogatott felügyeleti úton, erősítse meg, hogy a tulajdonos szolgáltatás újra beolvassa a konfigurációt, és tartson meg egy jóváhagyott visszautat. Egy másik környezetből bemásolt széles hatókörű beállításjegyzék-szkript az, ahogy egyetlen szolgáltatás javításából a gép összes TLS-kliense számára kiesés lesz. Az újraindítás hatóköre itt számít: egy alkalmazottnak tűnő beállítást még tarthat a memóriájában egy szolgáltatás, amely nem töltötte be újra.

Egy partnernek, amely még elavult verziót követel, frissítésre vagy migrációs tervre van szüksége. Egy nem dokumentált kivétel, amely csendben visszaállítja a régi protokollt, nem kompatibilitási stratégia, és nem éli túl a következő auditot.

Fogadja el a módosítást friss kapcsolatokkal

A házirend módosítása után új munkamenetekkel teszteljen, mert a módosítás előtt létrejött kapcsolat semmit sem bizonyít a most érvényben lévő konfigurációról. Erősítse meg, hogy az engedélyezett protokoll sikerül, a tiltott pedig elbukik az engedélyezett ellenőrzési folyamatban, majd hagyja a tanúsítvány identitását és a megbízhatósági ellenőrzéseket pontosan úgy, ahogy voltak.

Ne feledje, mire nem terjed ki a kézfogás. Az SSTP a TLS-réteg után PPP-hitelesítést szállít, így egy modern protokollverzió semmit sem mond arról, melyik felhasználót engedélyezték, vagy milyen erőforrásokat érhet el a munkamenet. Ezek külön vezérlők, külön bizonyítékokkal.

Írja le az eredményt szolgáltatásként, backendként, engedélyezett házirendként és megfigyelt verzióként. Ez a feljegyzés pontosan megválaszolja a biztonsági kérdést, amit sem a címkeérv, sem a kényelmetlenségre hivatkozó érv nem tesz meg.