TLS VPN teenoor IPsec: die vyf velde wat die moeite werd is om na te gaan
Vergelyk 'n TLS VPN en 'n IPsec VPN op grond van weergawe, protokolweergawe, suite, eweknie-identiteit en blootgestelde omvang, plus die foutuitkoms wat jy werklik gekonfigureer het.
Om TLS VPN's teen IPsec VPN's volgens protokolfamilie te rangskik, beantwoord 'n vraag wat niemand gevra het nie, en dit verwys gewoonlik na 'n konstruksie wat albei families jare gelede laat vaar het. Wat 'n keurder werklik kan beoordeel, is die onderhandelde beskerming, die eweknie-identiteit, die kliëntmodel en die blootgestelde diens. Daardie vier dinge is sigbaar in 'n ontplooiing, en nie een daarvan volg uit die produknaam nie. Vra vir vyf velde en die gesprek word konkreet.
Vyf velde, en die etiket is nie een van hulle nie
Die eerste veld is die ondersteunde sagtewareweergawe, want 'n protokolbeskrywing sonder 'n weergawe is 'n brosjure. Die tweede is die onderhandelde protokolweergawe, wat bepaal watter konstruksies hoegenaamd beskikbaar is. Die derde is die beskermingsuite, die vierde is die verifikasiemetode vir beide eweknie en gebruiker, en die vyfde is die toegangsomvang wat die produk ná toelating verleen.
'n SSL VPN-etiket dek ten minste drie verskillende produkte: 'n volledige netwerkkliënt, 'n programportaal en 'n ouerige blaaiergebaseerde portaal. Hulle stel verskillende dienste bloot en faal anders, so die etiket kan nie die omvangveld vervang nie.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Wat geauthentiseerde enkripsie werklik verander
TLS 1.3 vereis geauthentiseerde enkripsie, wat die ouer MAC-then-encrypt-konstruksie uit die protokol verwyder eerder as om dit opsioneel te laat. IPsec ESP het net so lank al geauthentiseerde-enkripsie-suites, met AES-GCM wat in sy eie RFC gedefinieer is. In albei families kom die waarborg uit die onderhandelde suite eerder as die familienaam, en daarom begin die veldlys met 'n weergawe. 'n Keurder wat nie die suite kan noem nie, het niks om te beoordeel nie.
Dit is waarom die historiese vergelyking misleidend is. 'n Ontplooiing wat aan 'n ou TLS-weergawe met 'n CBC-suite vasgepen is en een wat TLS 1.3 met 'n AEAD-suite gebruik, is nie dieselfde sekuriteitsposisie nie, al is albei TLS VPN's. Dieselfde skeiding bestaan aan die IPsec-kant tussen 'n moderne ESP-suite en 'n ouerige kombinasie.
Lees die onderhandelde waardes eerder as die konfigurasie wat jy bedoel het. Die opdragte hieronder wys waaroor 'n lewendige eindpunt en 'n lewendige tonnel werklik ooreengekom het.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasAs die eindpunt nie TLS 1.3 wil onderhandel nie, is dit 'n bevinding eerder as 'n voorkeur. As die tonnel 'n suite lys wat jy nie verwag het nie, is die konfigurasie wat saak maak die een wat die eweknieë gekies het, nie die een in die sjabloon nie.
Eweknie-identiteit is 'n afsonderlike vraag
Enkripsie sonder 'n geverifieerde eweknie beskerm die verkeer teen waarnemers en gee dit aan wie ook al die verbinding beantwoord het. Eweknie-verifikasie vra watter identiteit verwag word, watter vertrouensmateriaal dit valideer, en hoe die kliënt optree wanneer die antwoord nie ooreenstem nie. 'n Sertifikaatketting, 'n vasgepen sleutel en 'n vooraf gedeelde geheim is drie verskillende antwoorde met drie verskillende bedryfskoste.
Vra dan dieselfde vrae oor die gebruiker of toestel. 'n Poort wat die masjien verifieer en enige gebruiker toelaat, of omgekeerd, het 'n spesifieke posisie wat neergeskryf moet word eerder as aangeneem. Hulpbronregte wat ná toelating toegepas word, is deel van dieselfde veld, want verifikasie is nie magtiging nie.
Die behoud van gasheernaam- en sertifikaatkontroles is belangriker as die herkenbaarheid van die aanmeldvenster. 'n Kliënt wat gekonfigureer is om verifikasie te ignoreer, het die enigste stap verwyder wat jou poort van 'n oortuigende nabootsing onderskei.
Die grens wat die produk blootstel
'n Portaal sonder kliënt volmag geselekteerde programbewerkings deur die poort, so die gebruiker bereik 'n koppelvlak eerder as 'n netwerk. 'n Volledige tonnel-kliënt dra alles wat sy roetes en filterbeleid selekteer, wat 'n veel groter oppervlak is. Om die twee volgens protokolsterkte te vergelyk, mis die verskil in wat 'n aanvaller daardeur kan bereik. Die een stel 'n programkoppelvlak bloot, die ander 'n gerouteerde netwerk, en die twee vereis verskillende keurings.
Vra watter diens blootgestel is, watter bewerkings gemagtig is en waarop die poort self luister. 'n Bestuurskoppelvlak wat vanaf dieselfde adres as die gebruikerportaal bereikbaar is, is 'n ontplooiingsbevinding, en geen protokolkeuse vergoed daarvoor nie.
Omvang per program vernou die oppervlak verder, en dit verander ook die foutgedrag wanneer die tonnel val. 'n Ontwerp wat volledige tonnelbereik aanneem, sal breek op maniere wat 'n per-program-ontwerp nie doen nie, en die ondersteuningslas volg.
Bepaal die foutuitkoms en die lewensiklus
Wat gebeur wanneer verifikasie of beskerming onbeskikbaar is, is 'n beleidsbesluit wat in die keuring hoort. 'n Geblokkeerde uitkoms en 'n onaangekondigde direkte terugval het verskillende gevolge, en die verskil is onsigbaar in 'n funksielys. Stel die beoogde gedrag langs die hulpbron wat dit beskerm.
Sluit die poort se pleister- en ondersteuningslewensiklus in, sy geaktiveerde eksterne funksies en die opdateringspad vir kliënte. 'n Korrekte protokolkeuse maak nie 'n swak ontplooide diens veilig nie, en die meeste voorvalle woon in daardie gaping eerder as in die suite.
Skryf die vyf velde, die foutbeleid en die eienaar van die lewensiklus op een bladsy. Daardie bladsy is 'n keuring; 'n vergelyking van protokolfamilies is 'n mening.