Catena di fiducia. CC BY-SA 4.0
L'ispezione del traffico SSL (decrittografia SSL/TLS, analisi SSL o DPI) sta diventando un argomento di discussione sempre più caldo nel settore aziendale. L’idea di decriptare il traffico sembra contraddire il concetto stesso di crittografia. Tuttavia, il fatto è un dato di fatto: sempre più aziende utilizzano le tecnologie DPI, spiegando ciò con la necessità di controllare i contenuti per individuare malware, fughe di dati, ecc.
Ebbene, se accettiamo il fatto che tale tecnologia debba essere implementata, allora dovremmo almeno considerare come farlo nel modo più sicuro e meglio gestito possibile. Almeno non fare affidamento su quei certificati, ad esempio, che ti fornisce il fornitore del sistema DPI.
C'è un aspetto dell'implementazione che non tutti conoscono. In effetti, molte persone rimangono davvero sorprese quando ne sentono parlare. Questa è un'autorità di certificazione privata (CA). Genera certificati per decrittografare e crittografare nuovamente il traffico.
Invece di fare affidamento su certificati autofirmati o certificati provenienti da dispositivi DPI, puoi utilizzare una CA dedicata di un'autorità di certificazione di terze parti come GlobalSign. Ma prima, facciamo una piccola panoramica del problema stesso.
Cos'è l'ispezione SSL e perché viene utilizzata?
Sempre più siti Web pubblici stanno passando a HTTPS. Ad esempio, secondo , all'inizio di settembre 2019, la quota di traffico crittografato in Russia ha raggiunto l'83%.
Sfortunatamente, la crittografia del traffico viene utilizzata sempre più spesso dagli aggressori, soprattutto perché Let's Encrypt distribuisce migliaia di certificati SSL gratuiti in modo automatizzato. Pertanto, HTTPS viene utilizzato ovunque e il lucchetto nella barra degli indirizzi del browser non è più un indicatore affidabile di sicurezza.
I produttori di soluzioni DPI promuovono i loro prodotti da queste posizioni. Sono incorporati tra gli utenti finali (ovvero i tuoi dipendenti che navigano sul Web) e Internet, filtrando il traffico dannoso. Oggi sul mercato sono disponibili numerosi prodotti di questo tipo, ma i processi sono essenzialmente gli stessi. Il traffico HTTPS passa attraverso un dispositivo di ispezione dove viene decrittografato e controllato per rilevare eventuali malware.
Una volta completata la verifica, il dispositivo crea una nuova sessione SSL con il client finale per decrittografare e crittografare nuovamente il contenuto.
Come funziona il processo di decrittografia/ricocrittografia
Affinché l'appliance di ispezione SSL possa decrittografare e crittografare nuovamente i pacchetti prima di inviarli agli utenti finali, deve essere in grado di emettere certificati SSL al volo. Ciò significa che deve avere un certificato CA installato.
È importante per l'azienda (o chiunque si trovi nel mezzo) che questi certificati SSL siano considerati attendibili dai browser (ovvero, non attivino messaggi di avviso spaventosi come quello seguente). Pertanto la catena (o gerarchia) della CA deve trovarsi nel truststore del browser. Poiché questi certificati non vengono emessi da autorità di certificazione pubblicamente attendibili, è necessario distribuire manualmente la gerarchia della CA a tutti i client finali.
Messaggio di avviso per il certificato autofirmato in Chrome. Fonte:
Sui computer Windows è possibile utilizzare Active Directory e Criteri di gruppo, ma per i dispositivi mobili la procedura è più complicata.
La situazione diventa ancora più complicata se è necessario supportare altri certificati root in un ambiente aziendale, ad esempio quelli di Microsoft o basati su OpenSSL. Inoltre la protezione e la gestione delle chiavi private in modo che nessuna delle chiavi scada inaspettatamente.
L'opzione migliore: certificato root privato e dedicato da una CA di terze parti
Se la gestione di più root o certificati autofirmati non è allettante, c'è un'altra opzione: affidarsi a una CA di terze parti. In questo caso, i certificati vengono emessi da privato una CA collegata in una catena di fiducia a una CA radice privata dedicata creata appositamente per l'azienda.
Architettura semplificata per certificati root client dedicati
Questa configurazione elimina alcuni dei problemi menzionati in precedenza: almeno riduce il numero di radici da gestire. Qui puoi utilizzare una sola autorità root privata per tutte le esigenze PKI interne, con qualsiasi numero di CA intermedie. Ad esempio, il diagramma precedente mostra una gerarchia multilivello in cui una delle CA intermedie viene utilizzata per la verifica/decrittografia SSL e l'altra viene utilizzata per i computer interni (laptop, server, desktop, ecc.).
In questo progetto, non è necessario ospitare una CA su tutti i client poiché la CA di livello superiore è ospitata da GlobalSign, che risolve i problemi di protezione e scadenza della chiave privata.
Un altro vantaggio di questo approccio è la possibilità di revocare l’autorità di ispezione SSL per qualsiasi motivo. Invece, ne viene semplicemente creato uno nuovo, che è legato alla tua root privata originale, e puoi usarlo immediatamente.
Nonostante tutte le controversie, le aziende stanno implementando sempre più l'ispezione del traffico SSL come parte della propria infrastruttura PKI interna o privata. Altri usi della PKI privata includono l'emissione di certificati per l'autenticazione del dispositivo o dell'utente, SSL per server interni e varie configurazioni che non sono consentite nei certificati attendibili pubblici come richiesto dal forum CA/Browser.
I browser stanno reagendo
Va notato che gli sviluppatori di browser stanno cercando di contrastare questa tendenza e proteggere gli utenti finali da MiTM. Ad esempio, pochi giorni fa Mozilla Abilita il protocollo DoH (DNS-over-HTTPS) per impostazione predefinita in una delle prossime versioni del browser in Firefox. Il protocollo DoH nasconde le query DNS dal sistema DPI, rendendo difficile l'ispezione SSL.
Informazioni su piani simili 10 settembre 2019 Google per il browser Chrome.
Solo gli utenti registrati possono partecipare al sondaggio. Per favore.
Pensi che un'azienda abbia il diritto di ispezionare il traffico SSL dei suoi dipendenti?
-
Sì, con il loro consenso
-
No, chiedere tale consenso è illegale e/o non etico
122 utenti hanno votato. 15 utenti si sono astenuti.
Fonte: habr.com