Ci sono alcune cose da capire.

Il primo è che la maggior parte degli strumenti VPN sono stati originariamente progettati per fornire connettività privata su reti che erano insicure, eventualmente nate o firewall ma non attivamente ostili alle VPN.

Il secondo è che TLS tradizionale è un wrapper su TCP. TCP è una scelta sbagliata per le VPN perché soffre di "head of line blocking". Se un pacchetto viene perso, tutti i dati dietro di esso vengono bloccati fino a quando non vengono ritrasmessi correttamente. Questo ha causato grossi problemi durante l'esecuzione di VPN su TCP, è meno di un problema ora che abbiamo la ritrasmissione TCP veloce ma è ancora meno ideale.

Il terzo è che l'ispezione approfondita dei pacchetti è una cosa abbastanza nuova. Le reti che passeranno il traffico TLS legittimo non molestato ma che non passeranno altro traffico sulla porta 443 sono ancora l'eccezione e non la regola.

Sebbene Openvpn abbia un'opzione TCP, è progettato in modo primitivo per funzionare su UDP. Utilizza TLS per lo scambio di chiavi ma crittografa i pacchetti di rete effettivi utilizzando un sistema progettato esplicitamente per tale scopo.

link

Someone should say something about DTLS (TLS over UDP) too

DTLS è un protcol piuttosto nuovo. Non vedo alcun motivo per cui non potresti / non dovrei costruire una solitaria VPN su di essa, ma suppongo che i fornitori di software VPN non siano particolarmente in vena di riprogettare il loro software.

In ogni caso non sarebbe di aiuto con lo scenario descritto nella domanda.

Versione breve:

• I protocolli VPN devono fornire l'incapsulamento che TLS non fornisce
• Ovviamente, è possibile eseguire il tunnel VPN su TLS per ottenere lo stesso effetto!

Versione lunga:

Il nome Virtual Private Network suggerisce la risposta alla tua domanda. Un vero protocollo VPN emula una rete, che implica la possibilità di instradare più tipi di traffico e porte contemporaneamente su un singolo canale. Ecco perché con un protocollo VPN come IPSec si può finire, per esempio, con pacchetti TCP incapsulati all'interno di pacchetti ESP incapsulati all'interno di altri pacchetti TCP. (Vedi anche Qual è la differenza tra SSH e IPsec? )

Per impostazione predefinita, TLS non fornisce questa funzionalità. TLS acquisisce i byte, li crittografa e li trasferisce al destinatario che può decrittografarli. Questo è tutto; tutto il resto deve essere fatto dall'applicazione. Sotto HTTPS, un server Web e un client scambiano byte di dati HTTP su un canale TLS. Sotto IMAPS, un server di posta e un client scambiano i byte di dati IMAP su un canale TLS.

Per avere la connettività "di rete" generica su TLS, è necessario un client e un server in grado di eseguire tale incapsulamento e decapsulazione su entrambe le estremità. Non lo capisci gratis.

Questo non vuol dire che non puoi avere una VPN su TLS. Ci sono molti prodotti che lo fanno; anche i fornitori principali come Checkpoint supportano sia VPN IPSec che VPN basate su TLS. In alcuni casi il TLS sta semplicemente incapsulando i datagrammi IPSec, quindi la "N" effettiva è via IPSec, ma il TLS lo ottiene attraverso Internet.

Si noti che in alcuni casi un avversario sofisticato può dedurre quando una connessione TLS viene utilizzata per VPN in base al modello di comunicazione. C'è altro in Sicurezza operativa che crittografare i bit!

Molti protocolli VPN fanno utilizzano TLS. In particolare, quasi tutte le moderne VPN client-server (ad esempio utilizzate per connettere un laptop da remoto a una rete aziendale) supportano TLS come trasporto primario o fallback.

Sono un contributore del noto client open source per VPN basate su TLS / SSL: openconnect . Ho decodificato il protocollo GlobalProtect VPN (TLS + ESP) quasi interamente da solo. Ho studiato abbastanza protocolli VPN in dettaglio per notare alcuni schemi piuttosto chiari e compromessi di progettazione.

Vantaggi di TLS per l'autenticazione e il trasporto VPN:

• Robustezza. Il traffico VPN basato su TLS è indistinguibile dal traffico HTTPS "normale" in termini di struttura del pacchetto e contenuto crittografato, sebbene la tempistica e la dimensione dei pacchetti e la durata delle connessioni indichino che sta trasportando qualcosa di diverso dal "normale" traffico del browser. L'universalità di HTTPS significa che le VPN basate su TLS possono attraversare quasi tutti i firewall e middlebox; solo i censori veramente determinati che eseguono analisi del traffico o endpoint VPN in blacklist tramite DNS o IP, possono bloccarlo.
• Elevate garanzie di sicurezza: il moderno TLSv1.2 (a breve, 1.3) è un protocollo molto ben progettato, accuratamente analizzato e gradualmente maturato per comunicazioni sicure. Molte librerie lo avvolgono in un modo che rende abbastanza difficile l'uso improprio. Se si utilizza una VPN basata su TLS, è possibile prevedere che la propria connessione al gateway utilizzi cifrari moderni (ad esempio 1DES non antico, ad esempio) e x509 per la verifica del certificato a chiave pubblica del gateway, limitando gli attacchi man-in-the-middle. È possibile rovinare l'implementazione di TLS, infrangendo gravemente la sua sicurezza, ma relativamente difficile a causa della standardizzazione di librerie di alta qualità che eseguono la maggior parte dei bit più complessi. Sarebbe molto più facile scrivere una VPN non sicura basata su un protocollo "personalizzato".

Svantaggi di TLS per VPN trasporto , rispetto a ESP (il normale livello di trasporto di IPSEC- VPN basate):

• TLS normalmente funziona su TCP, che funziona male come un trasporto di tunneling con condizioni di rete sottostanti o con perdita di dati ... specialmente nel caso di TCP-over-TCP .
• Fortunatamente DTLS ("datagram TLS") può alleggerirlo; è usato in modo predominante nel protocollo AnyConnect / openconnect VPN, così come nei protocolli di comunicazione in tempo reale come WebRTC.
• La maggior parte dei sistemi operativi moderni ha ottimizzato il supporto nel kernel per IPSEC ed ESP. Ciò rende ESP veramente efficiente e basso overhead per gateway, firewall e sistemi client finali, se implementato correttamente. TLS viene in genere implementato in userspace e, combinato con la complessità del flusso TCP sottostante, lo rende meno efficiente.
• (Dovrebbe esserci un'implementazione del kernel D altrettanto efficiente nel kernel possibile, ma non ne sono a conoscenza in un sistema operativo mainstream.)

... per quanto riguarda l'utilizzo di TLS per l'autenticazione / configurazione di una VPN? Io fondamentalmente non vedo nessun reale svantaggio, a parte la mancanza di un protocollo standardizzato per questo.

TLS è più flessibile, ampiamente implementato e più facile da eseguire per il debug rispetto a ISAKMP (il componente di scambio di chiavi / autenticazione di IPSEC) . Diversi protocolli VPN aziendali moderni, tra cui GlobalProtect, utilizzano TLS per l'autenticazione e lo scambio di chiavi , ma poi ESP per il trasporto dei dati (sebbene possano tornare a TLS se necessario). Questa è una combinazione abbastanza efficace ed efficiente, nella mia esperienza.