¿Por qué Cloudflare es un ataque MITM? [cerrado]

Lamentablemente, no puedes contrarrestarlo sin ser técnicamente incorrecto.

Según Wikipedia, la definición de ataque del hombre en el medio :

  

"En criptografía y seguridad informática, un ataque de hombre en el medio (MITM) es un ataque en el que el atacante retransmite secretamente y posiblemente altera la comunicación entre dos partes que creen que se están comunicando directamente entre sí". / p>

Los propietarios de sitios web que configuran su sitio para usar Cloudflare no creen que se estén comunicando directamente con los visitantes, por lo que, según la definición técnica, no es un ataque MitM.

Cloudflare es contratado y pagado por el propietario del sitio para realizar el servicio que está haciendo Cloudflare. Por lo tanto, por definición, Cloudflare es parte de la red de proveedores de servicios del propietario del sitio, y mientras Cloudflare esté brindando los servicios especificados en el contrato, no es un atacante y el servicio proporcionado no es un ataque.

Decir que Cloudflare es un MitM es análogo a decir que eBay / Amazon son MitM entre usted y los vendedores. Pedir a los navegadores que bloqueen Cloudflare es como pedirle a los navegadores que bloqueen eBay / Amazon porque no le gustan los términos y condiciones de ese mercado.

Lo que están haciendo los proveedores de CDN como Cloudflare es en realidad mucho mejor que la situación antes de que aparecieran los proveedores de Cloudflare y CDN. Antes de que CDN se convierta en un lugar común, muchos ISP implementan un proxy de almacenamiento en caché entre usted y el proveedor de contenido (en realidad esto todavía es común en países con infraestructura de Internet menos desarrollada). En muchos casos, el ISP modificaría la página que están viendo los usuarios, generalmente inyectando sus propios anuncios en la página y posiblemente escaneando el sitio para averiguar qué anuncios servir. Los términos y condiciones para este "servicio" generalmente se ocultan efectivamente al usuario y casi nunca se le llama la atención cuando el usuario se registra en su servicio de Internet. La mayoría de los usuarios nunca se darían cuenta de que su ISP está haciendo esto y, por lo general, no hay forma de controlar qué sitios o parte de la página deben almacenarse en caché y cuáles deben servirse directamente.

Cuando llegó el CDN, las tablas están cambiadas. En lugar de trabajar para el ISP del usuario, ahora el proxy de almacenamiento en caché está trabajando para el proveedor de contenido. El proveedor de contenido opta explícitamente por usar Cloudflare en lugar de ser forzado por su proveedor de Internet. Y dado que los proveedores de contenido conocen mejor su contenido, tienen control sobre qué parte de su sitio puede usar el caché compartido y qué parte de la página debe usar la conexión directa. El único inconveniente efectivo es que con CDN, los términos y condiciones para el servicio de almacenamiento en caché ahora son aceptados por el proveedor de contenido, en lugar del usuario.

Los proveedores de contenido preocupados por la seguridad que desean usar una CDN normalmente tendrían dos servidores, uno de ellos con contenido masivo y público a través de la CDN, y un servidor estático seguro que brinda información sensible a la seguridad. Si su proveedor de contenido no realiza dicha separación y proporciona información personal de servicio confidencial utilizando un proveedor de servicio que no es adecuado para el propósito, debe culpar a su proveedor de contenido, no al proveedor de servicio, ya que es responsabilidad del proveedor de contenido proteger su información personal. los datos y es la opción del proveedor de contenido utilizar Cloudflare.

Si el navegador principal comienza a bloquear a los principales proveedores de CDN de forma predeterminada, es probable que muchos propietarios de sitios eliminen HTTPS para permitir que los ISP almacenen en caché su contenido. No vamos a volver a un mundo con HTTPS ubicuos y sin CDN.

(A continuación, me refiero al protocolo de seguridad de la capa de transporte anteriormente conocido como SSL como "TLS", porque todas las versiones del SSL original ya no son seguras y no deben utilizarse).

El problema es que quien haya presentado el informe de Bugzilla tiene una agenda en mente: cualquier cosa menos que una cadena ininterrumpida de bondad TLS de extremo a extremo es un ataque MITM y, por lo tanto, es temible. Mozilla ha señalado en su respuesta a este informe que Cloudflare es una CDN (Red de entrega de contenido), lo que significa que tienen que hacer lo que están haciendo con TLS para hacer lo que su cliente les está pagando.

Troy Hunt (el autor y mantenedor de "Have I Have Pwned?") explica en la siguiente publicación del blog que la alternativa a Cloudflare en muchos casos es operar con ningún cifrado de capa de transporte en absoluto (porque el proveedor de servicios en el origen no puede manejarlo): enlace

Esa página también explica cómo, TLS o no TLS, los actores a nivel nacional pueden tener acceso a tus cosas. No debe utilizar CloudFlare para cualquier cosa que sea tan sensible que la interceptación de los datos sea peligrosa para su salud.

HTTPS proporciona cifrado de extremo a extremo de su tráfico entre su navegador y el servidor que posee la clave privada correspondiente al certificado TLS.

Cuando vas a un sitio web de HTTPS en el CDN de cloudflare, cloudflare tiene la clave privada del certificado presentado en tu navegador (y es bastante obvio que es cloudflare; por ejemplo, el nombre común del certificado suele ser algo así como sni241623.cloudflaressl.com con un más o menos una docena de Nombres alternativos de sujeto para los sitios que sirve) O puede ejecutar un whois en la dirección IP correspondiente al nombre de dominio que está visitando; Usted encontrará que es propiedad de cloudflare.

Nota: para que un sitio use cloudflare, el propietario debe apuntar sus registros DNS a los servidores de cloudflare, momento en el que efectivamente le entregaron a cloudflare el control total de su sitio web (siempre que los registros DNS apunten a los servidores de cloudflare). Pueden demostrar el control de un dominio a las autoridades de certificación que emitirán certificados para su dominio a cloudflare.

Ahora cloudflare tiene el control para espiar y registrar las interacciones de los usuarios con su sitio web o manipular el contenido de forma silenciosa si lo desean.

Sin embargo, esto no es un ataque Man-in-the-Middle, porque el propietario del sitio web le dio permiso a Cloudflare para hacer todo esto. Entonces, no es un ataque, es una conexión segura a cloudflare (a quien el propietario del sitio web le dio permiso para publicar contenido en su nombre de dominio).

No es diferente a una empresa que subcontrata su sitio web a un tercero que diseña y aloja el sitio web. Hay un tercero que podría hacer cosas nefastas, pero recibió el permiso completo del propietario correspondiente.

O es como la cantidad de sitios web que se ejecutan en hosts compartidos o compran servidores privados virtuales, donde los administradores de la empresa de alojamiento pueden obtener todos los datos de su servidor si lo desean. Si algún administrador en su host de VPS con acceso de raíz a los servidores realmente quisiera las claves privadas para su servidor web en ejecución, pueden obtenerlas. (Tenga en cuenta que el cifrado completo del disco dentro de su máquina virtual puede ser evitado, ya que controlan el hardware del host y pueden leer la memoria de su máquina virtual). Pero nuevamente, las personas que usan hosts / VPS compartidos confían en que las compañías sean de buena reputación.

Al final, eso es todo lo que tienes. Debe confiar en que la organización que administra el sitio web en el otro extremo es confiable con los datos que usted les proporciona al navegar allí. Al visitar sitios web en la nube, la parte de CDN de la confianza está en cloudflare.

(Esto contrasta con los ataques MitM reales, donde algunos intermediarios atacantes que no tienen escuchas de acceso autorizadas y / o manipulan el tráfico de la red).