tls-auth contro tls-crypt: cosa protegge ciascuno in OpenVPN

Entrambe le opzioni usano un file di chiave condiviso ed entrambe rendono più difficile falsificare il traffico dello handshake, per questo vengono trattate come due nomi dello stesso elemento. Non lo sono. Una firma i pacchetti di controllo, l'altra li cifra anche, e nessuna delle due ha a che fare con il cifrario che protegge i tuoi dati.

Questa distinzione conta quando un profilo non riesce a connettersi, quando una revisione di sicurezza chiede cosa protegge la chiave e quando qualcuno presume che il file aggiuntivo renda il tunnel cifrato in qualche modo indefinito.

Cosa protegge davvero la chiave condivisa

La chiave usata da queste opzioni appartiene al canale di controllo: lo scambio che negozia i parametri, dimostra le identità e deriva le chiavi dei dati. È un segreto precondiviso che entrambe le estremità devono possedere prima che lo handshake possa procedere. Poiché si colloca prima dei controlli di identità, una chiave errata ferma la conversazione prima di quanto farebbe una password errata. Quest'ordine spiega perché la modalità di guasto sia così silenziosa.

tls-auth usa quel segreto per calcolare un HMAC sui pacchetti di controllo. Un pacchetto senza firma valida viene scartato prima di raggiungere l'elaborazione TLS, più costosa, ed è per questo che l'opzione è spesso descritta come un primo filtro anziché un sostituto di TLS.

tls-crypt va oltre cifrando il traffico di controllo protetto oltre ad autenticarlo. Il contenuto dei certificati, i nomi dei cifrari negoziati e altri dettagli dello handshake non sono più visibili sulla rete, e un osservatore senza la chiave non può nemmeno vedere quale versione di TLS venga tentata. Per un'installazione che teme di rivelare la propria impronta VPN, questa proprietà è il motivo principale per sceglierla. Resta comunque un segreto di gruppo, non una credenziale per utente.

Nessuno dei due meccanismi rilascia identità. La chiave condivisa è un segreto di gruppo, e chiunque la possieda può soddisfare quel livello del controllo.

Dove le due opzioni differiscono

La differenza osservabile è ciò che vede un osservatore. Con tls-auth lo handshake è visibile ma non verificabile senza la chiave. Con tls-crypt lo handshake è opaco per chi non possiede la chiave.

Anche la configurazione differisce. tls-auth si usa con un valore di direzione, quindi un lato usa una metà del materiale della chiave e l'altro lato l'altra metà. tls-crypt usa un'unica chiave in entrambe le direzioni, perciò la direttiva di direzione non fa parte del suo schema.

Nelle versioni moderne le due opzioni si escludono a vicenda. Un profilo deve portarne una, non entrambe, e server e client devono concordare quale, con materiale della chiave identico. Tenere una vecchia direttiva accanto a una nuova è un residuo di migrazione comune. Rimuovi quella inattiva così il prossimo lettore sa quale livello è davvero in vigore.

Una variante più recente, tls-crypt-v2, lega ogni client alla propria chiave avvolta, così revocare un client non richiede di riemettere la chiave di gruppo. Vale la pena conoscerla, ma è un'opzione diversa e non un sinonimo di nessuna delle due qui.

Perché una discrepanza sembra che non succeda nulla

Quando il materiale condiviso non corrisponde, l'altra estremità scarta i pacchetti senza dire al mittente perché. Non c'è alcun errore di autenticazione da leggere, perché il pacchetto non ha mai raggiunto il livello che lo produrrebbe.

Il client riprova, il server non dice nulla e il sintomo sembra un problema di rete. Allora le persone riavviano il servizio, ridigitano la password dell'account o rimuovono la direttiva di protezione per «testarla», il che cambia l'installazione invece di diagnosticarla.

Leggi nel log del server la prima lamentela a livello di pacchetto invece dell'ultima riga di nuovo tentativo. Conferma che entrambi i lati portino la stessa opzione con materiale della chiave identico e che il file della chiave non sia stato rigenerato solo su un lato.

Rimuovere la direttiva non è una riparazione sicura. Disattiva un livello di protezione per ogni client, e un tunnel che poi funziona dimostra solo che quel livello era la discrepanza.

Cosa va ancora configurato separatamente

Queste opzioni non verificano chi sia l'altra estremità. La validazione dei certificati, l'ancora di fiducia e il nome del server atteso restano requisiti separati, e nessuno diventa facoltativo perché è presente una chiave condivisa.

Non scelgono nemmeno il cifrario dei dati. Quella è una negoziazione separata, controllata dalle impostazioni del canale dati su entrambi i lati, e un tunnel protetto con tls-crypt può comunque usare un cifrario che non intendevi.

Infine, la chiave condivisa stessa richiede gestione. Trattala come un segreto, distribuiscila tramite un canale approvato e sostituiscila quando chiunque la possedesse se ne va. Poiché è condivisa, la sua esposizione è l'esposizione di ogni estremità che la usa.