En lugar de "pasar por alto" el cifrado, pueden falsificar la identidad del servidor para realizar un ataque MITM (de manera efectiva).
El cifrado en sí mismo es solo una parte de la configuración al configurar una conexión SSL / TLS: esto garantiza la confidencialidad de la comunicación entre el cliente y el servidor. Antes de eso, el cliente debe verificar la identidad del servidor para asegurarse de que está intercambiando datos de forma confidencial con la parte que espera: para eso se usan los certificados.
Un CA emite un certificado X.509 para un nombre de servidor dado. Si el navegador confía en esta CA (hay una serie de anclajes de confianza proporcionados de forma predeterminada en la mayoría de los navegadores), puede confiar en su contenido: el enlace entre su clave pública y el nombre que contiene. El navegador también debe verificar que el nombre del servidor que estaba buscando es uno de los nombres en el certificado.
Lo que el gobierno puede hacer es pedirle que confíe en su certificado de CA (y / o que las grandes CA les otorguen un certificado de CA intermedio) para que puedan emitir certificados para su dispositivo de vigilancia, falsificando así el certificado del servidor real. Este dispositivo sería un servidor y descifraría la conexión y luego actuaría como un cliente para el servidor real: entonces tendría 2 secciones cifradas: una entre el cliente y el dispositivo de vigilancia, y otra entre ese dispositivo y el servidor real.
Existen dispositivos que hacen esto (a veces denominados "servidores proxy MITM"), que se utilizan normalmente en una red empresarial.
Además del hecho de que cualquier persona que tenga el control de la clave privada de esa CA podría ver y alterar cualquier tráfico que el cliente haga a un sitio HTTPS (aquí hay una serie de problemas no técnicos), hay una serie de problemas técnicos al hacer esto a escala de un país:
Es posible que estos servidores proxy deban configurarse explícitamente en el navegador (como un proxy HTTP).
De hecho, es bastante difícil implementar un proxy MITM de manera transparente, ya que no siempre puede obtener el nombre que debe colocar en el certificado que genera dinámicamente con solo mirar los paquetes TCP iniciales. Si no se usa la Indicación del nombre del servidor (SNI es bastante común en la actualidad, pero no es compatible con todos los clientes), todo lo que puede obtener es la dirección IP del servidor, que no necesariamente se resuelve al nombre esperado. Por ejemplo, si obtiene la dirección para www.facebook.com y realiza una búsqueda DNS inversa, obtendrá algo como www-XYZ-XYZ.facebook.com . Podría funcionar con un comodín aquí, pero ese patrón no se puede esperar en general.
Esto hará que cualquier servicio que use la autenticación del certificado de cliente se rompa. Dado que durante el protocolo de enlace SSL / TLS, cuando se utiliza un certificado de cliente, el cliente firma la concatenación de todos los mensajes de protocolo de enlace (incluido el certificado del servidor) al final, y el servidor lo compara con lo que ha enviado y recibido (incluido el certificado real). Si hay algo en el medio que inserta su propio certificado, esto hará que la verificación falle.
Sin duda habrá un retraso en el establecimiento del protocolo de enlace, ya que los certificados pueden generarse de forma dinámica. (Algunos se pueden almacenar en caché).
Esto espera que los usuarios "jueguen bien" y usen los puertos que deben hacer. Es posible que los puertos alternativos no se monitoreen o que tengan un firewall completo.
Para rastrear los intercambios de Facebook / Google + / Gmail en una forma utilizable, estos dispositivos también deberán poder revisar la estructura de las páginas (o la carga útil de JSON para AJAX) y poder extraer la información relevante. Datos (o para almacenar todo lo que no pueda entender en algún lugar). Cualquier cambio leve en la API interna de esos servicios requeriría una adaptación costosa.
Todo esto para todas las comunicaciones HTTPS requerirá una gran cantidad de potencia de cómputo y generará una factura de electricidad sustancial.
(Por cierto, es posible que los informes que llevaron a la Home Office a realizar dichos planes se redactaron antes de que Facebook cambiara a HTTPS para todo)
Obtendrán una CA que se encuentra en la zona raíz de CA para que todos los navegadores emitan certificados válidos. Esta CA probablemente será una empresa con sede en el Reino Unido. El espionaje será completamente transparente para los usuarios. Los navegadores no mostrarán advertencias. Esto funcionará durante unos días, hasta que sea detectado por el público, momento en el que los proveedores del navegador revocarán el certificado raíz de la CA en cuestión, como lo hicieron en el pasado debido a problemas de seguridad en algunas CA. No hay otra forma práctica de descifrar las conexiones cifradas, a menos que si alguien está usando protocolos de una semana, pero eso es poco probable. También podrían instalar estas cajas y luego usarlas de forma selectiva, solo dirigirse a las personas que desean espiar, no a todas. En este caso, probablemente no será detectado y el certificado de CA no será rechazado. Pero no puede monitorear y descifrar todo el tráfico de Internet seguro y no ser observado.
Lea otras preguntas en las etiquetas privacy encryption tls man-in-the-middle confidentiality