SSL VPN o involucro TLS? Confrontate il confine che ha fallito

Due progetti possono far girare TLS sulla porta 443 e significare cose del tutto diverse. Un involucro protegge una connessione configurata tra una porta locale e un backend remoto. Un progetto di accesso alla rete trasporta traffico selezionato e cambia ciò che il client può raggiungere. Fate le quattro verifiche qui sotto in ordine e saprete quale dei due state guardando, il che di solito basta per sapere quale strato ha fallito.

Partite dalla connessione che avete davvero configurato

Annotate il front-end e il back-end prima di confrontare i prodotti. Un involucro ascolta su un indirizzo locale e inoltra a uno remoto, oppure avvia un programma sul lato remoto, e quella coppia è tutto il suo contratto. Le altre applicazioni del client non ne sanno nulla, a meno che non le indirizziate verso di esso. Non è un difetto dello strumento, è a questo che serve lo strumento.

Il contratto di un progetto di rete è diverso, e si esprime in rotte e politiche, non in una coppia di porte.

Notate quale delle due descrizioni corrisponde al vostro diagramma. Se la risposta è una mappatura di porta con un certificato nel mezzo, avete un involucro anche quando il nome del prodotto dice VPN. Se la risposta è un’interfaccia di tunnel e cambiamenti di rotta, avete un progetto di rete anche quando gira sul 443.

Verificate a cosa si collega l’involucro

Leggete le impostazioni di ascolto e di connessione e seguiteli fino al backend reale. Un involucro che inoltra a una porta di database non apre un’applicazione web, e un involucro che esegue un programma avvia quel programma invece di pubblicare tutto il resto che l’host esegue. Il backend è l’unica cosa che l’involucro conosce.

Poi decidete se il flusso inoltrato è testo in chiaro quando TLS finisce. Una connessione avvolta protegge il segmento tra i due involucri, e ciò che accade dopo l’involucro lontano è una questione separata. Per questo avvolgere qualcosa che porta già la propria protezione a volte è sensato e a volte sono solo parti mobili in più. Ispezionate il salto successivo invece di dare per scontata una delle due risposte.

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

Il primo comando mostra il certificato che viene realmente offerto a un client, e il secondo mostra cosa ascolta sull’host. Confrontate quel nome di certificato con quello che vi aspettavate prima di leggere qualsiasi altra cosa.

Verificate quale traffico trasporta il progetto

I progetti di accesso alla rete trasportano traffico selezionato e si integrano con l’instradamento e la politica di accesso del client. L’ammissione non è autorizzazione, quindi una connessione autenticata ha ancora bisogno di una decisione su quali risorse può raggiungere. Un portale senza client è un terzo modello che fa da proxy per le operazioni supportate senza mai apparire come interfaccia tun.

L’etichetta del prodotto non vi dice quale di questi modelli avete comprato, e il numero di porta dice ancora meno.

La sovrapposizione è possibile e non deve confondere il confronto. Un protocollo di tunnel può essere esso stesso avvolto in TLS in una disposizione TCP supportata, il che aggiunge uno strato attorno al tunnel senza trasformare l’involucro nel tunnel. È una scelta progettuale con il proprio comportamento di prestazioni e di guasto, e merita una riga nel diagramma. Annotatela, poi confrontate i modelli sottostanti invece dell’involucro esterno.

Verificate il confine che ha fallito, non l’etichetta

Annotate i fatti di un tentativo fallito: indirizzo del front-end, listener, l’identità che il client ha verificato, la destinazione del backend e l’operazione richiesta. Una stretta di mano riuscita dimostra che il TLS esterno si è completato e non dice nulla sul backend. Un rifiuto del backend è un evento diverso da un guasto di identità sul front-end, e nessuno dei due migliora togliendo -verify_return_error dal client. Confrontate ciò che è confrontabile, perché un successo tramite un altro nome host o porta non dimostra che le condizioni fossero le stesse.

La porta 443 è una convenzione che lascia passare TLS attraverso i dispositivi intermedi. Non rende il traffico arbitrario simile a una richiesta web per un dispositivo di policy.

Concludete con una frase che nomini la coppia di estremi, ciò che viene trasportato, quali applicazioni la usano e quale permesso impone la destinazione. Un progetto che non riesce a riempire quei quattro spazi non è finito, qualunque cosa dica la sua etichetta. Quella frase è anche il modo più rapido per spiegare il progetto a chi possiede il firewall.