TLS VPN versus IPsec: pět polí, která stojí za revizi

Zařazovat TLS VPN proti IPsec VPN podle rodiny protokolů odpovídá na otázku, kterou nikdo nepoložil, a obvykle cituje konstrukci, kterou obě rodiny opustily před lety. Co recenzent skutečně může posoudit, je vyjednaná ochrana, identita protějšku, model klienta a vystavená služba. Tyto čtyři věci jsou v nasazení viditelné a žádná z nich nevyplývá z etikety produktu. Požádejte o pět polí a rozhovor se stane konkrétním.

Pět polí a etiketa není jedno z nich

První pole je podporovaná verze softwaru, protože popis protokolu bez verze je brožura. Druhé je vyjednaná verze protokolu, která rozhoduje, jaké konstrukce jsou vůbec dostupné. Třetí je ochranná sada, čtvrté je metoda autentizace jak protějšku, tak uživatele, a páté je rozsah přístupu, který produkt po přijetí uděluje.

Etiketa SSL VPN pokrývá nejméně tři různé produkty: plného síťového klienta, proxy aplikací a starší portál založený na prohlížeči. Vystavují různé služby a selhávají různě, takže etiketa nemůže nahradit pole rozsahu.

Co autentizované šifrování skutečně mění

TLS 1.3 vyžaduje autentizované šifrování, což z protokolu odstraňuje starší konstrukci MAC-then-encrypt, místo aby ji nechalo volitelnou. IPsec ESP má sady autentizovaného šifrování stejně dlouho, s AES-GCM definovaným ve vlastním RFC. V obou rodinách záruka pochází z vyjednané sady, nikoli z názvu rodiny, a proto seznam polí začíná verzí. Recenzent, který nedokáže sadu pojmenovat, nemá co hodnotit.

Proto je historické srovnání zavádějící. Nasazení připnuté ke staré verzi TLS se sadou CBC a jiné, které provozuje TLS 1.3 se sadou AEAD, nemají stejný bezpečnostní postoj, i když obě jsou TLS VPN. Stejné rozdělení existuje na straně IPsec mezi moderní sadou ESP a starší kombinací.

Čtěte vyjednané hodnoty, ne konfiguraci, kterou jste zamýšleli. Příkazy níže ukazují, na čem se živý koncový bod a živý tunel skutečně dohodly.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Pokud koncový bod nechce vyjednávat TLS 1.3, je to zjištění, nikoli preference. Pokud tunel uvádí sadu, kterou jste nečekali, konfigurace, na které záleží, je ta, kterou zvolili protějšky, ne ta ze šablony.

Identita protějšku je samostatná otázka

Šifrování bez ověřeného protějšku chrání provoz před pozorovateli a předává ho tomu, kdo na spojení odpověděl. Autentizace protějšku se ptá, jaká identita se očekává, jaký důvěryhodný materiál ji ověřuje a jak se klient chová, když odpověď nesouhlasí. Řetěz certifikátů, připnutý klíč a předem sdílené tajemství jsou tři různé odpovědi se třemi různými provozními náklady.

Potom položte stejné otázky o uživateli nebo zařízení. Brána, která autentizuje stroj a pustí jakéhokoli uživatele, nebo naopak, má konkrétní postoj, který je třeba zapsat, ne předpokládat. Oprávnění k prostředkům uplatněná po přijetí jsou součástí stejného pole, protože autentizace není autorizace.

Zachování kontrol názvu hostitele a certifikátu je důležitější než známost přihlašovacího okna. Klient nakonfigurovaný tak, aby ověřování ignoroval, odstranil jediný krok, který odlišuje vaši bránu od přesvědčivé imitace.

Hranice, kterou produkt vystavuje

Bezklientový portál proxyuje vybrané operace aplikací přes bránu, takže uživatel dosáhne rozhraní, ne sítě. Klient plného tunelu nese to, co vyberou jeho trasy a politika filtrování, což je mnohem větší plocha. Srovnávat oba podle síly protokolu míjí rozdíl v tom, kam se útočník přes ně dostane. Jeden vystavuje rozhraní aplikace, druhý směrovanou síť, a oba vyžadují jiné revize.

Zeptejte se, která služba je vystavena, které operace jsou autorizované a na čem sama brána naslouchá. Administrační rozhraní dostupné ze stejné adresy jako uživatelský portál je zjištění nasazení a žádná volba protokolu to nevykompenzuje.

Rozsah na aplikaci dále zužuje plochu a mění i chování při selhání, když tunel spadne. Návrh předpokládající dosah plného tunelu se láme způsoby, které návrh pro jednotlivé aplikace nezná, a zátěž podpory následuje.

Rozhodněte výsledek selhání a životní cyklus

Co se stane, když autentizace nebo ochrana není dostupná, je rozhodnutí o politice, které patří do revize. Blokovaný výsledek a neoznámený přímý návrat mají různé důsledky a rozdíl je v seznamu funkcí neviditelný. Uveďte zamýšlené chování vedle prostředku, který chrání.

Zahrňte životní cyklus záplat a podpory brány, její povolené externí funkce a cestu aktualizace klientů. Správná volba protokolu neučiní bezpečnou špatně nasazenou službu a většina incidentů žije v této mezeře, ne v sadě.

Napište pět polí, politiku selhání a vlastníka životního cyklu na jednu stránku. Ta stránka je revize; srovnání rodin protokolů je názor.