Obtener información encriptada en un proxy MITM

El error no está en el protocolo, está en personas . O, podría decirse, en las herramientas , quién debe manejar los asuntos que son demasiado técnicos para que los usuarios humanos puedan hacerlo correctamente.

El protocolo SSL indica cómo van las cosas y que la conexión será segura, especialmente contra Man-in-the-Middle attack :

-  The negotiation of a shared secret is secure: the negotiated
   secret is unavailable to eavesdroppers, and for any authenticated
   connection the secret cannot be obtained, even by an attacker who
   can place himself in the middle of the connection.

Pero esto se mantiene solo si el protocolo realmente se sigue en toda su extensión y, en particular, si la validación de la clave pública del servidor no es un "acceso directo".

Por lo tanto, no hay nada que cambiar en el protocolo . Cuando las herramientas no implementan el protocolo correctamente, el error suele estar en las herramientas, no en el protocolo.

Podríamos argumentar que si los navegadores aún permiten omitir la advertencia de "certificado incorrecto" (aunque esa advertencia ha aumentado en el tono rojizo con el paso del tiempo), esto podría ser una indicación de que las suposiciones del protocolo no son realistas. Es decir, requerir que todos los servidores web tengan un certificado SSL que los navegadores de los clientes puedan validar puede ser demasiado pedir. Pero, honestamente, la seguridad tiene que comenzar en algún lugar . La criptografía no crea confianza, transfiere confianza . No puede tener un protocolo que garantice que el cliente siempre hable con el servidor "correcto" sin tener, al menos, una noción definida de lo que significa "correcto" en ese contexto.

Si el phishing o los ataques MitM con un certificado de servidor falso, que el usuario hizo clic en ellos, se vuelven demasiado frecuentes, espero que los proveedores de navegadores eliminen la omisión por completo y apliquen la validación estricta de X.509. Lo veremos en unos años.

MitM puede ocurrir de varias maneras. En el escenario del que está hablando, está describiendo dónde MitM está realizando dos conexiones, una al cliente y otra al servidor. Él no está descifrando o rompiendo TLS. La advertencia de certificado le permite saber que la información no proviene directamente del servidor.

Al mismo tiempo, si uno conoce las claves de cifrado o puede aprenderlas más tarde y ha guardado el tráfico, puede descifrar el mensaje. Si puede imitar completamente al remitente en tiempo real, simplemente puede descifrar el tráfico, generar nuevo tráfico y volver a cifrarlo como si fuera el remitente legítimo. El objetivo de MitM puede ser escuchar a escondidas o manipular.

En los entornos corporativos, los administradores de sistemas a menudo pueden "romper" el TLS u otro cifrado porque controlan las PC cliente y pueden instalar los certificados adecuados en el cliente para que confíen en el firewall corporativo de descifrado TLS / SIEM / etc. En este caso, el usuario final en el cliente no sabría que su tráfico está siendo descifrado.

El descuido y la manipulación de datos también se pueden realizar no en la red, sino en el remitente o el receptor utilizando malware o técnicas de "hombre en el navegador".

A menos que use un sistema honeypot / honeynet para inyectar tráfico falso o use un cifrado deficiente, no estoy seguro de cómo se podría hacer que el atacante crea que tuvo éxito cuando realmente no lo hizo. Tendrán datos de basura o tendrán datos que pueden procesar. Por ejemplo, con HTTPs, o lo descifras y tienes algo que es inteligible para un humano y una pieza de software, o tienes errores que no se pueden procesar. Si bien es posible, es muy poco probable que el mensaje cifrado se descifre en un formato que parezca inteligible, pero que no sea cierto sin conocer el sistema real.

Si sabe qué claves ya tiene el atacante y las técnicas que están usando, es posible inyectar tráfico en la red que podrían interceptar y descifrar para pensar que recibieron el mensaje, pero probablemente se pregunten sobre Todos los demás tráficos no se están descifrando y están usando claves diferentes.

El usuario es siempre el enlace más débil. Si tiene el mejor protocolo, el más increíblemente seguro, pero el atacante convence al usuario de que les envíe un cheque, no significa que haya un problema con el protocolo, sino que hay un problema con los usuarios. El usuario debe obtener información de algún lugar para decirle que el servidor es quien dice ser o no tiene forma de confiar en la conexión. SSL hace lo mejor para advertir al usuario que no confíe en la conexión, pero sigue dando la opción. En teoría, un cliente simplemente podría no permitir que el usuario acepte un certificado que no sea de confianza, pero esto frustraría al usuario al intentar otros medios como usar una conexión que no sea https.

No hay una forma mágica para que usted pueda descubrir información sobre el servidor legítimo (a menos que tenga conocimiento previo) que no pueda ser atacada por un hombre en el medio, cambiando la información que dice ser el servidor legítimo. Es por esto que los sistemas más seguros requieren el manejo físico de claves de conocimiento previo que se transportan bajo vigilancia armada. El establecimiento inicial de la confianza es el talón de Aquiles de la comunicación de confianza. Si el usuario elige activamente confiar en las personas equivocadas, ese es su problema, no un problema que pueda resolverse mediante medidas tecnológicas.

En cuanto a algo en el que el atacante podría pensar que tuvo éxito, pero en realidad no lo hizo, está hablando del reino del cifrado deniable allí y sería bastante difícil o imposible hacerlo con un cifrado de flujo debido a la forma en que los datos está almacenado. Necesitaría datos que podrían ser descifrados con 2 claves diferentes y que un descifrado daría el resultado real, mientras que el otro da algo falso.

Sin embargo, el problema es doble cuando se intenta aplicar esto a un cifrado de flujo. Primero, tiene una relación general de 1 a 1 entre el texto cifrado y el texto plano. El cifrado más denegable requiere un volumen mucho mayor de datos, algunos de los cuales parecen ser basura (pero en realidad es una señal para la otra clave). Como se esperaría una relación de 1 a 1, el exceso de datos arrojaría indicadores.

El segundo problema es la divulgación clave. Las fuertes medidas de protección contra MITM requieren que el intercambio de claves esté protegido. La mayoría de los ataques MITM, por lo tanto, atacan el intercambio de claves y evitan el intercambio de claves con el servidor deseado real. Por lo tanto, no habría una manera de darle al servidor real la clave correcta mientras le da al MITM la clave de desvío.