3

Feb

HTTPS Inspection

Devo ammetterlo: ho un debole per la funzionalità di HTTPS Inspection di TMG 2010. E’ forse il tipo di inspection più controverso, sia dal punto di vista tecnico (e vederemo il perché) sia dal punto di vista etico/morale/legale. Per quanto riguarda quest’ultimo, che riguarda per la maggior parte il controllo sul traffico di computer aziendali all’interno di rete aziendali, ci sono dei compromessi che possono mitigare il livello d’invasione della privacy ma che richiedono comunque un livello di fiducia da parte dell’utente.

Ma veniamo a noi, perché mi piace così tanto l’HTTPS Inspection? Negli ultimi tempi stiamo assistendo a un incredibile proliferare di connessioni che utilizzano il protocollo HTTP come sistema principale di comunicazione, anche per sistemi che non sembrerebbero portati per viaggiare su un sistema che, ricordiamolo, usa una connessione TCP. Moltissimi sistemi di VPN utilizzano SSL come protocollo (tra cui Microsoft IAG e il suo successore UAG), Exchange consente la lettura della posta servendosi di un RPC over HTTPS, alcuni noti serizi di telefonia usano il VoIP over HTTPS, e così via discorrendo. Il montivo è molto semplice: le connessioni HTTP e HTTPS in uscita sono consentite dalla stragrande maggioranza dei firewall; in aggiunta il contenuto del traffico HTTPS non è ispezionabile.

Per chi di vuoi non avesse familiarità col funzionamento di HTTPS posso dire in due parole che è un sistema, basato sulla combinazione di HTTP e SSL/TLS che utilizza la crittografia assimetrica per scambiare una chiave simmetrica; il tutto per evitare che un eventuale man-in-the-middle (qualcuno che intercetta la comunicazione) possa avere accesso alle informazioni scambiate tra client e server.

SSL

Per avviare una sessione SSL/TLS il server manda al client la sua chiave pubblica, il client genera una chiave di sessione simmetrica e la cripta con la chiave pubblica del server, il server riceve e decripta la chiave simmetrica con la sua chiave privata; una volta scambiata la chiave simmetrica il Client e il Server usano questa per criptare e decriptare i messaggi. Poich é solo il Client e il Server conoscono la chiave simmetrica TMG non potrà ispezionare il traffico ed al suo interno potrebbe essere incapsulato qualsiasi tipo di informazione, da download P2P a virus ad attacchi verso il sistema.

Per fare l’Inspection di una sessione HTTPS Microsoft TMG 2010 spezza di fatto la comunicazione in due sessioni: la prima viene stabilita tra TMG e il Web Server utilizzando la chiave pubblica del Web Server per criptare e scambiare la chiave simmetrica generata da TMG; a questo punto TMG rilascia, tramite la HTTPS Inspection Trusted Root CA Certificate Deployment, un certificato digitale con gli attributi di quello inviatogli dal Web Server, invia la sua chiave pubblica al Client che la userà per criptare e inviare a TMG la chiave simmetrica da lui generata. In questo modo TMG può ispezionare il traffico come una normale sessione HTTP, applicando content filters, scansione antimalware, Intrusion Prevention System, ecc.

 

 InspectedSSL

Quanto TMG inizia la sessione HTTPS verso il Web Server per prima cosa controlla che il certificato del server sia rilasciato da una Trusted Certification Authority, che il certificato non sia scaduto o non ancora valido, che sia per il sito indicato e che non sia all’interno di una Revocation List; è possibile configurare quali controlli escludere e il livello di tolleranza per i certificati scaduti. In caso uno solo di questi controlli dovesse fallire la sessione non verrà stabilita. Per questi motivi non è possibile accedere a siti che utilizzano un certificato Self'-Signed quando HTTPS Inspection è abilitata, per ovviare al problema è possibile inserire questi siti tra le Destination Exceptions.

Tuttavia, perché il processo funzioni in modo trasparente, è necessario che tutti i computer client abbiano installata la HTTPS Inspection Trusted Root CA tra le Trusted Certification Authorities; in caso di TMG all’intendo di Active Directory questo è estremamente semplice grazie all’apposita funzione nel pannello di gestione di HTTPS Inspection.

image 

In caso di TMG fuori dominio sarà necessario esportare il certificato della CA e distribuirlo nella Trusted Root CA con, ad esempio, una Grop Policy adeguata o, più semplicemente, inserire manualmente il certificato.

E’ possibile e auspicabile notificare l’utente dell’ispezione, questa opzione è configurabile dal Tab Client Notification e per poter essere visualizzata è necessario che il computer abbia installato il client di TMG.

Sempre nella configurazione della HTTPS Inspection è possibile selezionare quali gruppi di utenti o quali siti siano esclusi dal controllo.

E’ importante notare che tra le Destination Exceptions sia possibile inserire delle categorie di siti, sarebbe ad esempio adeguato escludere dalla HTTPS Inspection le categorie Finantial e Health in modo che le sessioni destinate a siti con dati sicuramente sensibili come quelli di istituti bancari o di servizi ospedalieri non vengano presi in considerazione per l’Inspection.

mshome

by Francesco V. Buccoli on 2/3/2010
Post archive