Bloqueado por Cloudflare
(jrhawley.ca)- En una página de GitLab necesaria para el trabajo, quedó atrapado en un “secure connection loop” en el que la verificación de integridad del navegador de Cloudflare no terminaba; después, el acceso con Firefox también quedó bloqueado en otro sitio web interno de la empresa
- Cambiar el valor de
privacy.resistFingerprintingen Firefox resolvió el acceso a GitLab, pero al día siguiente apareció una página de bloqueo en un sitio interno no relacionado, y volver el valor a su estado anterior no lo solucionó - Con el mismo equipo de trabajo, la VPN de la empresa y las mismas condiciones de certificado de seguridad, Chrome sí podía acceder y solo Firefox quedaba bloqueado, por lo que se considera que la decisión de bloqueo estaba relacionada con la huella digital del navegador o con la ausencia de ella
- Por el momento habrá que usar Chrome para los sitios internos de trabajo, y al usuario le resulta difícil saber cuántos sitios internos y externos más “protegidos” por Cloudflare se verán afectados
- Si tendencias como la atestación remota, Web Integrity API y passkeys dan más poder a las empresas, las personas podrían perder la capacidad de elegir hardware, sistema operativo y software, y tener que ajustarse a reglas invisibles
El secure connection loop de Cloudflare
- Cloudflare proporciona red de distribución de contenidos, defensa contra ataques distribuidos de denegación de servicio y otros servicios de infraestructura de red a gran parte de Internet
- Muchos sitios web que usan Cloudflare colocan una verificación de integridad del navegador antes de permitir el acceso
- El objetivo es bloquear actores maliciosos, bots y tráfico no deseado, y hacer que personas reales usen el sitio de la forma prevista
- Incluso un usuario legítimo que accede con buenas intenciones puede quedar bloqueado en la página de seguridad
- El secure connection loop es un estado en el que, cuando el usuario ingresa una URL, Cloudflare intercepta la solicitud y muestra una página de “Checking if the site connection is secure”, pero la verificación nunca termina
- El indicador de carga sigue girando, o se vuelve a pedir verificación humana y luego la página se actualiza repetidamente
- Aunque el usuario siga el procedimiento solicitado, vuelve a recibir la siguiente solicitud y no logra pasar
- Al buscar “Cloudflare checking if the site connection is secure”, además de la documentación oficial de Cloudflare aparecen muchas preguntas de usuarios que intentan esquivar esa página, por lo que parece ser un problema común
Problema de acceso a GitLab y cambio de configuración en Firefox
- Al intentar acceder a una página de GitLab desde la computadora de trabajo para revisar software científico, apareció la página de verificación de integridad del navegador de Cloudflare
- Se intentó revisar errores en la consola de desarrollador, desactivar temporalmente extensiones, usar una ventana privada y reiniciar la computadora, pero no fue posible salir del loop
- En los resultados de búsqueda encontró la sugerencia de desactivar la opción
privacy.resistFingerprintingenabout:configde Firefox- En ese momento ese valor ya estaba en
false - Al cambiarlo a
true, logró pasar la verificación de integridad del navegador y acceder al software que quería revisar
- En ese momento ese valor ya estaba en
Bloqueo en un sitio web interno no relacionado
- Al día siguiente, al acceder a una página web interna necesaria para el trabajo, apareció una página de bloqueo
- En la secuencia de hechos, no pudo pasar el loop de verificación de Cloudflare y, tras cambiar una configuración de privacidad de Firefox para esquivarlo, quedó bloqueado en otro sitio de trabajo
- Todo el proceso ocurrió desde un equipo de trabajo y detrás de la VPN de la empresa
- Para acceder a esa VPN es necesario que el dispositivo tenga instalado un certificado de seguridad específico
- Como Cloudflare solicitó ese certificado, se considera que sabía de su existencia
- Como datos fuertes que Cloudflare podría usar para verificar identidad se mencionan un certificado de seguridad por usuario y la dirección IP de la VPN corporativa
- El texto original mencionaba inicialmente la dirección MAC, pero en una nota al pie corrigió que lo más probable es que Cloudflare solo conociera la dirección IP detrás de la VPN de la empresa, no la dirección MAC
- No se instalaron extensiones adicionales, no se usó un navegador headless, no se cambió el agente de usuario ni se usaron Tor o protocolos no estándar; lo único que se cambió fue una configuración de privacidad del navegador
- Volver la configuración a su valor original no eliminó el bloqueo, y el acceso a recursos necesarios para el trabajo quedó en duda
Suposiciones sobre la causa del bloqueo y comparación con Chrome
- Debido al secure connection loop, el navegador hizo varias solicitudes de acceso a la misma página en poco tiempo, y Cloudflare pudo haber detectado esa alta frecuencia de solicitudes y rechazos como un patrón sospechoso
- Esta parte no es una causa confirmada, sino una explicación posible
- Luego, al bloquear el fingerprinting, el primer acceso sí pasó, pero se considera posible que Cloudflare haya interpretado la secuencia de eventos como comportamiento malicioso y marcado el navegador como sospechoso
- Al intentar acceder al sitio interno con Google Chrome, no hubo bloqueo
- El hecho de que el bloqueo ocurriera solo en Firefox y no en Chrome llevó a concluir que el bloqueo de Cloudflare se basa en la huella digital del navegador o en su ausencia
- Ambas solicitudes se hicieron con el mismo certificado de seguridad, la misma VPN corporativa, el mismo dispositivo y en la misma franja horaria
- La diferencia fue el navegador usado
- Se considera que Chrome no tiene un diseño de privacidad y seguridad reforzada al mismo nivel que Firefox, y que no se resiste al fingerprinting ni permite cambiar esa configuración en la misma medida
Impacto laboral
- Durante el futuro cercano habrá que usar Chrome para acceder a sitios internos de trabajo
- No se sabe cuántos otros sitios web internos o externos “protegidos” por Cloudflare terminarán bloqueados
- Podría intentar reinstalar Firefox, pero como ya vivió una situación en la que una respuesta basada en conjeturas empeoró las cosas, es difícil confiar en el siguiente paso
- Al no existir un procedimiento claro que el usuario pueda aplicar directamente, surge la posibilidad de tener que buscar en el directorio interno al administrador de sistemas responsable de esa página y pedir autorización de acceso
Preocupaciones sobre la web en general
- El hecho de que el acceso a recursos necesarios pueda bloquearse por desviarse un paso del comportamiento esperado, incluso con pruebas sólidas de identidad, lleva a preocuparse por el futuro de la web
- Si la atestación remota y las medidas de “seguridad” se aplican a áreas como la banca en línea, podrían afectar casi todos los aspectos de la vida personal
- Los usuarios de Android de-Googled deben hacer mucho esfuerzo para que la atestación de hardware funcione correctamente a fin de usar apps bancarias
- La guía de compatibilidad de atestación de GrapheneOS es un ejemplo de ello
- Se considera que falta un punto intermedio entre acceder al dinero desde un dispositivo personal y permitir que Google vigile la interacción con el dispositivo
- Las propuestas web que dan más poder a empresas a las que es difícil exigir responsabilidades que a las personas pueden aumentar las situaciones en las que los usuarios terminan tanteando reglas invisibles
- Solo en los últimos años empezaron a aplicarse sanciones sustanciales a empresas que violan leyes de privacidad, y la multa de 1.200 millones de euros a Facebook por incumplir el GDPR es un ejemplo
Preguntas que dejan Web Integrity API y passkeys
- La propuesta Web Integrity API es una propuesta que provocó rechazo en torno al futuro de la web
- Si una empresa financiera adopta una política de atestación remota en su sitio web, podrían restringirse aún más los tipos de hardware, sistemas operativos y software que puede usar una persona
- Puede haber razones legítimas para bloquear dispositivos viejos, vulnerables y sin posibilidad de parches, pero se considera que las decisiones empresariales pueden tender a aumentar el control corporativo a costa de la libertad o los derechos individuales
- El primer ejemplo de la propuesta Web Integrity API plantea la necesidad de que, en sitios web financiados con publicidad, los anunciantes puedan pagar para que personas, y no robots, vean los anuncios
- Como resultado, se considera que la carga de demostrar que se es humano recae sobre los usuarios humanos
- También se cuestiona que el autor de la propuesta pertenezca a Google, una empresa con grandes ingresos publicitarios
- La adopción de passkeys es una propuesta útil que puede ofrecer un acceso más seguro y sencillo a sitios web
- Sin embargo, si incluso pruebas fuertes de identidad pueden ser ignoradas, como en la experiencia con Cloudflare, es difícil saber cómo servicios como Cloudflare tratarán las passkeys
- Las passkeys dejan varias preguntas prácticas
- ¿Puede el usuario crear y sincronizar passkeys por su cuenta?
- Si solo cierto software puede usar passkeys, ¿quién define esos criterios?
- ¿Se requieren requisitos específicos de hardware o software como TPM, DeviceCheck o Integrity API?
- ¿Se pueden exportar las passkeys de un proveedor de servicio y moverlas a otro en cualquier momento?
- Si una passkey se asocia con un evento sospechoso, ¿la marca de sospecha se propaga a otros dispositivos que usan la misma passkey?
- ¿Los dispositivos que contienen passkeys sospechosas también se marcan como sospechosos, y eso afecta el acceso desde ese dispositivo a otros sitios web independientes?
- Las contraseñas tienen muchas desventajas, pero también la fortaleza de que las personas pueden crearlas por sí mismas, en los dispositivos que poseen, y administrarlas de la forma que quieran
- Aunque tecnologías como VPN, certificados y fingerprinting compensen debilidades de las contraseñas y de la seguridad informática, si para hacer tareas básicas hay que renunciar a la privacidad y aun así se puede terminar bloqueado, esa ayuda es limitada
1 comentarios
Opiniones en Hacker News
Incluso personas que dicen ser sensibles a la privacidad muchas veces usan Chrome sin saber esto.
Una página que Firefox bloqueaba se abrió en Chrome, pero Chrome no tiene un diseño reforzado de privacidad y seguridad como Firefox, recopila y comparte más historial de navegación y datos personales, y resiste menos el rastreo por huella digital.
Si era el mismo certificado, la misma VPN corporativa, el mismo dispositivo y la misma franja horaria, y solo al cambiar de navegador logró pasar, parece significar que Cloudflare lo estaba bloqueando con base en la huella digital del navegador o la ausencia de ella.
Si hoy te importa aunque sea un poco, no deberías usar Chrome.
En esta situación no queda claro qué información proporcionó Chrome a diferencia de Firefox, y podría ser simplemente que Firefox, al tener un agente de usuario menos común, haya sido sometido a un filtrado más estricto.
He visto casos en los que, al cambiar de navegador en un sitio, desaparece el mensaje de límite de velocidad; quizá con información limitada se asumió que misma IP + distinto agente de usuario = otra computadora.
Como mínimo habría que probar también con un tercer navegador.
“Usa Chrome” no es una solución, y quienes usan Firefox u otro software que no sea de Google siguen siendo personas.
La forma de verificar con JavaScript que “no eres un bot” parece más bien un mecanismo para obligar a los usuarios a activar JavaScript y exponerse a más anuncios.
Si el criterio es monopolizar el mercado y amenazar el futuro de la internet abierta, Cloudflare es una amenaza mayor, y en el momento en que la dictadura de Cloudflare se vuelva menos benévola, todos lo van a sentir.
Soy PM de la plataforma de desafíos de Cloudflare y me gustaría investigar la causa del problema.
No penalizamos a los usuarios solo por acciones repetidas, así que eso no debería hacer que el navegador aparezca como sospechoso.
Personalmente uso mucho Firefox, pero no he visto este comportamiento; si fuera un problema generalizado de Firefox, se habría disparado una alerta automática y lo habríamos tratado como un incidente grave.
Si te interesa resolver el problema, puedes escribirme a amartinetti at cloudflare.
Las direcciones IP se usan para enrutar paquetes, no deberían usarse para asignarles a los usuarios una “puntuación de comportamiento” en segundo plano. Mi IP pudo haber sido ayer la de una persona completamente distinta.
Decidir quién puede acceder a la mitad de la web usando firmas TLS no resuelve nada a largo plazo, refuerza el monopolio de los navegadores y va directamente en contra del espíritu de la web abierta.
Como ejecuto bots tipo crawler para proyectos personales, en cierta medida me lo busqué, pero si simplemente imito la firma TLS de Chrome, sigue funcionando. Amigos que no tienen conocimientos técnicos ni hicieron nada también quedaron atrapados en este bloqueo.
Es muy probable que el servicio de Cloudflare haya causado a millones de personas el perjuicio de quedar de pronto bloqueadas en la mitad de la WWW, y este tipo de daño es la consecuencia lógica de las heurísticas que deciden si se puede acceder o no a un sitio.
También es absurdo que una sola empresa fuera de mi país decida si puedo usar la web, y ahora tengo que volver a buscar proxies en lugares sospechosos para poder seguir usando Firefox.
Normalmente termina sola y no es gran cosa, pero sí se sintió un aumento en la frecuencia durante la semana pasada.
Puede que sea por la extensión Privacy Pass que uso, aunque no sé bien qué hace en realidad.
La ubicación real sigue siendo NYC, pero al entrar a sitios estadounidenses protegidos por Cloudflare aparezco como si viniera del Reino Unido, y cada vez me bloquean en más lugares, como periódicos locales, supermercados y emisores de tarjetas.
La información de geolocalización IPv6 de Cloudflare está rota, y parece interferir incluso cuando entro por IPv4. Para empezar, tomar decisiones basadas en geolocalización es una mala idea.
Podría deberse a que otros usuarios de la VPN se portaron mal, pero parece más probable que haya algo más que eso.
Tuve exactamente el mismo problema durante un tiempo, y pude encontrar los sitios a los que no podía acceder buscando “just a moment” en el historial del navegador
https://gitlab.com/users/sign_in, https://steamdb.info/login/, https://www.zabbix.com/forum/, https://casetext.com/, https://namemc.com/login, https://spinroot.com/, https://camelcamelcamel.com/
Es un problema que lleva meses, quizá años, y Cloudflare no parece arreglarlo; se siente como si odiaran la web abierta y quisieran imponer el dominio de Chrome/Chromium/Blink
El rayID no contiene información de identificación personal, así que puedes publicarlo, o escribir a amartinetti at cloudflare
Pronto también desplegaremos un mecanismo de reporte, para que en el futuro estos problemas se puedan notificar y atender rápidamente
Para usar la web hay que pagar un costo de una u otra forma: perder acceso por tener configuraciones estrictas de privacidad, o entregar privacidad. No hay forma de ganar
Ya no pago por otros motivos, pero en cualquier caso siento que fue bueno cortar con eso
Es el navegador número uno en escritorio, aunque no viene incluido por defecto en el sistema operativo; Windows tiene Edge y Mac tiene Safari, y aun así los usuarios descargan Chrome por su cuenta
Cuando una gran parte del tráfico de Internet queda controlada por una sola fuente, aparecen problemas como estos
Si Cloudflare decide arbitrariamente quién puede usar Internet, en la práctica su palabra se convierte en ley
Al principio empieza con una premisa ingenua como “una forma fácil de bloquear a los malos actores”, pero termina ampliándose según criterios arbitrarios
Para defender la privacidad también hay que permitir a la gente mala, pero el usuario promedio de Internet no entiende ese matiz
Incluso en el caso más ingenuo, un solo commit equivocado puede tirar Internet, y eso ya ocurrió en Cloudflare
Las leyes antimonopolio existen por empresas como Cloudflare, Google y Meta, pero no parece haber nadie con autoridad que quiera usarlas correctamente. Dentro de 20 años, Internet será completamente distinto a todo lo que hemos visto hasta ahora, y probablemente no para bien
Los clientes pueden elegir entre varios proveedores de CDN/WAF, Cloudflare ni siquiera es el más grande, Akamai es más grande
El CDN que más rápido crece es CloudFront y la competencia parece saludable, así que no entiendo por qué deberían aplicarse leyes antimonopolio
El dueño del sitio elige Cloudflare para impedirlo; Cloudflare no lo impone
Si uno inspecciona las diversas cookies de sesión de Cloudflare, los scripts de intermediario que inyecta en la página de “integridad de goma” o en el modo “super bot-fight”, etc., se ve que en la práctica está haciendo una verificación de integridad del navegador con heurísticas mediante web workers
Es decir, ejecuta una serie de pruebas que un navegador real manipulado por un usuario pasaría, pero que un navegador headless manipulado por un bot fallaría
Por ejemplo, para verificar si se trata de un navegador real o de un parser HTML crudo, dibuja una imagen en un canvas, la exporta como PNG y compara el hash; o revisa fuentes inusuales de sistemas operativos de consumo que suelen faltar cuando se ejecuta Puppeteer en el contenedor predeterminado de Lambda/Cloud Function
Más allá de eso, observa si los movimientos innecesarios del mouse y las pulsaciones de teclas antes de activar el prompt parecen errores humanos, o si se parecen a patrones de reproducción grabados vistos recientemente
Si quedas atrapado en el bucle de verificación, es porque tu navegador, dispositivo o extensiones ocultan o desactivan suficientes de estas heurísticas como para que Cloudflare no obtenga pruebas claras de que eres humano, y según la configuración del dueño del sitio, en vez de avisar que fallaste, sigue intentando obtener pruebas
Porque avisarle a un bot que falló sería darle una señal de “deja de hacer lo que no funciona y cambia la frecuencia de los escudos”
No hay excepciones en la consola y la misma página simplemente se recarga una y otra vez
Algo que a veces se pasa por alto es que el dueño de un sitio que usa Cloudflare decide globalmente qué tan paranoico quiere ser, y además puede crear reglas WAF muy detalladas y agresivas
Por eso, en algunos casos el dueño del sitio configura reglas demasiado agresivas y Cloudflare termina llevándose las críticas. Para el usuario final, el efecto visible suele ser el mismo
Antes creé una regla WAF que bloqueaba todo el tráfico de bots no verificados proveniente de grandes centros de datos como Google Cloud, OVH y DigitalOcean, pero fue un error porque muchas empresas, por algún motivo, enrutaban su tráfico a través de esos ASN
Esos usuarios seguramente se enojaron con Cloudflare, pero la causa real fue que yo configuré mal las cosas
En una clase de programación usamos como ejemplo un navegador simple; no procesa CSS ni JavaScript, así que la visualización es rudimentaria, pero funciona.
Funciona en algunos sitios, pero en particular los sitios grandes lo ven como un navegador desconocido y se niegan a enviar contenido. Probablemente piensan que es un bot.
Aunque fuera un bot, no veo cuál sería el problema si se comporta de forma educada, y me pregunto qué clase de web cerrada les hemos permitido crear a las grandes empresas.
No tiene obligación de prestar servicio a todo el mundo.
También molesta que la página de verificación de Cloudflare rompa la recarga de página en Firefox.
Cuando Cloudflare te devuelve a la página original, navega con POST; el primer POST lo intercepta Cloudflare, pero si recargas la página, ese POST va a la página real, y es muy probable que esa página no sepa qué hacer y muestre un error.
La única solución es presionar Enter en la barra de direcciones para volver a navegar en lugar de recargar, o buscar un enlace para volver a esa página.
No me sorprendería que algún sitio te bloquee por ese POST. Podría decidir: “enviaste un POST a esa página aun sabiendo que no debías hacerlo, así que eres un bot malicioso que intenta hackear”.
Es ridícula la cantidad de veces que Cloudflare me hace ver una página de “checking your connection” de 15 a 30 segundos.
Para alguien que vive con TDAH, como yo, estas demoras e interrupciones acumuladas durante todo el día pueden tener un impacto grave.
Incluso tomando bien la medicación, esta medida de verdad te deja impotente y hace que la experiencia en línea sea horrible y agotadora.
Nadie quiere mostrárselo a los usuarios, pero se termina usando porque no queda alternativa.
Debería reducir mucho la cantidad de CAPTCHA que ves de una manera que no perjudica demasiado la privacidad.
En Safari se pueden activar los Private Access Tokens: https://blog.cloudflare.com/how-to-enable-private-access-tok...
Ambos métodos se parecen a la propuesta de DRM web de Google en que un emisor externo genera tokens, pero, a diferencia del intento de Google, no garantizan que el bloqueador de anuncios esté desactivado en la página que quiere usar el token.
Ayer mismo me enteré de que el inicio de sesión de PayPal no funciona con Safari ni Firefox, y solo funciona en navegadores basados en Chromium.
Cada vez nos metemos más de lleno en la época de “este sitio está optimizado para Google Chrome”.
Si activas la protección contra fingerprinting en Firefox, no puedes iniciar sesión, y parece que la autenticación en dos pasos por sí sola no basta para proteger la cuenta.
Si no permito que Twitch identifique mi computadora de forma única, no me deja iniciar sesión, así que simplemente dejé de ver streams de Twitch.
Me pasó con Firefox en Windows, Linux y Android, y por suerte todavía tengo la sesión iniciada en la app, pero como no puedo entrar a PayPal desde Firefox, alguna vez tuve que pagar con tarjeta de crédito aunque tenía saldo en PayPal.