TLS VPN mot IPsec: dei fem felta som er verd å gå gjennom

Å rangere TLS VPN-ar mot IPsec VPN-ar etter protokollfamilie svarar på eit spørsmål ingen stilte, og det viser vanlegvis til ein konstruksjon begge familiane slutta å bruke for fleire år sidan. Det ein gjennomgåar faktisk kan vurdere, er den forhandla vernet, peer-identiteten, klientmodellen og den eksponerte tenesta. Dei fire tinga er synlege i ein utrulling, og ingen av dei følgjer av produktetiketten. Be om fem felt, og samtalen blir konkret.

Fem felt, og etiketten er ikkje eitt av dei

Det første feltet er den støtta programvareutgåva, fordi ein protokollskildring utan versjon er ein brosjyre. Det andre er den forhandla protokollversjonen, som avgjer kva konstruksjonar som i det heile er tilgjengelege. Det tredje er vernesuiten, det fjerde er autentiseringsmetoden for både peer og brukar, og det femte er tilgangsomfanget produktet gir etter opptak.

Ein SSL VPN-etikett dekkjer minst tre ulike produkt: ein full nettverksklient, ein applikasjonsproxy og ein eldre nettlesarbasert portal. Dei eksponerer ulike tenester og feilar ulikt, så etiketten kan ikkje erstatte omfangsfeltet.

Kva autentisert kryptering faktisk endrar

TLS 1.3 krev autentisert kryptering, noko som fjernar den eldre MAC-then-encrypt-konstruksjonen frå protokollen i staden for å gjere han valfri. IPsec ESP har hatt suitan for autentisert kryptering like lenge, med AES-GCM definert i sin eigen RFC. I begge familiane kjem garantien frå den forhandla suiten og ikkje frå familienamnet, og difor byrjar feltlista med ein versjon. Ein gjennomgåar som ikkje kan namngje suiten, har ingenting å vurdere.

Difor er den historiske samanlikninga misvisande. Ein utrulling låst til ein gammal TLS-versjon med ein CBC-suite og ein som køyrer TLS 1.3 med ein AEAD-suite, er ikkje same sikkerheitsstilling, sjølv om begge er TLS VPN-ar. Den same splittinga finst på IPsec-sida mellom ein moderne ESP-suite og ein eldre kombinasjon.

Les dei forhandla verdiane i staden for konfigurasjonen du hadde tenkt. Kommandoane nedanfor viser kva eit levande endepunkt og ein levande tunnel faktisk vart samde om.

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

Viss endepunktet ikkje vil forhandle TLS 1.3, er det eit funn og ikkje ei preferanse. Viss tunnelen listar ein suite du ikkje venta, er konfigurasjonen som betyr noko den partane valde, ikkje den i malen.

Peer-identitet er eit eige spørsmål

Kryptering utan ein verifisert peer vernar trafikken mot observatørar og gjev han til den som svara på tilkoplinga. Peer-autentisering spør kva identitet som vert venta, kva tillitsmateriale som validerer han, og korleis klienten oppfører seg når svaret ikkje stemmer. Ei sertifikatkjede, ein festa nøkkel og ein på førehand delt løyndom er tre ulike svar med tre ulike driftskostnader.

Still så dei same spørsmåla om brukaren eller eininga. Ein gateway som autentiserer maskinen og slepp inn kven som helst brukar, eller omvendt, har ei bestemd stilling som bør skrivast ned i staden for å bli anteken. Ressurstillatingar som vert brukte etter opptak, er del av same felt, fordi autentisering ikkje er autorisasjon.

Å bevare vertsnamn- og sertifikatkontrollar betyr meir enn kor kjent innloggingsvindauget er. Ein klient konfigurert til å ignorere verifisering har fjerna det einaste trinnet som skil gatewayen din frå ei overtydande etterlikning.

Grensa produktet eksponerer

Ein klientlaus portal proxyar utvalde applikasjonsoperasjonar gjennom gatewayen, slik at brukaren når eit grensesnitt i staden for eit nettverk. Ein fulltunnelklient ber det rutene og filterpolicyen vel ut, som er ei mykje større flate. Å samanlikne dei to etter protokollstyrke overser skilnaden i kva ein åtakar kan nå gjennom dei. Den eine eksponerer eit applikasjonsgrensesnitt, den andre eit ruta nettverk, og dei to krev ulike gjennomgangar.

Spør kva teneste som vert eksponert, kva operasjonar som er autoriserte og kva gatewayen sjølv lyttar på. Eit administrasjonsgrensesnitt som kan nåast frå same adresse som brukarportalen, er eit utrullingsfunn, og ingen protokollval kompenserer for det.

Omfang per applikasjon snevrar inn flata ytterlegare, og det endrar òg feilåtferda når tunnelen fell. Eit design som føreset fulltunnelrekkjevidde, vil bryte på måtar eit per-app-design ikkje gjer, og støttebelastninga følgjer.

Avgjer feilutfallet og livssyklusen

Kva som skjer når autentisering eller vern ikkje er tilgjengeleg, er ei policyavgjerd som høyrer heime i gjennomgangen. Eit blokkert utfall og ein uannonsert direkte tilbakefall har ulike konsekvensar, og skilnaden er usynleg i ei funksjonsliste. Angi den tiltenkte åtferda ved sida av ressursen han vernar.

Ta med gatewayen sin patch- og støttelivssyklus, dei aktiverte eksterne funksjonane hans og oppdateringsvegen for klientar. Eit korrekt protokollval gjer ikkje ei dårleg utrulla teneste trygg, og dei fleste hendingane ligg i det gapet snarare enn i suiten.

Skriv dei fem felta, feilpolicyen og livssykluseigaren på éi side. Den sida er ein gjennomgang; ei samanlikning av protokollfamiliar er ei meining.