Bloqueado pela Cloudflare
(jrhawley.ca)- Em uma página do GitLab necessária para o trabalho, o Browser Integrity Check da Cloudflare ficou preso em um “secure connection loop” que nunca terminava; depois disso, o acesso pelo Firefox também foi bloqueado em outro site interno da empresa
- Alterar o valor de
privacy.resistFingerprintingno Firefox resolveu o acesso ao GitLab, mas no dia seguinte apareceu uma página de bloqueio em um site interno não relacionado, e voltar o valor ao original não resolveu - No mesmo dispositivo de trabalho, com a VPN da empresa e os certificados de segurança, o Chrome conseguia acessar, enquanto apenas o Firefox era bloqueado; isso sugere que a decisão de bloqueio estava relacionada à impressão digital do navegador, ou à ausência dela
- Por enquanto, será necessário usar o Chrome para sites internos de trabalho, e é difícil para o usuário saber quantos outros sites internos ou externos “protegidos” pela Cloudflare serão afetados
- Se tendências como atestação remota, Web Integrity API e passkeys derem mais poder às empresas, indivíduos podem perder a liberdade de escolher hardware, sistema operacional e software, tendo de se adaptar a regras invisíveis
O secure connection loop da Cloudflare
- A Cloudflare fornece rede de distribuição de conteúdo, proteção contra ataques distribuídos de negação de serviço e outros serviços de infraestrutura de rede para grande parte da internet
- Muitos sites que usam Cloudflare colocam um Browser Integrity Check antes do acesso
- O objetivo é impedir agentes maliciosos, bots e tráfego indesejado, garantindo que pessoas reais usem o site da forma pretendida
- Mesmo usuários legítimos, agindo de boa-fé, podem ser barrados na página de segurança
- O secure connection loop ocorre quando o usuário digita uma URL e a Cloudflare intercepta a solicitação, mostra a página “Checking if the site connection is secure” e a verificação nunca termina
- O indicador de carregamento continua girando, ou a autenticação humana é solicitada novamente e a página fica recarregando em loop
- Mesmo seguindo o procedimento exigido, o usuário recebe a próxima exigência de novo e não consegue passar
- Ao pesquisar por “Cloudflare checking if the site connection is secure”, além da documentação oficial da Cloudflare aparecem muitas perguntas de usuários tentando contornar essa página, o que indica que o problema parece ser comum
Problema de acesso ao GitLab e mudança de configuração no Firefox
- Ao acessar uma página do GitLab em um computador de trabalho para verificar um software científico, apareceu a página de Browser Integrity Check da Cloudflare
- O GitLab começou a usar Cloudflare em 2020
- Foram tentados: verificar erros no console de desenvolvedor, desativar temporariamente extensões, usar janela privativa e reiniciar o computador, mas nada tirou o navegador do loop
- Nos resultados de busca, surgiu a sugestão de desativar a opção
privacy.resistFingerprintingemabout:configno Firefox- Naquele momento, o valor já estava como
false - Ao mudar o valor para
true, foi possível passar pelo Browser Integrity Check e acessar o software que precisava ser verificado
- Naquele momento, o valor já estava como
Bloqueio em um site interno não relacionado
- No dia seguinte, ao acessar uma página interna da empresa necessária para o trabalho, apareceu uma página de bloqueio
- Pela sequência dos fatos, o usuário não conseguia passar pelo loop de verificação da Cloudflare, alterou uma configuração de privacidade do Firefox para contorná-lo e depois foi bloqueado em outro site de trabalho
- Todo o processo ocorreu em um dispositivo de trabalho, atrás da VPN da empresa
- Essa VPN exige que um certificado de segurança específico esteja instalado no dispositivo para permitir o acesso
- Como a Cloudflare solicitou esse certificado, presume-se que ela soubesse da existência dele
- Como dados fortes que a Cloudflare poderia usar para confirmação de identidade, foram citados o certificado de segurança individual do usuário e o endereço IP da VPN da empresa
- O texto original mencionava inicialmente o endereço MAC, mas corrigiu em uma nota de rodapé que a Cloudflare provavelmente não saberia o endereço MAC, apenas o IP por trás da VPN corporativa
- Não houve instalação de extensão adicional, uso de navegador headless, alteração de user agent, uso de Tor ou de protocolos não padrão; a única mudança foi uma configuração de privacidade do navegador
- Mesmo após restaurar a configuração ao valor original, o bloqueio não foi removido, tornando incerto o acesso a recursos necessários para o trabalho
Hipótese sobre a causa do bloqueio e comparação com o Chrome
- Por causa do secure connection loop, o navegador fez várias solicitações à mesma página em um curto período, e a Cloudflare pode ter detectado essa alta frequência de solicitações e recusas como um padrão suspeito
- Esta não é uma causa confirmada, mas uma explicação possível
- Depois, ao bloquear fingerprinting, o primeiro acesso passou; ainda assim, a Cloudflare pode ter interpretado a sequência de eventos como comportamento malicioso e marcado o navegador como suspeito
- Ao tentar acessar o site interno pelo Google Chrome, não houve bloqueio
- O fato de o bloqueio ocorrer apenas no Firefox, e não no Chrome, levou à conclusão de que o bloqueio da Cloudflare se baseava na impressão digital do navegador ou na ausência dela
- As duas solicitações foram feitas com o mesmo certificado de segurança, a mesma VPN da empresa, o mesmo dispositivo e no mesmo intervalo de tempo
- A diferença era o navegador usado
- O Chrome é visto como um navegador que não tem o mesmo nível de design voltado a privacidade e reforço de segurança que o Firefox, nem resiste a fingerprinting no mesmo grau ou leva o usuário a alterar essas configurações
Impacto no trabalho
- No curto prazo, será necessário usar o Chrome para acessar sites internos de trabalho
- Não é possível saber quantos outros sites internos ou externos “protegidos” pela Cloudflare ainda serão bloqueados
- Reinstalar o Firefox pode ser uma opção, mas, como tentativas especulativas já pioraram a situação, é difícil ter confiança no próximo passo
- Sem um procedimento claro que o próprio usuário possa seguir para resolver o problema, pode ser necessário encontrar no diretório interno o administrador de sistemas responsável pela página e solicitar liberação de acesso
Preocupações com a web em geral
- O fato de o acesso a recursos necessários poder ser bloqueado quando alguém se afasta um passo do comportamento esperado, mesmo tendo provas fortes de identidade, gera preocupação sobre o futuro da web
- Se atestação remota e medidas de “segurança” forem aplicadas a áreas como internet banking, isso pode afetar quase todos os aspectos da vida pessoal
- Usuários de Android sem Google precisam se esforçar bastante para que a atestação de hardware funcione corretamente ao usar aplicativos bancários
- O guia de compatibilidade de attestation do GrapheneOS é um exemplo disso
- A visão apresentada é que falta um meio-termo entre acessar o próprio dinheiro em um dispositivo pessoal e permitir que o Google monitore a interação com o dispositivo
- Propostas para a web que dão mais poder a empresas, que são mais difíceis de responsabilizar do que indivíduos, podem aumentar situações em que usuários ficam tentando adivinhar regras invisíveis
- Só nos últimos anos empresas que violam leis de privacidade começaram a receber sanções relevantes, como mostra a multa de 1,2 bilhão de euros aplicada ao Facebook por violação do GDPR
Perguntas deixadas pela Web Integrity API e pelas passkeys
- A proposta da Web Integrity API provocou reação contrária em debates sobre o futuro da web
- Se empresas financeiras adotarem políticas de atestação remota em seus sites, os tipos de hardware, sistema operacional e software que indivíduos podem usar poderão ficar ainda mais restritos
- Pode haver motivos legítimos para bloquear dispositivos antigos, vulneráveis e impossíveis de corrigir, mas decisões corporativas podem seguir na direção de ampliar o controle das empresas às custas da liberdade ou dos direitos individuais
- O primeiro exemplo da proposta da Web Integrity API cita a necessidade de que, em sites sustentados por publicidade, anunciantes possam pagar para que pessoas, e não robôs, vejam os anúncios
- A consequência, na visão apresentada, é que usuários humanos passam a carregar o ônus de provar que são humanos
- Também é questionado o fato de o autor da proposta trabalhar no Google, empresa com grande receita de publicidade
- A adoção de passkeys é uma proposta útil, capaz de oferecer acesso a sites de forma mais segura e simples
- Porém, se provas fortes de identidade podem ser ignoradas, como na experiência com a Cloudflare, fica difícil saber como passkeys seriam tratadas por provedores de serviço como a Cloudflare
- As passkeys deixam várias perguntas práticas
- O usuário pode criar e sincronizar passkeys por conta própria?
- Se apenas determinados softwares puderem usar passkeys, quem define esses critérios?
- São exigidos requisitos específicos de hardware ou software, como TPM, DeviceCheck ou Integrity API?
- É possível exportar passkeys de um provedor de serviço e movê-las para outro a qualquer momento?
- Se uma passkey estiver associada a um incidente suspeito, a marcação de suspeita se propaga para outros dispositivos que usam a mesma passkey?
- Dispositivos que contêm passkeys suspeitas também são marcados como suspeitos, afetando até o acesso desse dispositivo a outros sites independentes?
- Senhas têm muitos problemas, mas têm a vantagem de poderem ser criadas pelo próprio indivíduo, no dispositivo que ele possui, e gerenciadas da forma que preferir
- Mesmo que tecnologias como VPN, certificados e fingerprinting compensem fraquezas de senhas e da segurança de computadores, sua utilidade é limitada se, para fazer tarefas básicas, for necessário abrir mão da privacidade — e ainda assim houver risco de bloqueio
1 comentários
Opiniões no Hacker News
Mesmo pessoas sensíveis à privacidade muitas vezes usam Chrome sem saber disso
Uma página que era bloqueada no Firefox abriu no Chrome, mas o Chrome não tem um projeto voltado a mais privacidade e segurança como o Firefox; ele coleta e compartilha mais histórico de navegação e dados pessoais, além de resistir menos ao rastreamento por impressão digital
Se era o mesmo certificado, a mesma VPN corporativa, o mesmo dispositivo e o mesmo horário, mas bastou trocar o navegador para passar, isso parece significar que a Cloudflare estava bloqueando com base na impressão digital do navegador ou na ausência dela
Hoje em dia, se você se importa minimamente com essas coisas, não deveria usar Chrome
Nessa situação, não está claro quais informações o Chrome forneceu de diferente do Firefox, e pode ser simplesmente que o Firefox, por ter um user agent mais raro, tenha virado alvo de uma filtragem mais rigorosa
Já vi casos em que a mensagem de limite de taxa desaparecia ao trocar de navegador no site; com informações limitadas, é possível que tenham inferido mesmo IP + user agent diferente = computador diferente
No mínimo, seria preciso testar também com um terceiro navegador
“Use Chrome” não é uma solução, e quem usa Firefox ou outro software que não seja do Google continua sendo humano
Verificar por JavaScript que alguém “não é um bot” parece uma forma de obrigar o usuário a ativar JavaScript e se expor a mais anúncios
Se o critério é monopolizar o mercado e ameaçar o futuro da internet aberta, a Cloudflare é a ameaça maior, e todos vão sentir quando a ditadura da Cloudflare se tornar menos benevolente
Sou PM da plataforma de desafios da Cloudflare e gostaria de investigar a causa do problema
Não penalizamos usuários apenas por ações repetitivas, então o navegador não deveria ser marcado como suspeito por causa disso
Pessoalmente, uso bastante Firefox e não vi esse comportamento; se fosse um problema generalizado no Firefox, alarmes automáticos teriam disparado e teríamos tratado como incidente crítico
Se tiver interesse em resolver o problema, pode enviar um e-mail para amartinetti at cloudflare
Endereços IP servem para roteamento de pacotes, não para atribuir, em segundo plano, uma “pontuação de comportamento” aos usuários. Meu IP ontem poderia ter sido o IP de uma pessoa totalmente diferente
Usar assinaturas TLS para decidir quem pode acessar metade da web não resolve nada no longo prazo, fortalece o monopólio dos navegadores e vai frontalmente contra o espírito da web aberta
Como rodo bots do tipo crawler em projetos pessoais, em certa medida eu provoquei isso, mas ainda funciona se eu apenas imitar a assinatura TLS do Chrome. Amigos sem conhecimento técnico e que não fizeram nada também foram pegos nesse bloqueio
É bem provável que os serviços da Cloudflare tenham causado a milhões de pessoas o dano de serem bloqueadas em metade da WWW de um dia para o outro, e esse dano é a consequência lógica de heurísticas que decidem se alguém pode acessar um site
Também é ridículo que uma única empresa fora do meu país decida se eu posso usar a web, e agora preciso sair comprando proxies em lugares suspeitos para continuar usando Firefox
Normalmente ela termina automaticamente, então não é nada grave, mas senti que a frequência aumentou na semana passada
Talvez seja por causa da extensão Privacy Pass que estou usando, embora eu não saiba exatamente o que ela faz
A localização real ainda é NYC, mas ao acessar sites dos EUA protegidos pela Cloudflare parece que venho do Reino Unido, e cada vez mais lugares, como jornais locais, mercados e empresas de cartão, me bloqueiam
As informações de geolocalização IPv6 da Cloudflare estão quebradas, e ela parece interferir até quando acesso por IPv4. Em primeiro lugar, tomar decisões com base em geolocalização é uma má ideia
Pode ser porque outro usuário da VPN teve mau comportamento, mas parece mais provável que seja algo além disso
Tive exatamente o mesmo problema por um tempo e consegui encontrar, no histórico do navegador, os sites que não conseguia acessar pesquisando por “just a moment”
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/
É um problema que já dura meses, talvez anos, e a Cloudflare parece não corrigir; dá a sensação de que ela odeia a web aberta e quer impor o domínio do Chrome/Chromium/Blink
O rayID não contém informações de identificação pessoal, então pode ser divulgado publicamente, ou você pode enviar um e-mail para amartinetti at cloudflare
Em breve também vamos lançar um mecanismo de denúncia, para que problemas assim possam ser comunicados e tratados rapidamente no futuro
Para usar a web, é preciso pagar algum preço: ou perder acesso por causa de configurações rígidas de privacidade, ou entregar sua privacidade. Não há como vencer
Não pago mais por outros motivos, mas, de todo modo, sinto que foi bom ter cancelado
É o navegador número 1 no desktop, mesmo não vindo incluído por padrão no sistema operacional; o Windows tem o Edge e o Mac tem o Safari, mas ainda assim os usuários baixam o Chrome por conta própria
Quando uma grande parte do tráfego da internet é controlada por uma única origem, problemas assim vêm junto
Se a Cloudflare simplesmente decidir arbitrariamente quem pode usar a internet, na prática sua palavra vira lei
No começo isso parte de uma premissa ingênua, como “uma forma fácil de bloquear agentes maliciosos”, mas acaba se expandindo para critérios arbitrários
Para defender a privacidade, é preciso permitir também pessoas ruins, mas o usuário médio da internet não entende essa sutileza
Mesmo no caso mais inocente, um único commit errado pode derrubar a internet, e isso já aconteceu na Cloudflare
Leis antitruste existem por causa de empresas como Cloudflare, Google e Meta, mas não parece haver ninguém com autoridade disposto a aplicá-las de verdade. Daqui a 20 anos, a internet será completamente diferente de tudo que vimos até agora, e provavelmente não para melhor
Esses clientes podem escolher entre vários provedores de CDN/WAF, e a Cloudflare nem é a maior; a Akamai é maior
A CDN que cresce mais rapidamente é a CloudFront, e a concorrência parece saudável, então não entendo por que leis antitruste deveriam se aplicar
O dono do site escolhe a Cloudflare para impedir isso; não é a Cloudflare que impõe
Ao desmontar os vários cookies de sessão da Cloudflare, as páginas de “integridade de borracha” ou scripts injetados por intermediário enviados pelo modo “super bot-fight”, dá para ver que, na prática, ela executa heuristicamente uma verificação de integridade do navegador via web workers
Ou seja, roda uma série de testes que um navegador real operado por um usuário passaria, mas um navegador headless controlado por bot falharia
Por exemplo, para verificar se é um navegador real ou um parser HTML cru, ela desenha uma imagem em um canvas, exporta como PNG e compara o hash; ou verifica fontes peculiares de sistemas operacionais de consumidor que costumam faltar ao rodar o Puppeteer em contêineres padrão de Lambda/Cloud Function
Indo além, pode observar se movimentos desnecessários do mouse e pressionamentos de teclas antes de ativar o prompt parecem erros humanos, ou se se assemelham a padrões recentes de reprodução de gravações
Se você caiu no loop de verificação, é porque seu navegador, dispositivo ou extensões ocultaram ou desativaram heurísticas suficientes para que a Cloudflare não obtivesse provas convincentes de que você é humano; dependendo da configuração do dono do site, em vez de informar que falhou, ela continua tentando obter provas
Isso porque avisar a um bot que ele falhou equivale a dar o sinal de “pare com o método que não funciona e mude a frequência dos escudos”
Não há exceções no console; a mesma página apenas recarrega sem parar
Um ponto que às vezes passa despercebido é que o dono do site que usa Cloudflare decide, globalmente, o quão paranoico quer ser, e também pode criar regras de WAF separadas, muito granulares e agressivas
Então, em alguns casos, o dono do site configurou regras agressivas demais e a Cloudflare leva a culpa. Para o usuário final, o efeito geralmente é o mesmo
Certa vez criei uma regra de WAF que bloqueava todo tráfego de bots não verificados vindo de grandes datacenters como Google Cloud, OVH e DigitalOcean, mas foi um erro, porque muitas empresas, por algum motivo, roteavam tráfego por esses ASNs
Esses usuários provavelmente ficaram bravos com a Cloudflare, mas a causa real foi uma configuração errada minha
Em aulas de programação, usamos como exemplo um navegador simples; ele não processa CSS nem JavaScript, então a exibição é rudimentar, mas funciona
Em alguns sites ele funciona, mas especialmente os sites grandes o identificam como um navegador desconhecido e se recusam a enviar conteúdo. Provavelmente acham que é um bot
Mesmo que fosse um bot, se ele se comporta de forma educada, não vejo qual é o problema, e me pergunto que tipo de web fechada estamos permitindo que as grandes empresas construam
Ele não tem obrigação de prestar serviço a todo mundo
Também é irritante que a página de verificação da Cloudflare quebre o recarregamento de página do Firefox
Quando a Cloudflare manda você de volta para a página original, a navegação é feita por POST; o primeiro POST é interceptado pela Cloudflare, mas se você recarregar a página, esse POST vai para a página real, que provavelmente não sabe o que fazer e mostra um erro
A única solução é pressionar Enter na barra de endereços para navegar de novo em vez de recarregar, ou encontrar um link que leve de volta àquela página
Não me surpreenderia se você fosse bloqueado em algum site por causa desse POST. Eles podem concluir: “você enviou um POST para essa página mesmo sabendo que não deveria, então é um bot malicioso tentando hackear”
É absurdo o número de vezes que a Cloudflare me faz ver a página de “checking your connection” por 15 a 30 segundos
Para alguém que convive com TDAH, como eu, esses atrasos e interrupções acumulados ao longo do dia podem ter um impacto sério
Mesmo tomando a medicação corretamente, essa medida é realmente paralisante e torna a experiência online horrível e desgastante
Ninguém quer mostrar isso aos usuários, mas acaba sendo necessário
Ele deve reduzir bastante o número de CAPTCHAs que você vê, de uma forma que não é muito ruim para a privacidade
No Safari, é possível ativar Private Access Tokens: https://blog.cloudflare.com/how-to-enable-private-access-tok...
Os dois métodos são parecidos com a proposta de DRM para a Web do Google no sentido de que um emissor externo gera tokens, mas, ao contrário da tentativa do Google, não garantem para a página que quer usar o token que o bloqueador de anúncios está desativado
Ontem mesmo descobri que o login do PayPal não funciona no Safari nem no Firefox, só em navegadores baseados no Chromium
Estamos entrando cada vez mais fundo na era do “este site é otimizado para o Google Chrome”
Se você ativa a proteção contra fingerprinting no Firefox, não consegue fazer login, e aparentemente a autenticação de dois fatores por si só não é suficiente para proteger a conta
Se eu não permito que a Twitch identifique meu computador de forma única, ela não me deixa entrar, então simplesmente parei de assistir a streams da Twitch
Aconteceu no Firefox no Windows, Linux e Android; felizmente ainda estou logado no app, mas, como não consigo acessar o PayPal pelo Firefox, já paguei com cartão de crédito mesmo tendo saldo no PayPal