VPN TLS versus IPsec: cele cinci câmpuri care merită verificate

A clasifica VPN-urile TLS împotriva VPN-urilor IPsec după familia de protocoale răspunde la o întrebare pe care nimeni nu a pus-o și citează de obicei o construcție pe care ambele familii au abandonat-o acum ani. Ce poate evalua cu adevărat un recenzent este protecția negociată, identitatea omologului, modelul de client și serviciul expus. Aceste patru lucruri sunt vizibile într-un deployment și niciunul nu decurge din eticheta produsului. Cereți cinci câmpuri și conversația devine concretă.

Cinci câmpuri, iar eticheta nu este unul dintre ele

Primul câmp este versiunea de software acceptată, pentru că o descriere de protocol fără versiune este o broșură. Al doilea este versiunea de protocol negociată, care decide ce construcții sunt chiar disponibile. Al treilea este suita de protecție, al patrulea metoda de autentificare atât pentru omolog, cât și pentru utilizator, iar al cincilea domeniul de acces acordat de produs după admitere.

O etichetă VPN SSL acoperă cel puțin trei produse diferite: un client de rețea complet, un proxy de aplicații și un portal vechi bazat pe browser. Expun servicii diferite și eșuează diferit, așa că eticheta nu poate ține locul câmpului de domeniu.

Ce schimbă de fapt criptarea autentificată

TLS 1.3 impune criptarea autentificată, ceea ce elimină construcția mai veche MAC-then-encrypt din protocol în loc să o lase opțională. IPsec ESP are suite de criptare autentificată de tot atâta timp, cu AES-GCM definit în propriul RFC. În ambele familii garanția vine din suita negociată, nu din numele familiei, motiv pentru care lista câmpurilor începe cu o versiune. Un recenzent care nu poate numi suita nu are ce evalua.

De aceea comparația istorică este înșelătoare. Un deployment fixat pe o versiune veche de TLS cu o suită CBC și unul care rulează TLS 1.3 cu o suită AEAD nu au aceeași postură de securitate, chiar dacă ambele sunt VPN-uri TLS. Aceeași diviziune există și pe partea IPsec, între o suită ESP modernă și o combinație veche.

Citiți valorile negociate în locul configurației pe care intenționați să o aplicați. Comenzile de mai jos arată la ce au convenit efectiv un punct final activ și un tunel activ.

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

Dacă punctul final nu vrea să negocieze TLS 1.3, acesta este un constat, nu o preferință. Dacă tunelul listează o suită la care nu vă așteptați, configurația care contează este cea aleasă de omologi, nu cea din șablon.

Identitatea omologului este o întrebare separată

Criptarea fără un omolog verificat protejează traficul de observatori și îl predă cui a răspuns la conexiune. Autentificarea omologului întreabă ce identitate este așteptată, ce material de încredere o validează și cum se comportă clientul când răspunsul nu corespunde. Un lanț de certificate, o cheie fixată și un secret prepartajat sunt trei răspunsuri diferite cu trei costuri operaționale diferite.

Apoi puneți aceleași întrebări despre utilizator sau dispozitiv. O poartă care autentifică mașina și admite orice utilizator, sau invers, are o postură specifică ce ar trebui scrisă, nu presupusă. Permisiunile de resurse aplicate după admitere fac parte din același câmp, pentru că autentificarea nu este autorizare.

Păstrarea verificărilor de nume de gazdă și certificat contează mai mult decât familiaritatea ferestrei de conectare. Un client configurat să ignore verificarea a eliminat singurul pas care distinge poarta dumneavoastră de o imitație convingătoare.

Limita pe care o expune produsul

Un portal fără client proxyază operațiuni de aplicație selectate prin poartă, astfel încât utilizatorul ajunge la o interfață, nu la o rețea. Un client cu tunel complet transportă ceea ce selectează rutele și politica sa de filtrare, ceea ce este o suprafață mult mai mare. Compararea celor două după puterea protocolului ratează diferența în ce poate atinge un atacator prin ele. Unul expune o interfață de aplicație, celălalt expune o rețea rutată, iar cele două necesită evaluări diferite.

Întrebați ce serviciu este expus, ce operațiuni sunt autorizate și pe ce ascultă poarta însăși. O interfață de administrare accesibilă de la aceeași adresă ca portalul utilizatorilor este un constat de deployment, iar nicio alegere de protocol nu îl compensează.

Domeniul pe aplicație îngustează și mai mult suprafața și schimbă și comportamentul la defecțiune când cade tunelul. Un design care presupune acoperire de tunel complet se rupe în moduri pe care un design per aplicație nu le cunoaște, iar încărcarea de suport urmează.

Decideți rezultatul defecțiunii și ciclul de viață

Ce se întâmplă când autentificarea sau protecția nu sunt disponibile este o decizie de politică ce aparține evaluării. Un rezultat blocat și o revenire directă neanunțată au consecințe diferite, iar diferența este invizibilă într-o listă de funcții. Declarați comportamentul intenționat lângă resursa pe care o protejează.

Includeți ciclul de viață al patch-urilor și al suportului pentru poartă, funcțiile externe activate și calea de actualizare a clienților. O alegere corectă de protocol nu face sigur un serviciu prost implementat, iar majoritatea incidentelor trăiesc în acel gol, nu în suită.

Scrieți cele cinci câmpuri, politica de defecțiune și proprietarul ciclului de viață pe o singură pagină. Acea pagină este o evaluare; o comparație de familii de protocoale este o opinie.