Artículo original de Hugo Landau, publicado el 23 de octubre de 2019
Los sitios web deberían evitar usar Cloudflare.
El servicio de frontal HTTP de Cloudflare incorpora prácticas seriamente cuestionables. Tal como están las cosas, la extensión del número de sitios web que han llegado a usar Cloudflare, multiplicada por sus problemas, representa un peligro para el estado de la web.
Cloudflare, tal como se anuncia a los operadores de sitios, no identifica estos problemas, y los operadores incluso podrían no ser conscientes de ellos.
Si un sitio web usa Cloudflare, lo más probable y por defecto es que esto resulte en que el sitio web se vuelva estocásticamente defectuoso.
Un sitio web es un servicio de procesamiento de solicitudes HTTP. La adopción de Cloudflare hace que dichos servicios se vuelvan poco fiables y provoca condiciones de denegación de servicio para los usuarios, de una manera esencialmente aleatoria e inaccountable.
Cuando ocurren dichas condiciones de denegación de servicio, Cloudflare proporciona una extraña página de “un paso más” que invita al visitante a completar un reCAPTCHA para acceder al sitio. Cloudflare afirma que esto se basa en la reputación de la IP, lo que constituye una equivocación falaz entre IPs y usuarios que se ha demostrado altamente perjudicial para los usuarios de Tor en términos de la navegabilidad de la web.
Esto ni siquiera funciona si el usuario tiene las cookies desactivadas, o si el usuario usa un navegador que no soporta iframes, como lynx.
El código de estado HTTP para esta página es 403 Forbidden. Esencialmente, Cloudflare por diseño perpetra aleatoriamente ataques de denegación de servicio contra usuarios, pero al mismo tiempo Cloudflare paradójicamente se anuncia a sí mismo como un servicio para mitigar ataques DoS.
Cloudflare afirma que estas medidas son necesarias para contrarrestar el abuso. Esta afirmación es dudosa porque es un modelo de operación para una CDN que parece tener pocos o ningún imitador. En otras palabras, otras CDN no parecen tener ningún problema implementando HTTP correctamente mientras proporcionan medidas anti-DDoS, sin recurrir a prácticas como demandas aleatorias de que los usuarios completen CAPTCHAs.
La demanda aleatoria de Cloudflare de que los usuarios completen CAPTCHAs discrimina contra usuarios que no son humanos, por diseño. Esto constituye un peligro para la rastreabilidad de la web. No está claro qué recurso está disponible para las organizaciones que rastrean la web y que se encuentran impedidas por las acciones de Cloudflare. Incluso si Cloudflare pusiera en lista blanca a estas organizaciones, esto esencialmente convierte a Cloudflare en una autoridad sobre la legitimidad de un motor de búsqueda; lo cual, dada la magnitud de la base de usuarios de Cloudflare, es profundamente preocupante.
No hay base en el estándar HTTP para exigir que los usuarios o sus agentes de usuario completen CAPTCHAs para cargar una página, y las demandas de CAPTCHA emitidas por Cloudflare no se comunican de ninguna manera estándar. El código de estado ‘403 Forbidden’ usado para estas páginas podría expresar prohibiciones arbitrarias de política, como denegación no negociable de acceso. Cloudflare exige no solo un usuario humano (pero no consistentemente; solo si decide aleatoriamente hacerlo), sino que tampoco comunica de manera inequívoca y legible por máquina cuándo este es el caso, lo cual es discriminatorio para los robots, muchos de los cuales son legítimos.
Más absurdamente, si quieres proporcionar una API sobre Cloudflare tienes que eximir tus endpoints de API para que esto no ocurra, lo que plantea la pregunta de cuál es el punto en primer lugar si tienes que hacer agujeros en él, y básicamente prueba el punto.
La inexplicable incapacidad de Cloudflare para implementar HTTP de una manera sana y transparente, a pesar de que esta incapacidad parece no ser compartida por ningún otro servicio CDN existente, se volvió aún más ridícula cuando Cloudflare se puso en contacto con el proyecto Tor para solicitar que hicieran cambios en Tor para acomodar sus propias prácticas problemáticas.
En su enlace con Tor, Cloudflare afirma que su razonamiento para sus CAPTCHAs no es la mitigación de DDoS, sino lo siguiente:
Uno pensaría que este último punto podría hacer que Cloudflare se diera cuenta de que intentar detener el spam de comentarios a nivel de CDN es una idea fútil y solo puede resultar en romper HTTP, pero no. Lo que Cloudflare está intentando hacer aquí es una práctica fundamentalmente rota (de hecho, toda la premisa de los “firewalls de aplicaciones web” está fundamentalmente rota, ver más abajo) porque Cloudflare no está en posición de entender el significado semántico del tráfico HTTP y definitivamente no está en posición de rearquitectar la aplicación web de un operador de sitio para que entienda por qué sus propias solicitudes AJAX están siendo denegadas aleatoriamente.
En otras palabras, dado que los CAPTCHAs son discriminatorios para los robots como se discutió anteriormente, el servicio de Cloudflare es involuntariamente discriminatorio para el JavaScript de los mismos sitios web que sirve, rompiéndolos. La respuesta de Cloudflare a esto parece ser poner CAPTCHA a todo el sitio web por adelantado por si acaso alguien quisiera publicar un comentario, aunque incluso esto no siempre funciona; definitivamente he encontrado sitios web que no lo hicieron y que tenían funcionalidad AJAX rota debido a que las solicitudes posteriores activadas por AJAX fueron denegadas por Cloudflare, una condición para la cual el código JS no fue diseñado para manejar (ni habría ninguna manera sana de que lo manejara de todos modos).
Ser un servicio de filtrado de spam de comentarios no es lo único que Cloudflare intenta hacer además de ser una CDN. También afirman usar sus CAPTCHAs para mitigar otro tráfico “abusivo”, como “recopilar direcciones de correo electrónico”.
lunar: […] ¿Podrían decirnos qué califica como abuso?
jgrahamc: Abuso: spam de comentarios, recopilación de direcciones de correo electrónico, atacar aplicaciones web (p. ej., inyección SQL), DoS HTTP (explotar servidores/aplicaciones web lentas para dejarlas fuera de línea). No me interesan los DoS L3/L4 y Tor ya que son inexistentes (a menos que el nodo de salida sea separadamente parte de una botnet).
Esta es una práctica fundamentalmente rota. Intentar filtrar inyecciones SQL a nivel de CDN es un ejercicio de inutilidad y teatro de seguridad. Esta es la idea del “Firewall de Aplicaciones Web”, la absurda idea de que hacer grep de solicitudes/respuestas buscando patrones conocidos como malos es una cura adecuada para aplicaciones web vulnerables. En realidad, no es confiable ni preciso porque no puede serlo.
Si intento iniciar sesión en un sitio web con el nombre de usuario ' OR 0=0 --, Cloudflare no tiene forma de saber si esto es un ataque de inyección SQL o simplemente un nombre de usuario peculiar que el sitio web ha decidido emitir legítimamente. Cloudflare no tiene forma de saber si el sitio web incluso usa SQL para el almacenamiento de datos.
Si publico ' OR 0=0 -- en un comentario, Cloudflare no tiene forma de saber si esto es un ataque de inyección SQL, o si realmente funcionará, o si realmente estoy publicando un comentario discutiendo sobre inyección SQL e incluyendo ejemplos (en cuyo punto esto realmente se convierte en una forma de censura).
Lo que significa usar Cloudflare es que Cloudflare causará aleatoriamente DoS a los usuarios si piensa que están intentando usar un patrón de texto al cual Cloudflare es por diseño alérgico. Las circunstancias en las que ocurren estas denegaciones de servicio están, por supuesto, mal definidas y de ninguna manera exhaustivamente enumeradas, por lo que usar Cloudflare presenta una responsabilidad intensa e inaccountable en términos de disponibilidad y neutralidad de contenido para cualquier sitio web. Es esencialmente una forma de hacer que tu sitio web sea poco fiable y falle aleatoriamente.
El concepto de “firewall de aplicaciones web” está fundamentalmente fallido en todos los casos, porque presupone falsamente que un proxy intermedio ciego puede evaluar de manera confiable el significado semántico de los datos transmitidos, lo cual en realidad es imposible. Dado que este tipo de “servicio” es parte de la propuesta de valor de Cloudflare y un intento de agregar un valor adicional generador de ganancias, Cloudflare ha construido esencialmente todo su negocio haciendo algo que es una mala idea y que no puede implementarse de manera confiable.
Continuando con el tema fallido del “firewall de aplicaciones web” de un proxy desconocedor que intenta adivinar el significado semántico del contenido transmitido a través de él, Cloudflare insiste en ser una CDN que hace cosas no propias de CDN de otras maneras. En lugar de ser un proxy neutral del tráfico, incluso cuando Cloudflare no está estocásticamente haciendo DoS a los sitios web de sus clientes, Cloudflare insiste en hacer cosas interesantes con los cuerpos de respuesta.
Por ejemplo, manipula direcciones de correo electrónico y las reemplaza con alguna convolución de JavaScript destinada a complicar la recopilación. Excepto que no manipula direcciones de correo electrónico… manipula cualquier cosa que se parezca vagamente a una dirección de correo electrónico, incluso si no lo es.
Esto:
# Bienvenido a example.com. Para acceder a la API foobar, usa curl:
curl 'https://foo@example.com/foobar'
se convierte en:
# Bienvenido a example.com. Para acceder a la API foobar, usa curl:
curl 'https://[email protected]/foobar'
¿Dirección XMPP? Filtrada. ¿Dirección SIP? Filtrada. ¿Identificador de algoritmo OpenSSH? Filtrado. ¿Principal de Kerberos? Filtrado. Debido a que este filtrado necesariamente se hace sin tener en cuenta el contexto, sufre los mismos problemas inherentes a intentar prevenir la inyección SQL, y es una demostración potente de cómo los “Firewalls de Aplicaciones Web” son una idea fundamentalmente estúpida. Cloudflare no puede tener ni la más mínima pista de si algo es una dirección de correo electrónico o no, pero filtrará de todos modos.
Dado que navego por la web con JavaScript desactivado por defecto, es un facepalm constante para mí encontrar cosas en sitios web que ni siquiera son direcciones de correo electrónico reemplazadas con [email protected], incluso partes de listados de código fuente.
Por supuesto, esta práctica también discrimina contra usuarios con JavaScript desactivado y contra navegadores que no soportan JavaScript, impidiéndoles ver direcciones de correo electrónico (o cualquier cosa que se parezca a una).
Cloudflare también toma otras libertades. Reorganiza el JavaScript de una página web para optimizarlo. Esencialmente, Cloudflare modifica las respuestas para aplicar una variedad de transformaciones mal definidas que cree apropiadas. Desde la perspectiva de un operador de sitio web, esto debería verse como una responsabilidad.
Ningún otro servicio CDN ofrece un servicio gratuito comparable al de Cloudflare. ¿Por qué Cloudflare ofrece servicio gratis?
Es porque Cloudflare no es una CDN, es un proyecto de inteligencia. Su propósito completo es recopilar datos. Esto no es una inferencia mía, los fundadores de Cloudflare han declarado felizmente públicamente:
En 2003, Lee Holloway y yo comenzamos Project Honey Pot como un proyecto de código abierto para rastrear fraude y abuso en línea. El Proyecto permitía a cualquiera con un sitio web instalar un fragmento de código y rastrear hackers y spammers. Lo ejecutamos como un pasatiempo y no pensamos mucho en ello hasta que, en 2008, el Departamento de Seguridad Nacional llamó y dijo: ‘¿Tienen alguna idea de cuán valiosos son los datos que tienen?’ Eso nos hizo pensar en cómo podríamos desplegar efectivamente los datos de Project Honey Pot, así como de otras fuentes, para proteger sitios web en línea. Eso se convirtió en el impulso inicial para CloudFlare.
Sí, Cloudflare fue fundado por la gente de Project Honeypot.
Cloudflare también tiene un nivel gratuito extremadamente generoso, y probablemente la mayoría de los sitios web que lo usan no pagan. Pero como hemos llegado a entender en esta era de capitalismo de vigilancia, si no estás pagando, no eres el cliente — eres el producto.
Amenaza a la anonimidad de los usuarios de Tor. Cloudflare no solo inconveniente inútilmente a los usuarios de Tor haciéndoles resolver CAPTCHAs para ver sitios web; también representa un vehículo para la desanonimización de usuarios de Tor. Cloudflare es básicamente una plataforma ideal para atacar Tor porque es lo más cercano que alguien ha estado jamás de construir un Adversario Activo Global (GAA) — una entidad que puede observar y modificar tráfico en cualquier parte del mundo. Compárese esto con la categoría menor del Adversario Pasivo Global (GPA), que puede observar pero no modificar tráfico en cualquier parte del mundo. Tor no está diseñado para ofrecer seguridad efectiva contra ninguno de estos.
Para poner esto en perspectiva, en 2013 la NSA había renunciado a lograr el estatus de GPA (y por lo tanto a poder desanonimizar de manera confiable el tráfico de Tor), y mucho menos GAA. Cloudflare está efectivamente invitando a la gente a ayudarla a convertirse en un GAA.
Cookies de seguimiento. Por cierto, Cloudflare entrega una cookie de seguimiento para cualquier sitio web que lo use. Incluso si el sitio web es completamente estático y sin estado, aún obtienes una cookie de seguimiento. (Dado que Cloudflare definitivamente tiene activos en la UE — tiene que tenerlos, es una CDN — también está violando bastante descaradamente la ley de la UE aquí).
Cloudflare es conocido por proporcionar sus servicios a una variedad de sitios web, incluidos sitios web de piratería notorios como The Pirate Bay. También es una empresa estadounidense.
Dado que se sabe que EE.UU. derriba incluso empresas que parecen ser legales en el papel, como Megaupload, cuando están asociadas con infracción de derechos de autor, esta situación es peculiar.
Responsabilidad probable. 17 USC 512 prevé exenciones de responsabilidad por infracción de derechos de autor para varios tipos de entidad. 17 USC 512(c) prevé la retirada de “información que reside en sistemas o redes por dirección de usuarios”; esta es la conocida disposición de “aviso DMCA”. Sin embargo, también contiene una disposición 17 USC 512(b) que se relaciona con proxies de caché (es decir, Cloudflare).
Esta cláusula establece varias condiciones para que esta exención de responsabilidad sea válida:
En otras palabras, si un tribunal de EE.UU. ordenara que The Pirate Bay retirara ciertas páginas de su sitio, Cloudflare estaría obligado a cumplir con los avisos que le pidan dar efecto a esa retirada en ausencia de cumplimiento por parte de The Pirate Bay mismo — y en cualquier caso, parece probable que un tribunal de EE.UU. también podría simplemente ordenar a Cloudflare directamente que deshabilite el acceso a él.
Pero incluso esto es irrelevante porque Cloudflare modifica el material que pasa. Por lo tanto, no puede reclamar la exención 17 USC 512(b) en absoluto. Además, dado que 47 USC 230 (la Ley de Decencia en las Comunicaciones) exime explícitamente los derechos de autor de la inmunidad de responsabilidad que otorga a los intermediarios, sin una exención aplicable de 17 USC 512 es probable que sea responsable. A pesar de esto, ha habido una ausencia de incluso intentos de ataque por parte de EE.UU. a las actividades de Cloudflare proporcionando servicios a sitios web de piratería notorios.
Mis conclusiones. Parece probable que el gobierno de EE.UU. podría afectar adversamente el negocio de Cloudflare mediante acciones legales si lo deseara. El hecho de que no lo hayan hecho es por lo tanto inusual. Sin embargo, es bien sabido que las fuerzas del orden federales de EE.UU. están contentas de evitar cerrar actividades ilegales si creen que pueden obtener más inteligencia al no hacerlo.
A partir de programas anteriores como PRISM, está bien demostrado que la mayoría de las grandes empresas tecnológicas están perfectamente contentas de cumplir con solicitudes de acceso total por parte de agencias de inteligencia y fuerzas del orden. Además, dado que Cloudflare ahora es usado por un número absurdamente grande de sitios web, esto significa que Cloudflare es esencialmente la principal agencia global de MitM del mundo. Este es un nivel de acceso y visibilidad que las agencias de inteligencia de señales normalmente solo podrían soñar, especialmente porque rompe TLS. Para ser franco, los datos de interceptación disponibles para Cloudflare son tan tentadores para las agencias de inteligencia, que parece casi más allá de la plausibilidad que no hayan ido tras ellos, especialmente al considerar la posibilidad de chantajear efectivamente a Cloudflare sobre la legalidad de sus actividades y, para el caso, el contacto histórico conocido de sus fundadores con el DHS. (Aunque incluso esto asume una reluctancia predeterminada a asistir a la vigilancia extrajudicial por parte de las empresas tecnológicas, de la cual se sabe que frecuentemente no es el caso a favor de la indiferencia o el entusiasmo abierto).
En otras palabras, en el balance de probabilidades, creo que la continua falta de agresión de Cloudflare por parte del gobierno de EE.UU. y la simple consideración del MO estándar tanto de las agencias de inteligencia como de las empresas tecnológicas hace que sea abrumadoramente probable que Cloudflare sea un elemento efectivo de la inteligencia de señales de EE.UU.
Esto no es, por supuesto, evidencia o prueba. Sin embargo, las probabilidades son adecuadas para que asumir que no es el caso sería, francamente, imprudente. Aunque el uso de Cloudflare como escuchadero por sí solo sería alarmante en sí mismo, la perspectiva de la fusión de la capacidad parcial de GAA de Cloudflare y las capacidades parciales de GPA de la NSA sería formidable en extremo. Una abundancia de precaución — y una desconfianza de las empresas que esencialmente intentan ponerse en posición de hacer MitM a todo el tráfico web, incluso si afirman benevolencia — es totalmente aconsejable.
Después de todo, la mera posibilidad de esto amenaza con socavar el “renacimiento criptográfico”, para socavar todo por lo que ha trabajado la comunidad criptográfica pública desde 2013 — y la criptografía se trata de mitigar meras posibilidades en primer lugar1.
1 Hablando personalmente, asumo hoy en día que cualquier cosa que una agencia de inteligencia pudiera estar haciendo, muy probablemente la está haciendo. Las revelaciones de Snowden parecen mostrar que esta regla sirve bien, por lo que a veces me refiero a esto como la “ley de Snowden”. ↩
2 Una aclaración preventiva — las personas familiarizadas con la oferta de Cloudflare podrían mencionar su servicio “keyless SSL”, pero esto en realidad no cambia nada porque Cloudflare aún termina la sesión TLS y ve el tráfico descifrado. ↩
Nota: Este es un resumen traducido y formateado del artículo original “Cloudflare considered harmful” de Hugo Landau. Las opiniones expresadas son del autor original y no necesariamente reflejan la posición de este asistente.