{"id":38110,"date":"2019-10-31T22:21:42","date_gmt":"2019-10-31T19:21:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut\/"},"modified":"2019-10-31T22:21:42","modified_gmt":"2019-10-31T19:21:42","slug":"dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/dpi-inspektsiya-ssl-protivorechit-smyslu-kriptografii-no-kompanii-eyo-vnedryayut","title":{"rendered":"DPI (ispezione SSL) contraddice il principio della crittografia, ma le aziende la implementano","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DPI
\nCatena di fiducia. CC BY-SA 4.0 Yanpas<\/a><\/noindex><\/i><\/p>\n

L'ispezione del traffico SSL (decodifica SSL\/TLS, analisi SSL o DPI) sta diventando un argomento sempre pi\u00f9 dibattuto nel settore aziendale. L'idea di decodificare il traffico sembra contraddire il concetto stesso di crittografia. Tuttavia, i fatti sono incontrovertibili: sempre pi\u00f9 aziende utilizzano tecnologie DPI, giustificando ci\u00f2 con la necessit\u00e0 di controllare i contenuti per malware, fughe di dati, ecc.<\/p>\n

Dunque, se accettiamo la necessit\u00e0 di implementare questa tecnologia, dovremmo almeno considerare i modi per farlo nel modo pi\u00f9 sicuro e gestibile possibile. Ad esempio, non dovremmo affidarci ai certificati che ci fornisce il fornitore del sistema DPI.<\/p>\n

C'\u00e8 un aspetto dell'implementazione di cui non tutti sono a conoscenza. In effetti, molte persone restano davvero sorprese quando ne sentono parlare. Si tratta di un'autorit\u00e0 di certificazione privata (CA). Questa genera certificati per decodificare e ri-criptare il traffico.
\n<\/a><\/noindex>
\nInvece di affidarsi a certificati autofirmati o a certificati provenienti da dispositivi DPI, puoi utilizzare un'autorit\u00e0 di certificazione dedicata di un'autorit\u00e0 di certificazione esterna, come GlobalSign. Ma prima, facciamo una piccola panoramica del problema stesso.<\/p>\n

Che cos'\u00e8 l'ispezione SSL e perch\u00e9 viene utilizzata?<\/h2>\n

\nSempre pi\u00f9 siti web pubblici stanno passando a HTTPS. Ad esempio, secondo le statistiche di Chrome<\/a><\/noindex>, all'inizio di settembre 2019, la percentuale di traffico crittografato in Russia ha raggiunto l'83%.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Sfortunatamente, la crittografia del traffico \u00e8 sempre pi\u00f9 sfruttata anche dai malintenzionati, specialmente ora che Let's Encrypt distribuisce gratuitamente migliaia di certificati SSL in modo automatizzato. Di conseguenza, HTTPS \u00e8 ampiamente utilizzato \u2014 e l'icona del lucchetto nella barra degli indirizzi del browser ha smesso di essere un indicatore affidabile di sicurezza.<\/p>\n

Da queste posizioni i produttori di soluzioni DPI promuovono i loro prodotti. Essi si interpongono tra gli utenti finali (cio\u00e8 i tuoi dipendenti che navigano in internet) e Internet stesso, filtrando il traffico malevolo. Attualmente, sul mercato ci sono diversi di questi prodotti, ma i processi sono essenzialmente gli stessi. Il traffico HTTPS passa attraverso un dispositivo di verifica, dove viene decodificato e controllato per la presenza di malware.<\/p>\n

Al termine della verifica, il dispositivo crea una nuova sessione SSL con il cliente finale per decrittografare e ri-crittografare il contenuto.<\/p>\n

Come funziona il processo di decrittografia\/ri-crittografia<\/h2>\n

\nAffinch\u00e9 il dispositivo di ispezione SSL possa decrittografare e ri-crittografare i pacchetti prima di inviarli agli utenti finali, deve essere in grado di emettere certificati SSL al volo. Ci\u00f2 significa che deve avere installato un certificato CA.<\/p>\n

Per l'azienda (o per un'altra persona intermedia) \u00e8 importante che questi certificati SSL siano fidati nei browser (cio\u00e8 non generino brutti messaggi di avviso, come quello mostrato di seguito). Pertanto, la catena CA (o gerarchia) deve trovarsi nello store di fiducia del browser. Poich\u00e9 questi certificati non sono emessi da autorit\u00e0 di certificazione pubbliche e fidate, \u00e8 necessario trasferire manualmente le gerarchie CA a tutti i client finali.<\/p>\n

