TLS VPN kontra IPsec: de fem felter, der er værd at gennemgå

At rangere TLS VPN'er mod IPsec VPN'er efter protokolfamilie besvarer et spørgsmål, ingen stillede, og det henviser som regel til en konstruktion, som begge familier droppede for år tilbage. Det, en gennemgående person faktisk kan vurdere, er den forhandlede beskyttelse, peer-identiteten, klientmodellen og den eksponerede tjeneste. De fire ting er synlige i en udrulning, og ingen af dem følger af produktets etiket. Bed om fem felter, og samtalen bliver konkret.

Fem felter, og etiketten er ikke et af dem

Det første felt er den understøttede softwareudgivelse, fordi en protokolbeskrivelse uden version er en brochure. Det andet er den forhandlede protokolversion, som afgør, hvilke konstruktioner der overhovedet er tilgængelige. Det tredje er beskyttelsessuiten, det fjerde er godkendelsesmetoden for både peer og bruger, og det femte er det adgangsomfang, produktet giver efter optagelse.

Et SSL VPN-etiket dækker mindst tre forskellige produkter: en fuld netværksklient, en applikationsproxy og en gammel browserbaseret portal. De eksponerer forskellige tjenester og fejler forskelligt, så etiketten kan ikke erstatte omfangsfeltet.

Hvad godkendt kryptering faktisk ændrer

TLS 1.3 kræver godkendt kryptering, hvilket fjerner den ældre MAC-then-encrypt-konstruktion fra protokollen i stedet for at gøre den valgfri. IPsec ESP har haft suiter til godkendt kryptering lige så længe, med AES-GCM defineret i sin egen RFC. I begge familier kommer garantien fra den forhandlede suite og ikke fra familienavnet, og derfor begynder feltlisten med en version. En gennemgående person, der ikke kan navngive suiten, har intet at vurdere.

Derfor er den historiske sammenligning misvisende. En udrulning fastlåst til en gammel TLS-version med en CBC-suite og en, der kører TLS 1.3 med en AEAD-suite, er ikke samme sikkerhedsposition, selv om begge er TLS VPN'er. Den samme opsplitning findes på IPsec-siden mellem en moderne ESP-suite og en ældre kombination.

Læs de forhandlede værdier i stedet for den konfiguration, du havde tænkt dig. Kommandoerne nedenfor viser, hvad et kørende endepunkt og en kørende tunnel faktisk blev enige om.

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

Hvis endepunktet ikke vil forhandle TLS 1.3, er det en konstatering og ikke en præference. Hvis tunnelen viser en suite, du ikke forventede, er den konfiguration, der betyder noget, den parterne valgte, ikke den i skabelonen.

Peer-identitet er et separat spørgsmål

Kryptering uden en verificeret peer beskytter trafikken mod observatører og giver den til den, der svarede på forbindelsen. Peer-godkendelse spørger, hvilken identitet der forventes, hvilket tillidsmateriale der validerer den, og hvordan klienten opfører sig, når svaret ikke passer. En certifikatkæde, en fastgjort nøgle og en forud delt hemmelighed er tre forskellige svar med tre forskellige driftsomkostninger.

Stil så de samme spørgsmål om brugeren eller enheden. En gateway, der godkender maskinen og optager enhver bruger, eller omvendt, har en bestemt position, som bør skrives ned i stedet for antages. Ressourcetilladelser, der anvendes efter optagelse, hører til samme felt, fordi godkendelse ikke er autorisation.

At bevare værtsnavn- og certifikatkontroller betyder mere end loginvinduets velkendthed. En klient, der er konfigureret til at ignorere verifikation, har fjernet det eneste trin, der skelner din gateway fra en overbevisende efterligning.

Den grænse, produktet eksponerer

En klientløs portal proxier udvalgte applikationshandlinger gennem gatewayen, så brugeren når en grænseflade i stedet for et netværk. En full-tunnel-klient bærer, hvad dens ruter og filtreringspolitik udvælger, hvilket er en meget større flade. At sammenligne de to efter protokolstyrke overser forskellen i, hvad en angriber kan nå gennem dem. Den ene eksponerer en applikationsgrænseflade, den anden et routet netværk, og de to kræver forskellige gennemgange.

Spørg, hvilken tjeneste der er eksponeret, hvilke handlinger der er autoriserede, og hvad gatewayen selv lytter på. En administrationsgrænseflade, der kan nås fra samme adresse som brugerportalen, er en udrulningskonstatering, og intet protokolvalg opvejer det.

Omfang per applikation indsnævrer fladen yderligere, og det ændrer også fejladfærden, når tunnelen falder. Et design, der forudsætter full-tunnel-rækkevidde, vil bryde på måder, et per-app-design ikke gør, og supportbelastningen følger.

Beslut fejludgangen og livscyklussen

Hvad der sker, når godkendelse eller beskyttelse ikke er tilgængelig, er en politisk beslutning, der hører i gennemgangen. En blokeret udgang og et uannonceret direkte fald tilbage har forskellige konsekvenser, og forskellen er usynlig i en funktionsliste. Angiv den tilsigtede adfærd ved siden af den ressource, den beskytter.

Medtag gatewayens patch- og supportlivscyklus, dens aktiverede eksterne funktioner og opdateringsvejen for klienter. Et korrekt protokolvalg gør ikke en dårligt udrullet tjeneste sikker, og de fleste hændelser ligger i det hul snarere end i suiten.

Skriv de fem felter, fejlpolitikken og livscyklusejeren på én side. Den side er en gennemgang; en sammenligning af protokolfamilier er en mening.