Se il tuo software di filtraggio è implementato come proxy HTTP (possibilmente trasparente), l'unico modo per filtrare le connessioni HTTPS è fare un'ispezione SSL Man-in-the-Middle. Questa è una tecnica un po 'complicata e intrusiva, ma alcuni proxy di filtraggio lo supportano. Il modo in cui funziona fondamentalmente è questo:
-
Ogni volta che il proxy intercetta un handshake SSL, non lo inoltra al sito di destinazione ma risponde ad esso direttamente, utilizzando il proprio certificato autofirmato che afferma di essere valido per il sito di destinazione.
-
Una volta stabilita la connessione SSL tra il proxy e il browser (che pensa di parlare al sito di destinazione), il proxy crea la propria connessione SSL al sito di destinazione.
-
Il proxy riceve quindi la richiesta HTTP su SSL dal browser, la filtra e la inoltra al sito di destinazione. Quindi fa lo stesso con la risposta dal sito di destinazione al browser.
Naturalmente, poiché il certificato inviato dal proxy al browser nel passaggio 1 non è effettivamente valido per il sito di destinazione, e in particolare non è stato firmato da una CA attendibile, il browser normalmente interromperà la connessione e mostrerà all'utente un grosso avviso su un certificato non sicuro.
Il trucco, tuttavia, è che tu, come amministratore di rete, devi aggiungere il certificato di firma del proxy nell'elenco dei certificati di root attendibili del browser. In questo modo, il browser, infatti, si fida dei certificati falsi restituiti dal proxy.
Ovviamente, l'utente può rimuovere il certificato del proxy dall'elenco di fiducia del browser o semplicemente utilizzare il proprio browser che non è configurato per fidarsi del proxy. Ma questo significa solo che riceveranno un avviso di sicurezza e non potranno connettersi ai siti HTTPS; non li aiuterà a bypassare effettivamente il proxy.
Tutto ciò che ho detto, vorrei seriamente consigliarti di pensare attentamente prima di utilizzare tali trucchi per minare l'infrastruttura di sicurezza SSL, e farlo solo se ritieni che sia assolutamente necessario. Anche in questo caso, consiglierei di applicarlo solo su alcuni siti specifici che si desidera filtrare e di lasciare connessioni HTTPS ad altri siti. I tuoi utenti potrebbero non preoccuparsi che tu stia spiando le loro ricerche Google - ma loro non non vogliono che tu spuli il loro banking online, per esempio.
D'altra parte, se il tuo software di filtro viene eseguito sul computer dell'utente, ad es. come estensione del browser, quindi non dovrebbe avere problemi a filtrare le richieste HTTPS con la stessa semplicità del semplice HTTP; inserendosi tra l'interfaccia utente del browser e il back-end di rete, può riscrivere le richieste HTTPS prima che sono crittografate.
(Questo è, ad esempio, come funziona il plug-in HTTPS Everywhere per Firefox: intercetta richieste HTTP e riscrive in richieste HTTPS, a volte modificando gli URL anche in altri modi. Non c'è motivo per cui questo non funzionerebbe altrettanto bene anche nella direzione opposta.)
Tuttavia, ci sono due problemi con questo approccio. Il primo è che i diversi browser hanno API di estensione diverse, e non tutte sono ugualmente convenienti per tale riscrittura delle richieste. (Ad esempio, l'API di estensione di Chrome è apparentemente particolarmente inadeguata per questo, a causa del suo design asincrono.)
Il secondo problema è semplicemente che c'è un modo semplice per aggirare un filtro implementato in questo modo: basta installare un browser che il filtro non supporta. Pertanto, tale filtraggio non sarà molto efficace se non associato ad altre restrizioni per prevenire tali soluzioni.