Un certificato VPN personalizzato non è uno strato di cifratura in più

Installare un certificato personalizzato su un endpoint VPN sembra aggiungere protezione, perché certificati e cifratura compaiono ovunque insieme. In pratica cambia due cose: quale identità presenta l’endpoint e a quale emittente il suo pari è disposto a fidarsi. Nessuna delle due avvolge i vostri dati una seconda volta. Se l’esigenza reale è un secondo canale protetto, serve un secondo canale con i propri endpoint, non un altro certificato.

Tre compiti separati in un handshake TLS 1.3

RFC 8446 tiene separate queste cose, e la separazione è tutta la risposta. Il messaggio Certificate trasporta la catena di certificati dell'endpoint. CertificateVerify dimostra il possesso della chiave privata corrispondente e lega la trascrizione dell'handshake. Lo strato record protegge il traffico con le chiavi di traffico negoziate.

Sostituite il certificato e i primi due elementi cambiano. La protezione dei record non viene eseguita due volte e non diventa più forte perché l’emittente ora è privato.

Che cosa compra davvero una CA privata

Compra un sistema di identità controllato: voi decidete chi riceve l’emissione, voi decidete quali emittenti accettano i pari, e potete revocare secondo il vostro calendario. È davvero utile quando gestite entrambe le estremità.

Però importa anche obblighi. La fiducia va distribuita deliberatamente, la verifica del pari deve restare attiva e il ciclo di vita delle credenziali deve avere un responsabile. Una CA privata non è una scorciatoia attorno a nessuna di queste tre cose.

Quando un secondo canale è la risposta giusta

Supponiamo che un’applicazione apra HTTPS verificato verso il proprio servizio mentre i suoi pacchetti passano anche da una VPN. Quel progetto ha due confini con endpoint potenzialmente diversi, ed è così che appare un secondo canale protetto.

La distinzione conta al gateway. Se la sessione TLS dell’applicazione termina al gateway VPN invece che nell’applicazione, la protezione che pensavate di avere oltre il tunnel non c’è. Scrivete chi termina ogni canale prima di rivendicare la proprietà.

Chiedete cosa cambia l’installazione

Una richiesta di installare un certificato può significare tre cose diverse. Può cambiare l’identità del client stesso, un’ancora di fiducia specifica di un’applicazione, oppure la fiducia a livello di piattaforma per tutto ciò che è sul dispositivo. Non sono equivalenti, e solo l’ultima influisce su software non correlato.

Chiedete quale delle tre è intesa, poi chiedete cosa dovrebbe ottenere. Se la risposta è più cifratura, la proposta punta al meccanismo sbagliato.

Scrivete i confini

Per ogni canale annotate gli endpoint, l’identità che ciascun lato verifica e ciò che l’operatore in mezzo può vedere. Poi annotate il comportamento in caso di guasto: cosa succede quando la verifica fallisce e cosa succede quando il canale viene rifiutato.

Due righe su una pagina di solito risolvono una discussione che una rotazione dei certificati non può risolvere.

Decidete con tre domande

Il problema è chi dice di essere l’endpoint, o cosa succede ai dati? La protezione deve proseguire oltre il gateway VPN fino a un’applicazione specifica? E riuscite a nominare i due endpoint che terminerebbero un secondo canale?

Se la prima domanda è quella vera, correggete identità e fiducia. Se lo è la seconda o la terza, progettate il secondo canale e lasciate il certificato dove deve stare.