El título básicamente lo cubre. Quiero saber si el uso de HTTPS, TLS, S / MIME, SSL lo protegerá de Deep Packet Inspection y Big Data Analytics. (Sé que si alguien falsifica un certificado o hace que instales una CA falsa o el uso del software MITM pueden engañar al usuario promedio, quiero saber si una persona semi-diligente de seguridad de TI semi-diligente está segura usando esas tecnologías para cifrar los datos y conexiones)
Inspección profunda de paquetes (DPI) es un término que comúnmente se refiere a intermediarios de red estándar, como los enrutadores en un ISP, que examinan el contenido en una capa de protocolo más alta que la capa que necesitan para procesar el paquete ( inspeccionando así "más profundo" en el paquete de lo necesario). Por ejemplo, un enrutador IP puede necesitar solo mirar la capa IP (capa 3 en el modelo OSI) del paquete, pero si también inspecciona los datos de la capa de aplicación (capa 5/7), entonces está realizando una inspección profunda de paquetes.
HTTPS (en referencia a la amplia suite que mencionó) es un protocolo de capa de aplicación. Se defenderá contra la inspección profunda de paquetes que lee el contenido de la capa de aplicación, pero no contra DPI en niveles más bajos de la envoltura de protocolo. Por ejemplo, HTTPS no evitará que DPI vea el paquete TCP y examine el puerto de destino para adivinar para qué protocolo está. Pero evitará que el DPI aprenda la carga útil de datos de la aplicación real del protocolo.
El análisis de Big Data se refiere al análisis realizado en bases de datos muy grandes de datos recopilados, pero la forma en que se recopilan esos datos tiene poco que ver con el HTTPS. HTTPS solo está diseñado para proteger los datos en tránsito de red, cuando el servidor de destino en el protocolo HTTPS lee datos, los datos se descifran y ya no existe la protección HTTPS. Lo que sucede en ese punto depende de lo que el cliente y el servidor estén usando sobre HTTPS. Probablemente, el servidor puede hacer prácticamente lo que quiera en ese momento. (En otras palabras, Big Data generalmente se refiere a Data At Rest, mientras que HTTPS protege Data In Motion. Dado que tratan diferentes etapas de los datos, tiene sentido que la protección en una etapa no se aplique a los datos cuando se transfiere a una etapa diferente.)
¿El transporte de cifrado de capa (SSL / TLS / https) le impedirá realizar Big Data Analytics?
Depende. ¿El servidor en el otro extremo usa sus datos para el análisis de big data? Si no lo hacen, estás a salvo de los análisis de datos grandes. Si utiliza google / facebook / amazon, etc., ellos están analizando sus datos (y posiblemente compartiendo información con otras entidades (como el gobierno de EE. UU. / NSA)), están haciendo análisis de big data sobre la información que les proporcionó.
TLS (y SSL es solo una versión antigua de eso; y HTTPS es solo HTTP + SSL / TLS) solo limita a los interceptores de la red a saber solo cuando , a quien ( Dirección IP) y la cantidad de datos que está enviando y recibiendo. (Esto supone que no han comprometido una CA o los certificados de confianza de sus navegadores para un ataque sofisticado). Esta información limitada a veces es muy útil en ataques de canal lateral para deducir qué información privada está enviando ( especialmente si hay características de autocompletar de ajax como la sugerencia de google)
Sin embargo, en general, el cifrado de transporte solo permite que su computadora y los servidores https en el otro extremo de la conexión vean sus datos; aunque cada computadora es libre de compartir esos datos con los adversarios para analizar.
Para que quede claro, sí, el cifrado de la capa de transporte evita que su ISP / otra red escuche a escondidas desde Deep Packet Inspection; con la excepción de ver cuándo, quién y cuántos datos cifrados está enviando / recibiendo. Si está paranoico con respecto a esta información limitada, puede hacer un proxy de todo su tráfico a través de un túnel / VPN / tor cifrado para ocultar qué sitios web / máquinas está visitando, de modo que el ISP solo puede descubrir la cantidad de datos que está enviando a su proxy. en cualquier momento dado. (Concedido, el ISP del servidor proxy podría escuchar a escondidas qué sitios son visitados por sus servidores proxy y qué computadoras están conectadas al servidor proxy).
SonicWALL DPI-SSL se usa principalmente en una red administrada donde los administradores pueden controlar una Autoridad de certificación raíz y, por lo tanto, obligan a los clientes a confiar en el certificado firmado por SonicWALL en el medio.
Un ejemplo de esto sería una Escuela filtrando / forzando la búsqueda segura en Goolge (ya que ahora usa https como predeterminado) - sin este desglose de paquetes "man in the middle" el usuario podría ver todo lo que quisieran y solo se informaría como enlace .
En términos simples, el cliente realiza una solicitud a enlace en su navegador: el SonicWALL (como dispositivo Edge) luego hace esta solicitud a Google en su nombre. (por lo tanto, creando la conexión segura entre Google - > SonicWALL) - SonicWALL luego vuelve a firmar el tráfico y lo dirige al dispositivo interno correcto.
Esto solo se puede hacer si el Administrador de red tiene acceso a la infraestructura de clave pública o si se ha dicho a las estaciones de trabajo que confíen en el certificado autofirmado de sonicwallCA.
En términos reales, puede verificarlo haciendo clic en el candado de su navegador y verificando si se trata de un tercero de confianza o de su compañía local. Este ataque sería MUY difícil si no está a cargo de la infraestructura de una red.
En realidad, hay una sorprendente cantidad de datos que pueden filtrarse a través de una conexión HTTPS típica.
Si el servidor y el cliente TLS están actualizados, entonces los datos están cifrados y son seguros, pero los tamaños, tiempos y cantidad de paquetes y mensajes TLS dentro de los paquetes contienen información interesante. Considere el Bicycle Attack ; el orden y la longitud aproximada de los encabezados devueltos por el servidor web pueden verse en el flujo cifrado.
Los atacantes observadores, incluidos los DPI que inspeccionan los firewalls, incluido el Gran Firewall, pueden crear sus propias conexiones con el servidor web de destino para obtener el contenido cifrado que no es exclusivo de un usuario.
Por ejemplo, cualquier persona puede ver la página de inicio de sesión del sitio, incluso si tiene TLS, porque tiene que mostrarlo a usuarios no autenticados.
Las páginas que responden a los eventos del usuario enviando datos a un servidor, como la función de búsqueda según tipo de google, pueden exponer la tasa de escritura o los patrones del usuario, que pueden servir para identificarlos.
Y, por supuesto, ... La información de DNS y proxy suele estar fuera de la capa HTTPS y puede exponer los sitios y los clientes utilizados.
Lea otras preguntas en las etiquetas tls