VPN TLS contra IPsec: els cinc camps que val la pena revisar

Classificar les VPN TLS enfront de les VPN IPsec per família de protocol respon a una pregunta que ningú no va fer, i sovint cita una construcció que totes dues famílies van deixar d’usar fa anys. El que un revisor pot avaluar de debò és la protecció negociada, la identitat del parell, el model de client i el servei exposat. Aquestes quatre coses són visibles en un desplegament, i cap no es dedueix de l’etiqueta del producte. Demaneu cinc camps i la conversa es torna concreta.

Cinc camps, i l’etiqueta no és un d’ells

El primer camp és la versió de programari admesa, perquè una descripció de protocol sense versió és un fullet. El segon és la versió de protocol negociada, que decideix quines construccions estan fins i tot disponibles. El tercer és la suite de protecció, el quart el mètode d’autenticació tant del parell com de l’usuari, i el cinquè l’abast d’accés que el producte concedeix després de l’admissió.

Una etiqueta VPN SSL cobreix almenys tres productes diferents: un client de xarxa complet, un proxy d’aplicacions i un portal heretat basat en navegador. Exposen serveis diferents i fallen de maneres diferents, així que l’etiqueta no pot substituir el camp d’abast.

Què canvia realment el xifratge autenticat

TLS 1.3 exigeix xifratge autenticat, cosa que elimina del protocol la construcció MAC-then-encrypt més antiga en lloc de deixar-la opcional. IPsec ESP té suites de xifratge autenticat des de fa el mateix temps, amb AES-GCM definit en la seva pròpia RFC. En totes dues famílies la garantia prové de la suite negociada i no del nom de la família, i per això la llista de camps comença per una versió. Un revisor que no pot anomenar la suite no té res a avaluar.

Per això la comparació històrica és enganyosa. Un desplegament fixat a una versió antiga de TLS amb una suite CBC i un altre que executa TLS 1.3 amb una suite AEAD no tenen la mateixa postura de seguretat, encara que tots dos siguin VPN TLS. La mateixa divisió existeix al costat IPsec entre una suite ESP moderna i una combinació heretada.

Llegiu els valors negociats en lloc de la configuració que preteníeu. Les ordres de sota mostren en què van coincidir realment un extrem actiu i un túnel actiu.

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

Si l’extrem no vol negociar TLS 1.3, és una troballa i no una preferència. Si el túnel llista una suite que no esperàveu, la configuració que importa és la que van triar els parells, no la de la plantilla.

La identitat del parell és una qüestió a part

El xifratge sense un parell verificat protegeix el trànsit dels observadors i el lliura a qui hagi respost a la connexió. L’autenticació del parell pregunta quina identitat s’espera, quin material de confiança la valida i com es comporta el client quan la resposta no coincideix. Una cadena de certificats, una clau fixada i un secret precompartit són tres respostes diferents amb tres costos operatius diferents.

Després feu les mateixes preguntes sobre l’usuari o el dispositiu. Una passarel·la que autentica la màquina i admet qualsevol usuari, o el contrari, té una postura concreta que s’hauria d’escriure en lloc de suposar. Els permisos de recursos aplicats després de l’admissió formen part del mateix camp, perquè l’autenticació no és l’autorització.

Conservar les comprovacions de nom d’amfitrió i de certificat importa més que la familiaritat de la finestra d’inici de sessió. Un client configurat per ignorar la verificació ha eliminat l’únic pas que distingeix la vostra passarel·la d’una imitació convincent.

El límit que exposa el producte

Un portal sense client fa de proxy d’operacions d’aplicació seleccionades a través de la passarel·la, així que l’usuari arriba a una interfície en lloc d’una xarxa. Un client de túnel complet transporta el que seleccionen les seves rutes i la seva política de filtratge, que és una superfície molt més gran. Comparar els dos per la força del protocol passa per alt la diferència en el que un atacant pot assolir a través d’ells. Un exposa una interfície d’aplicació, l’altre exposa una xarxa encaminada, i els dos exigeixen revisions diferents.

Pregunteu quin servei està exposat, quines operacions estan autoritzades i en què escolta la mateixa passarel·la. Una interfície d’administració accessible des de la mateixa adreça que el portal d’usuari és una troballa de desplegament, i cap elecció de protocol no ho compensa.

L’abast per aplicació redueix encara més la superfície, i també canvia el comportament de fallada quan cau el túnel. Un disseny que suposa abast de túnel complet falla de maneres que un disseny per aplicació no coneix, i la càrrega de suport segueix.

Decidiu el resultat de fallada i el cicle de vida

Què passa quan l’autenticació o la protecció no estan disponibles és una decisió de política que pertany a la revisió. Un resultat bloquejat i una tornada directa no anunciada tenen conseqüències diferents, i la diferència és invisible en una llista de funcions. Indiqueu el comportament previst al costat del recurs que protegeix.

Incloeu el cicle de vida de pedaços i suport de la passarel·la, les seves funcions externes habilitades i el camí d’actualització dels clients. Una elecció de protocol correcta no fa segur un servei mal desplegat, i la majoria dels incidents viuen en aquest buit i no en la suite.

Escriviu els cinc camps, la política de fallada i el responsable del cicle de vida en una pàgina. Aquesta pàgina és una revisió; una comparació de famílies de protocol és una opinió.