\"DPI
\nMessaggio di avviso per un certificato autofirmato in Chrome. Fonte: BadSSL.com<\/a><\/noindex><\/i><\/p>\n

Su computer con Windows, \u00e8 possibile utilizzare Active Directory e le Group Policy, ma per i dispositivi mobili la procedura \u00e8 pi\u00f9 complessa.<\/p>\n

La situazione si complica ulteriormente se \u00e8 necessario supportare anche altre radici di certificato in un ambiente aziendale, ad esempio, da Microsoft o basate su OpenSSL. Inoltre, \u00e8 necessario proteggere le chiavi segrete e gestirle, in modo che nessuna di queste chiavi scada in modo imprevisto.<\/p>\n

La soluzione migliore: un certificato radice privato e dedicato da un'autorit\u00e0 di certificazione esterna.<\/h2>\n

\nSe la gestione di pi\u00f9 radici o certificati autofirmati non \u00e8 attraente, c'\u00e8 un'altra opzione: ci si pu\u00f2 fidare di un'autorit\u00e0 di certificazione esterna. In questo caso, i certificati vengono emessi da un'autorit\u00e0<\/b> di certificazione privata, che \u00e8 collegata nella catena di fiducia a un'autorit\u00e0 di certificazione radice dedicata e privata, creata appositamente per l'azienda.<\/p>\n

\"DPI<\/a><\/noindex>
\nArchitettura semplificata per certificati radice dedicati per i clienti<\/i><\/p>\n

Questa configurazione elimina alcuni dei problemi menzionati in precedenza: almeno riduce il numero di root da gestire. Qui pu\u00f2 essere utilizzato un solo centro di certificazione radice privato per tutte le necessit\u00e0 interne della PKI con qualsiasi numero di centri di certificazione intermedi. Ad esempio, nel diagramma sopra \u00e8 mostrata una gerarchia multilivello, in cui uno dei centri di certificazione intermedi viene utilizzato per la verifica\/decriptazione SSL e un altro per computer interni (portatili, server, desktop, ecc.).<\/p>\n

In questo schema non \u00e8 necessario posizionare CA su tutti i client, poich\u00e9 la CA di livello superiore \u00e8 ospitata da GlobalSign, risolvendo i problemi relativi alla protezione della chiave privata e alla sua scadenza.<\/p>\n

Un ulteriore vantaggio di questo approccio \u00e8 la possibilit\u00e0 di revocare il certificato di ispezione SSL per qualsiasi motivo. Invece, viene semplicemente creato un nuovo certificato collegato al tuo root privato originale, e pu\u00f2 essere utilizzato immediatamente.<\/p>\n

Nonostante tutte le controversie, le imprese stanno sempre pi\u00f9 implementando l'ispezione SSL del traffico come parte dell'infrastruttura PKI interna o privata. Altri utilizzi della PKI privata includono l'emissione di certificati per l'autenticazione di dispositivi o utenti, SSL per server interni, oltre a diverse configurazioni che non sono consentite in certificati pubblicamente fidati secondo i requisiti del CA\/Browser Forum.<\/p>\n

I browser resistono<\/h2>\n

\nBisogna notare che i developer dei browser stanno cercando di contrastare questa tendenza e di proteggere gli utenti finali da attacchi MiTM. Ad esempio, pochi giorni fa Mozilla ha deciso<\/a><\/noindex> ha annunciato di voler abilitare di default il protocollo DoH (DNS-over-HTTPS) in una delle prossime versioni del browser Firefox. Il protocollo DoH nasconde le query DNS dai sistemi DPI, rendendo difficile l'ispezione SSL.<\/p>\n

Un piano simile \u00e8 stato annunciato il 10 settembre 2019 ha annunciato<\/a><\/noindex> da Google per il browser Chrome.<\/p>\n

\"DPI<\/a><\/noindex><\/p>\n

Solo gli utenti registrati possono partecipare al sondaggio. Accedi<\/a><\/noindex>, per favore.<\/p>\n

Secondo te, l'azienda ha il diritto di ispezionare il traffico SSL dei propri dipendenti?<\/h2>\n