'Black boxes' will be installed by internet services providers to filter & decode encrypted materials – including social media and email messages, something which critics say will have an impact on personal privacy.
Invece di "bypassare" la crittografia, possono falsificare l'identità del server, in modo da eseguire un attacco MITM (efficacemente).
La crittografia stessa è solo una parte della configurazione quando si imposta una connessione SSL / TLS: ciò garantisce la riservatezza della comunicazione tra il client e il server. Prima di questo, il client deve verificare l'identità del server, per assicurarsi che stia scambiando i dati in modo confidenziale con la parte che si aspetta: questo è ciò per cui vengono utilizzati i certificati.
Un certificato X.509 viene emesso da una CA per un determinato nome di server. Se il browser considera attendibile questa CA (ci sono un certo numero di ancore di trust fornite di default con la maggior parte dei browser), può fidarsi del suo contenuto: l'associazione tra la sua chiave pubblica e il nome che contiene. Il browser deve anche verificare che il nome del server che stava cercando sia uno dei nomi nel certificato.
Ciò che il governo può fare è chiedervi di fidarsi del suo certificato CA (e / o fare in modo che le grandi CA forniscano loro un certificato CA intermedio) in modo che possano emettere certificati per il loro dispositivo di sorveglianza, falsificando così il vero certificato del server. Questo dispositivo sarebbe un server e decifrerebbe la connessione e quindi agirà da client stesso verso il server reale: si avranno quindi 2 sezioni crittografate: una tra il client e il dispositivo di sorveglianza e una tra quel dispositivo e il server reale.
Esistono appliance che fanno questo (a volte indicato come "server proxy MITM"), tipicamente utilizzato su una rete aziendale.
Oltre al fatto che chiunque abbia il controllo della chiave privata di quella CA può vedere e modificare il traffico che il cliente effettua su un sito HTTPS (ci sono una serie di problemi non tecnici qui), ci sono una serie di problemi tecnici quando si fa questo alla scala di un paese:
Potrebbe essere necessario configurare esplicitamente questi server proxy nel browser (come proxy HTTP).
In effetti, è abbastanza difficile implementare un proxy MITM in modo trasparente, perché non sempre è in grado di ottenere il nome da inserire nel certificato che genera dinamicamente, semplicemente guardando i pacchetti TCP iniziali. Se l'indicazione del nome del server non è usata (SNI è abbastanza comune al giorno d'oggi, ma non è supportato da tutti i client), tutto ciò che può ottenere è l'indirizzo IP del server, che potrebbe non risolversi necessariamente nel nome previsto. Ad esempio, se ottieni l'indirizzo per www.facebook.com e esegui una ricerca DNS inversa, otterrai qualcosa come www-XYZ-XYZ.facebook.com . Potrebbe funzionare con un carattere jolly qui, ma questo modello non può essere previsto in generale.
Questo farà sì che qualsiasi servizio che utilizza l'autenticazione del certificato client si interrompa. Poiché durante l'handshake SSL / TLS, quando viene utilizzato un certificato client, il client firma la concatenazione di tutti i messaggi di handshake (incluso il certificato del server) alla fine e il server lo confronta con ciò che ha inviato e ricevuto (incluso il certificato reale). Se c'è qualcosa nel mezzo che inserisce il proprio certificato, questo farà fallire questa verifica.
Ci sarà certamente un ritardo nella creazione dell'handshake, dal momento che i certificati potrebbero dover essere generati dinamicamente. (Alcuni potrebbero essere memorizzati nella cache.)
Ciò si aspetta che gli utenti "giochino bene" e usino le porte che devono fare. Le porte alternative potrebbero non essere monitorate o dovrebbero essere completamente firewall.
Per rintracciare gli scambi di Facebook / Google + / Gmail in una forma utilizzabile, questi dispositivi dovranno anche essere in grado di esaminare la struttura delle pagine (o il payload JSON per AJAX) ed essere in grado di estrarre il relativo dati (o per memorizzare tutto ciò che non può capire da qualche parte). Qualsiasi lieve modifica nell'API interna di tali servizi richiederebbe un costoso adeguamento.
Fare tutto questo per tutte le comunicazioni HTTPS richiederà sicuramente una grande quantità di potenza di elaborazione e produrrà una bolletta elettrica sostanziale.
(È possibile che i report che hanno portato l'Home Office a elaborare tali piani siano stati redatti prima che Facebook passasse a HTTPS per tutto, a proposito.)
Otterranno una CA che si trova nella zona radice della CA per tutti i browser per rilasciare loro certificati validi. Questa CA sarà probabilmente una società con sede nel Regno Unito. Spiare sarà completamente trasparente per gli utenti. I browser non mostreranno avvisi. Ciò funzionerà per alcuni giorni, fino a quando non verrà rilevato dal pubblico in quel momento i fornitori di browser revocheranno il certificato radice della CA in questione, come in passato a causa di problemi di sicurezza in alcune CA. Non esiste un altro modo pratico per decifrare le connessioni crittografate, a meno che non si stia utilizzando un protocollo di una settimana, ma è improbabile. Potrebbero anche solo installare queste scatole e quindi usarle in modo selettivo, solo targetizzare le persone che desiderano spiare, non tutti. In questo caso, probabilmente non verrà rilevato e il certificato CA non verrà rifiutato. Ma non è possibile monitorare e decrittografare tutto il traffico Internet sicuro e non essere notato.
Leggi altre domande sui tag encryption privacy tls man-in-the-middle confidentiality