TLS VPN mot IPsec: de fem feltene som er verdt å gjennomgå

Å rangere TLS VPN-er mot IPsec VPN-er etter protokollfamilie svarer på et spørsmål ingen stilte, og det viser vanligvis til en konstruksjon begge familiene sluttet å bruke for flere år siden. Det en gjennomgår faktisk kan vurdere, er den forhandlede beskyttelsen, peer-identiteten, klientmodellen og den eksponerte tjenesten. De fire tingene er synlige i en utrulling, og ingen av dem følger av produktetiketten. Be om fem felter, og samtalen blir konkret.

Fem felter, og etiketten er ikke ett av dem

Det første feltet er den støttede programvareutgivelsen, fordi en protokollbeskrivelse uten versjon er en brosjyre. Det andre er den forhandlede protokollversjonen, som avgjør hvilke konstruksjoner som i det hele tatt er tilgjengelige. Det tredje er beskyttelsessuiten, det fjerde er autentiseringsmetoden for både peer og bruker, og det femte er tilgangsomfanget produktet gir etter opptak.

En SSL VPN-etikett dekker minst tre forskjellige produkter: en full nettverksklient, en applikasjonsproxy og en eldre nettleserbasert portal. De eksponerer ulike tjenester og feiler ulikt, så etiketten kan ikke erstatte omfangsfeltet.

Hva autentisert kryptering faktisk endrer

TLS 1.3 krever autentisert kryptering, noe som fjerner den eldre MAC-then-encrypt-konstruksjonen fra protokollen i stedet for å gjøre den valgfri. IPsec ESP har hatt suiter for autentisert kryptering like lenge, med AES-GCM definert i sin egen RFC. I begge familier kommer garantien fra den forhandlede suiten og ikke fra familienavnet, og derfor begynner feltlisten med en versjon. En gjennomgår som ikke kan navngi suiten, har ingenting å vurdere.

Derfor er den historiske sammenligningen misvisende. En utrulling låst til en gammel TLS-versjon med en CBC-suite og en som kjører TLS 1.3 med en AEAD-suite, er ikke samme sikkerhetsstilling, selv om begge er TLS VPN-er. Den samme splittelsen finnes på IPsec-siden mellom en moderne ESP-suite og en eldre kombinasjon.

Les de forhandlede verdiene i stedet for konfigurasjonen du hadde tenkt. Kommandoene nedenfor viser hva et levende endepunkt og en levende tunnel faktisk ble 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 et funn og ikke en preferanse. Hvis tunnelen lister en suite du ikke forventet, er konfigurasjonen som betyr noe den partene valgte, ikke den i malen.

Peer-identitet er et eget spørsmål

Kryptering uten en verifisert peer beskytter trafikken mot observatører og gir den til den som svarte på tilkoblingen. Peer-autentisering spør hvilken identitet som forventes, hvilket tillitsmateriale som validerer den, og hvordan klienten oppfører seg når svaret ikke stemmer. En sertifikatkjede, en festet nøkkel og en forhåndsdelt hemmelighet er tre forskjellige svar med tre forskjellige driftskostnader.

Still så de samme spørsmålene om brukeren eller enheten. En gateway som autentiserer maskinen og slipper inn enhver bruker, eller omvendt, har en bestemt stilling som bør skrives ned i stedet for antas. Ressurstillatelser som brukes etter opptak, er del av samme felt, fordi autentisering ikke er autorisasjon.

Å bevare vertsnavn- og sertifikatkontroller betyr mer enn hvor kjent innloggingsvinduet er. En klient konfigurert til å ignorere verifisering har fjernet det eneste trinnet som skiller gatewayen din fra en overbevisende etterligning.

Grensen produktet eksponerer

En klientløs portal proxyer utvalgte applikasjonsoperasjoner gjennom gatewayen, slik at brukeren når et grensesnitt i stedet for et nettverk. En fulltunnelklient bærer det rutene og filterpolicyen velger ut, som er en mye større flate. Å sammenligne de to etter protokollstyrke overser forskjellen i hva en angriper kan nå gjennom dem. Den ene eksponerer et applikasjonsgrensesnitt, den andre et rutet nettverk, og de to krever ulike gjennomganger.

Spør hvilken tjeneste som eksponeres, hvilke operasjoner som er autorisert og hva gatewayen selv lytter på. Et administrasjonsgrensesnitt som kan nås fra samme adresse som brukerportalen, er et utrullingsfunn, og ingen protokollvalg kompenserer for det.

Omfang per applikasjon snevrer inn flaten ytterligere, og det endrer også feilatferden når tunnelen faller. Et design som forutsetter fulltunnelrekkevidde, vil bryte på måter et per-app-design ikke gjør, og støttebelastningen følger.

Bestem feilutfallet og livssyklusen

Hva som skjer når autentisering eller beskyttelse ikke er tilgjengelig, er en policybeslutning som hører hjemme i gjennomgangen. Et blokkert utfall og en uannonsert direkte tilbakefall har ulike konsekvenser, og forskjellen er usynlig i en funksjonsliste. Angi den tiltenkte atferden ved siden av ressursen den beskytter.

Ta med gatewayens patch- og støttelivssyklus, dens aktiverte eksterne funksjoner og oppdateringsveien for klienter. Et korrekt protokollvalg gjør ikke en dårlig utrullet tjeneste trygg, og de fleste hendelser ligger i det gapet snarere enn i suiten.

Skriv de fem feltene, feilpolicyen og livssykluseieren på én side. Den siden er en gjennomgang; en sammenligning av protokollfamilier er en mening.