O Chrome passou anos a assustá-lo com sites sem cadeado. Agora todos têm um - e em sete de dez sites grandes leva a um intermediário
O cadeado e o HTTPS foram inventados por um motivo: para que ninguém entre si e o site pudesse ler o que envia. O seu ISP, o Wi-Fi do café, um Estado no fio - todos vêem só texto cifrado. Os browsers passaram anos a ensinar: sem cadeado - não introduza a password.
Cloudflare é um proxy entre si e o site; Amazon CloudFront, Azure Front Door, Akamai e Fastly funcionam da mesma forma. Para «mitigar ataques», o intermediário precisa de ver o tráfego em claro. Assim a sua ligação termina no servidor dele: lá o pedido é desencriptado, verificado pelas regras e só depois enviado ao site por uma ligação separada. A própria documentação da Cloudflare chama a isto TLS termination - «o ponto onde o tráfego HTTPS é desencriptado para a Cloudflare o poder inspecionar». Amazon, Azure e Akamai usam o mesmo nome para o mesmo ponto.
Tecnicamente isto é um clássico homem no meio. A única diferença de um ataque: o dono do site aderiu quando colocou o site atrás do intermediário. O plano ou as definições não removem isto: enquanto o site estiver atrás de um intermediário, a encriptação termina no intermediário - no plano gratuito e no Enterprise. Ninguém lhe perguntou, e o cadeado não o diz.
O que isto significa na prática - por documentos e datas
Sem juízos. Só a documentação da própria Cloudflare, os seus relatórios de incidentes e textos públicos - com datas, para cada linha poder ser verificada.
Sete dos dez maiores sites - atrás de um intermediário
Segundo o HTTP Archive 2025, 71% dos mil sites mais visitados do mundo servem até o documento HTML através de um intermediário; entre o top 10 000 - 70%, entre o top 100 000 - 62%. Quem são esses intermediários: Cloudflare - 58% desses sites, depois Amazon CloudFront (7%), Fastly (5%), Akamai (2%) e load balancers na cloud. Contando todos os sites do mundo, um em cada três está atrás de um intermediário; só a Cloudflare - 26% de todos os sites e 85% do mercado de reverse-proxy.
O WAF lê o corpo de cada pedido - segundo a documentação
As regras da Cloudflare «inspect the body of each incoming request», e o campo http.request.body.raw na linguagem de regras é «the unaltered HTTP request body». Um formulário de login é um corpo de pedido. O login e a password nele são texto em claro.
Cloudbleed, 2017: a memória do intermediário vazou para outras respostas
De 22 de setembro de 2016 a 18 de fevereiro de 2017 um bug no parser da Cloudflare misturou pedaços de memória de um site nas respostas de outro: cabeçalhos, partes de pedidos POST com passwords, cookies, chaves API e tokens. A Cloudflare contou 1,2 milhões de hits; os vazamentos chegaram às caches de pesquisa - mais de 80 000 páginas limpas. A imprensa citou Uber, OkCupid, Fitbit.
Novembro de 2023: atacantes entraram na Cloudflare com chaves roubadas
De 14 a 24 de novembro de 2023 atacantes - a Cloudflare chama-lhes «nation-state» - com credenciais roubadas na falha da Okta trabalharam dentro dos sistemas da Cloudflare: wiki Confluence, tracker Jira, repositórios Bitbucket, 76 repositórios descarregados. Depois a Cloudflare rodou mais de 5 000 credenciais e reviu 4 893 sistemas.
Um interruptor para todos
2 de julho de 2019 - 27 minutos, uma regex no WAF, o tráfego caiu 82%. 21 de junho de 2022 - 75 minutos, 19 centros de dados. 18 de novembro de 2025 - quase seis horas, «worst outage since 2019»: X, ChatGPT, Spotify, Shopify, Coinbase cairam. 5 de dezembro de 2025 - mais 25 minutos. 20 de fevereiro de 2026 - seis horas, um erro BGP. Nenhuma falha foi um ataque.
A Cloudflare decide se é humano
O dono do site marca uma caixa - e o acesso é decidido não por ele, mas pelo filtro da Cloudflare. A documentação admite um «challenge loop, when the challenge appears again and again», inclusive por VPN e proxies. Desde 2016 a Cloudflare trata Tor como um «país» separado e afirma que 94% dos pedidos dali são maliciosos; o Tor Project respondeu sobre um «endless loop of CAPTCHAs» e um bloqueio de pelo menos 80% dos endereços Tor.
Quando um Estado luta contra o intermediário: o caso da Rússia
Em outubro de 2024 a Cloudflare activou a encriptação ECH por predefinição nos planos gratuitos. A 6 de novembro de 2024 sites atrás da Cloudflare com ECH deixaram de abrir para ISPs russos; a 7 de novembro o CMU SSOP (uma unidade do Roskomnadzor, o regulador russo das comunicações) chamou ao ECH um «meio de contornar restrições» e recomendou aos donos desactivá-lo «ou, melhor, usar CDNs domésticos». Desde 9 de junho de 2025 os quatro maiores operadores russos cortam o tráfego Cloudflare aos primeiros 16 KB de qualquer ficheiro. O tráfego da Rússia caiu cerca de 30%; mais de 40% dos sites da web russa - cerca de 300 000 - estão atrás da Cloudflare. A 2 de junho de 2026 o FSB anunciou que serviços de informação estrangeiros tinham recolhido dados de telefones de funcionários russos «usando as capacidades técnicas» da Cloudflare e da Fastly, e abriu processos sob os artigos 272 e 273 do Código Penal - não mostrou provas técnicas, e as empresas não responderam. A mesma Cloudflare cobre desde 2022 sites do Ministério da Defesa do Reino Unido sob contrato governamental - Army, Royal Navy, RAF e o portal Defence Gateway para 330 000 utilizadores: £425 mil para 2022-2025 e £105 mil para 2025-2026.
O mesmo esquema em todo o lado: Amazon, Akamai, Azure, Fastly
Qualquer proxy ou load balancer na cloud que termina TLS em si funciona da mesma forma: Amazon CloudFront e ALB, Azure Front Door e Application Gateway, Akamai, Fastly, Imperva, e na Europa também OVHcloud, Myra, Link11. Cada um tem o seu WAF que lê o corpo do pedido, a sua cache e as suas falhas. A Cloudflare é simplesmente a maior e a mais aberta na documentaç��o. Hosting comum com certificado no servidor origin é diferente: lá só o site lê o tráfego.
O que isto significa para o seu dinheiro
Exchange atrás de um intermediário
Carteira web atrás de um intermediário
Carteira com assinatura offline
Verifique qualquer site em um minuto
Não tem de acreditar em nós nem neles. O intermediário deixa rasto em cada resposta, e qualquer um pode vê-lo.
Pegámos em cinco das carteiras mais populares e vimos quem está entre si e o site delas
Não adivinhámos nem lemos reviews alheias: fizemos pedidos normais aos sites, vimos cabeçalhos de resposta e certificados. O resultado está abaixo, tal como está.
O que as pessoas perguntam depois de chegar até aqui
O que é a Cloudflare em palavras simples?
Uma empresa intermediária: o site manda todo o tráfego pelos servidores deles, e eles «protegem-no». Para «proteger», desencriptam a sua ligação do lado deles. É assim que funciona um quarto de todos os sites do mundo.
A Cloudflare vê as minhas passwords?
Sim. A ligação termina no servidor dela, e as regras de filtragem segundo a documentação lêem o corpo de cada pedido - um formulário de login com utilizador e password é exactamente esse corpo. Se guarda isso e por quanto tempo regem as políticas dela, que não pode verificar.
Porque é que o site me pede para confirmar que sou humano?
Isso não é o site, é a Cloudflare. O dono ligou a verificação, e o filtro do intermediário decide: VPN, Tor, uma região «suspeita», um browser antigo - e cai num challenge loop. A própria Cloudflare admite esses loops na documentação.
Um site atrás da Cloudflare não abre no meu país. O que posso fazer?
Quando um país luta com um intermediário, aos utilizadores resta VPN - ou um site sem intermediário. Aos donos de sites ajuda uma coisa: tirar a Cloudflare de entre si e os utilizadores. O caso da Rússia no Facto 07 mostra quão depressa «o site está em baixo» se torna «o intermediário zangou-se com o ISP».
Isto é só sobre a Cloudflare?
Não. Qualquer intermediário que termina TLS em si funciona assim: Amazon CloudFront e load balancers AWS, Azure Front Door, Akamai, Fastly, Imperva, e na Europa também OVHcloud, Myra, Link11. Entre os mil maiores sites do mundo, 71% estão atrás de um intermediário: Cloudflare - 58% deles, Amazon - 7%, Fastly - 5%, Akamai - 2%. Hosting comum é diferente: lá o tráfego e o certificado pertencem ao próprio site.
Sou dono de um site. O que devo fazer?
Decida o que importa mais: «proteção contra ataques» ou o facto de as passwords dos utilizadores não passarem por código alheio. O plano e as definições não mudam isto - em qualquer plano a cifra termina no intermediário. Há um compromisso - um proxy que não desencripta TLS e só reencaminha o fluxo pelo nome do servidor. É assim que o nosso servidor frontal funciona: a proteção contra tráfego em excesso fica, um intermediário em texto claro não.