VPN TLS contro IPsec: i cinque campi che vale la pena esaminare

Mettere in classifica i VPN TLS rispetto ai VPN IPsec per famiglia di protocolli risponde a una domanda che nessuno ha posto, e di solito cita una costruzione che entrambe le famiglie hanno abbandonato anni fa. Ciò che un revisore può davvero valutare è la protezione negoziata, l’identità del peer, il modello di client e il servizio esposto. Queste quattro cose sono visibili in un deployment, e nessuna deriva dall’etichetta del prodotto. Chiedi cinque campi e la conversazione diventa concreta.

Cinque campi, e l’etichetta non è uno di questi

Il primo campo è la release software supportata, perché una descrizione del protocollo senza versione è una brochure. Il secondo è la versione negoziata del protocollo, che decide quali costruzioni siano persino disponibili. Il terzo è la suite di protezione, il quarto il metodo di autenticazione per peer e utente, e il quinto l’ambito di accesso concesso dal prodotto dopo l’ammissione.

Un’etichetta VPN SSL copre almeno tre prodotti diversi: un client di rete completo, un proxy applicativo e un portale legacy basato su browser. Espongono servizi diversi e falliscono diversamente, quindi l’etichetta non può sostituire il campo dell’ambito.

Cosa cambia davvero la cifratura autenticata

TLS 1.3 richiede la cifratura autenticata, che rimuove dal protocollo la costruzione MAC-then-encrypt più vecchia invece di lasciarla opzionale. IPsec ESP dispone di suite a cifratura autenticata da altrettanto tempo, con AES-GCM definito in una propria RFC. In entrambe le famiglie la garanzia viene dalla suite negoziata e non dal nome della famiglia, ed è per questo che l’elenco dei campi inizia da una versione. Un revisore che non sa nominare la suite non ha nulla da valutare.

Ecco perché il confronto storico è fuorviante. Un deployment fissato a una vecchia versione di TLS con una suite CBC e uno che esegue TLS 1.3 con una suite AEAD non hanno la stessa postura di sicurezza, anche se entrambi sono VPN TLS. La stessa divisione esiste sul lato IPsec tra una suite ESP moderna e una combinazione legacy.

Leggi i valori negoziati invece della configurazione che intendevi. I comandi qui sotto mostrano ciò su cui un endpoint attivo e un tunnel attivo si sono realmente accordati.

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

Se l’endpoint non vuole negoziare TLS 1.3, è un riscontro e non una preferenza. Se il tunnel elenca una suite che non ti aspettavi, la configurazione che conta è quella scelta dai peer, non quella nel modello.

L’identità del peer è una questione separata

La cifratura senza un peer verificato protegge il traffico dagli osservatori e lo consegna a chiunque abbia risposto alla connessione. L’autenticazione del peer chiede quale identità è attesa, quale materiale di fiducia la convalida e come si comporta il client quando la risposta non corrisponde. Una catena di certificati, una chiave fissata e un segreto precondiviso sono tre risposte diverse con tre costi operativi diversi.

Poi poni le stesse domande sull’utente o sul dispositivo. Un gateway che autentica la macchina e ammette qualsiasi utente, o il contrario, ha una postura precisa che va scritta anziché presunta. Le autorizzazioni alle risorse applicate dopo l’ammissione fanno parte dello stesso campo, perché l’autenticazione non è l’autorizzazione.

Preservare i controlli su nome host e certificato conta più della familiarità della finestra di accesso. Un client configurato per ignorare la verifica ha rimosso l’unico passaggio che distingue il tuo gateway da un’imitazione convincente.

Il confine che il prodotto espone

Un portale senza client fa da proxy per operazioni applicative selezionate attraverso il gateway, così l’utente raggiunge un’interfaccia anziché una rete. Un client a tunnel completo trasporta ciò che le sue rotte e la sua politica di filtraggio selezionano, che è una superficie molto più ampia. Confrontare i due per forza del protocollo manca la differenza in ciò che un attaccante può raggiungere attraverso di essi. Uno espone un’interfaccia applicativa, l’altro una rete instradata, e i due richiedono revisioni diverse.

Chiedi quale servizio è esposto, quali operazioni sono autorizzate e su cosa ascolta il gateway stesso. Un’interfaccia di gestione raggiungibile dallo stesso indirizzo del portale utente è un riscontro di deployment, e nessuna scelta di protocollo lo compensa.

L’ambito per applicazione restringe ulteriormente la superficie, e cambia anche il comportamento in caso di guasto quando il tunnel cade. Un progetto che presuppone la portata del tunnel completo si rompe in modi che un progetto per app non conosce, e il carico di supporto segue.

Decidi l’esito di errore e il ciclo di vita

Ciò che accade quando l’autenticazione o la protezione non è disponibile è una decisione politica che appartiene alla revisione. Un esito bloccato e un fallback diretto non annunciato hanno conseguenze diverse, e la differenza è invisibile in un elenco di funzionalità. Dichiara il comportamento previsto accanto alla risorsa che protegge.

Includi il ciclo di vita delle patch e del supporto del gateway, le sue funzionalità esterne abilitate e il percorso di aggiornamento dei client. Una scelta di protocollo corretta non rende sicuro un servizio mal distribuito, e la maggior parte degli incidenti vive in quel divario anziché nella suite.

Scrivi i cinque campi, la politica di errore e il responsabile del ciclo di vita in una pagina. Quella pagina è una revisione; un confronto di famiglie di protocolli è un’opinione.