{"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":"La DPI (ispezione SSL) contraddice il principio della crittografia, ma le aziende la implementano.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

L'ispezione del traffico SSL (decifratura SSL\/TLS, analisi SSL o DPI) sta diventando un argomento sempre pi\u00f9 caldo nel settore aziendale. L'idea di decifrare il traffico sembra contraddire il concetto stesso di crittografia. Tuttavia, \u00e8 un dato di fatto: un numero crescente di aziende utilizza tecnologie DPI, giustificando questa scelta con la necessit\u00e0 di controllare il contenuto alla ricerca di malware, fughe di dati, ecc.<\/p>\n

Bene, se accettiamo come dato di fatto che sia necessario implementare tale tecnologia, allora dovremmo almeno considerare i modi per farlo nel modo pi\u00f9 sicuro e gestito possibile. Dovremmo almeno non fare affidamento su quei certificati, ad esempio, che fornisce il fornitore del sistema DPI.<\/p>\n

C'\u00e8 un aspetto dell'implementazione di cui non tutti sono a conoscenza. In effetti, molti rimangono davvero sorpresi quando ne sentono parlare. Questo \u00e8 il centro di certificazione privato (CA). Genera certificati per la decifratura e la ri-critto del traffico.
\n<\/a><\/noindex>
\nInvece di fare affidamento su certificati autofirmati o certificati provenienti da dispositivi DPI, puoi utilizzare un CA dedicato di un'autorit\u00e0 di certificazione di terze parti, come GlobalSign. Ma prima facciamo una breve 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 quota di traffico crittografato in Russia ha raggiunto l'83%.<\/p>\n

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

Sfortunatamente, i criminali informatici utilizzano sempre pi\u00f9 frequentemente la crittografia del traffico, specialmente dato che Let's Encrypt distribuisce migliaia di certificati SSL gratuiti in modo automatizzato. Di conseguenza, HTTPS \u00e8 ampiamente adottato \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. Queste soluzioni si inseriscono tra gli utenti finali (cio\u00e8 i vostri dipendenti che navigano sul web) e Internet, filtrando il traffico dannoso. Oggi ci sono diversi prodotti sul mercato, ma i processi sono essenzialmente simili. Il traffico HTTPS passa attraverso un dispositivo di controllo, dove viene decrittato e verificato per identificare eventuali malware.<\/p>\n

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

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

\nPer consentire al dispositivo di ispezione SSL di decrittare 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 essere installato un certificato CA su di esso.<\/p>\n

Per un'azienda (o per un'altra persona coinvolta), \u00e8 fondamentale che i certificati SSL siano considerati affidabili nei browser (ossia, non causino messaggi di avviso inquietanti come quello riportato di seguito). Pertanto, la catena CA (o gerarchia) deve trovarsi nel repository di fiducia del browser. Poich\u00e9 questi certificati non sono emessi da autorit\u00e0 di certificazione pubbliche riconosciute, \u00e8 necessario trasferire manualmente la gerarchia CA a tutti i clienti finali.<\/p>\n

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

Nei computer Windows, si possono utilizzare Active Directory e le politiche di gruppo, ma per i dispositivi mobili la procedura \u00e8 pi\u00f9 complessa.<\/p>\n

La situazione si complica ulteriormente se \u00e8 necessario gestire altri certificati radice in un ambiente aziendale, ad esempio da Microsoft o basati su OpenSSL. Inoltre, la protezione e la gestione delle chiavi private sono cruciali, affinch\u00e9 nessuna di queste chiavi scada inaspettatamente.<\/p>\n

La soluzione migliore \u00e8 un certificato radice privato e dedicato da una CA esterna.<\/h2>\n

\nSe la gestione di pi\u00f9 radici o dei certificati autofirmati non \u00e8 attraente, esiste anche un'altra opzione: affidarsi a un'autorit\u00e0 di certificazione esterna. In questo caso, i certificati sono rilasciati da un'autorit\u00e0<\/b> di certificazione privata che \u00e8 collegata nella catena di fiducia a una radice dedicata e privata, creata appositamente per l'azienda.<\/p>\n

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

Questa configurazione elimina alcuni dei problemi menzionati in precedenza: riduce quantomeno il numero di radici da gestire. Qui si pu\u00f2 utilizzare un'unica radice privata per tutte le necessit\u00e0 interne della PKI con qualsiasi numero di autorit\u00e0 di certificazione intermedie. Ad esempio, nel diagramma sopra \u00e8 mostrata una gerarchia multilivello, in cui una delle autorit\u00e0 di certificazione intermedie \u00e8 utilizzata per la verifica\/decriptazione SSL, mentre un'altra \u00e8 destinata a computer interni (laptop, server, desktop, ecc.).<\/p>\n

In questo schema non \u00e8 necessario posizionare il CA su tutti i client, poich\u00e9 il CA di livello superiore \u00e8 ospitato da GlobalSign, il che risolve i problemi di protezione della chiave privata e di scadenza.<\/p>\n

Un altro vantaggio di questo approccio \u00e8 la possibilit\u00e0 di revocare un certificato SSL di ispezione per qualsiasi motivo. Al suo posto, se ne crea semplicemente uno nuovo, legato al tuo root privato originale, e pu\u00f2 essere utilizzato immediatamente.<\/p>\n

Nonostante tutte le controversie, le aziende stanno sempre pi\u00f9 implementando l'ispezione SSL del traffico come parte dell'infrastruttura PKI interna o privata. Altre opzioni per l'uso della PKI privata includono l'emissione di certificati per l'autenticazione di dispositivi o utenti, SSL per server interni, cos\u00ec come varie configurazioni che non sono consentite nei certificati pubblici di fiducia secondo i requisiti del CA\/Browser Forum.<\/p>\n

I browser resistono<\/h2>\n

\nVa notato che gli sviluppatori di browser stanno cercando di opporsi a questa tendenza e proteggere gli utenti finali dai MiTM. Ad esempio, pochi giorni fa Mozilla ha preso una decisione<\/a><\/noindex> attivare di default il protocollo DoH (DNS-over-HTTPS) in una delle seguenti versioni del browser Firefox. Il protocollo DoH nasconde le richieste DNS dagli sistemi DPI, rendendo pi\u00f9 difficile l'ispezione SSL.<\/p>\n

Riguardo a piani simili del 10 settembre 2019 ha annunciato<\/a><\/noindex> la societ\u00e0 Google per il browser Chrome.<\/p>\n

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

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

Cosa ne pensate, la societ\u00e0 ha il diritto di ispezionare il traffico SSL dei propri dipendenti?<\/h2>\n