Cloudflareによってブロックされる
(jrhawley.ca)- 業務に必要なGitLabページで、Cloudflareのブラウザ整合性チェックが終わらない「secure connection loop」に陥り、その後は別の社内WebサイトでもFirefoxからのアクセスが遮断された
- Firefoxの
privacy.resistFingerprintingの値を変更してGitLabへの接続は解決したが、翌日には無関係な社内サイトでブロックページが表示され、値を元に戻しても解除されなかった - 同じ業務端末、会社VPN、セキュリティ証明書という条件でChromeは接続可能だった一方、Firefoxだけがブロックされており、ブロック判定はブラウザフィンガープリント、またはフィンガープリントの欠如に関連していると考えられる
- 当面は社内業務サイトにChromeを使う必要があり、Cloudflareで「保護」されている社内外のサイトが今後どこまで影響を受けるのか、利用者には分かりにくい
- リモートアテステーション、Web Integrity API、passkeysのような流れが企業にさらに大きな権限を与えれば、個人はハードウェア・OS・ソフトウェアの選択肢を失い、見えないルールに従わされる可能性がある
Cloudflareのsecure connection loop
- Cloudflareは、コンテンツ配信ネットワーク、分散型サービス拒否攻撃対策、その他のネットワーク基盤サービスをインターネットの多くの領域に提供している
- Cloudflareを利用する多くのWebサイトは、アクセス前にブラウザ整合性チェックを配置している
- 目的は、悪意ある主体、ボット、望ましくないトラフィックを防ぎ、実際の人間が意図された形でサイトを使うようにすることにある
- 正常な利用者が善意でアクセスしていても、セキュリティページで止められることがある
- secure connection loopとは、ユーザーがURLを入力するとCloudflareがリクエストを横取りし、「Checking if the site connection is secure」というページを表示したまま、検査が終わらない状態を指す
- 読み込み表示が回り続けたり、人間確認を再度要求したあとでリロードが繰り返されたりする
- 利用者が要求された手順に従っても、次の手順をまた要求され、通過できない
- 「Cloudflare checking if the site connection is secure」で検索すると、Cloudflare公式文書以外にも、そのページを回避したい利用者の質問が多数見つかるほど一般的な問題に見える
GitLab接続の問題とFirefox設定の変更
- 業務用コンピューターで科学ソフトウェアを確認しようとしてGitLabページにアクセスしたところ、Cloudflareのブラウザ整合性チェックページが表示された
- GitLabは2020年にCloudflareの利用を開始した
- 開発者コンソールのエラー確認、拡張機能の一時無効化、プライベートブラウズ、コンピューターの再起動を試したが、ループを抜けられなかった
- 検索結果から、Firefoxの
about:configでprivacy.resistFingerprintingオプションを無効化せよという提案を見つけた- その時点でその値はすでに
falseだった - 値を
trueに変えるとブラウザ整合性チェックを通過でき、確認したかったソフトウェアにアクセスできた
- その時点でその値はすでに
無関係な社内Webサイトで発生したブロック
- 翌日、業務に必要な社内Webページにアクセスするとブロックページが表示された
- 流れとしては、Cloudflareの検査ループを通過できず、それを回避するためにFirefoxのプライバシー関連設定を1つ変更したあと、別の業務サイトでブロックされた形である
- 一連の過程はすべて業務用端末と会社VPNの背後で行われた
- そのVPNは、端末に特定のセキュリティ証明書がインストールされていなければアクセスできない
- Cloudflareはその証明書を要求していたため、証明書の存在を認識していたと考えられる
- Cloudflareが本人確認に使える強いデータとして、利用者ごとのセキュリティ証明書と会社VPNのIPアドレスが挙げられている
- 原文では当初MACアドレスに言及していたが、脚注でCloudflareが知り得るのはMACアドレスではなく、会社VPNの背後にあるIPアドレスだけである可能性が高いと訂正している
- 別の拡張機能の導入、headless browserの使用、ユーザーエージェントの変更、Torや非標準プロトコルの使用はなく、変えたのはブラウザのプライバシー設定1つだけだった
- 設定を元の値に戻してもブロックは解消されず、業務に必要なリソースへのアクセスが不確実になった
ブロック原因の推測とChromeとの比較
- secure connection loopのため、ブラウザが短時間に同じページへのアクセスを何度も要求し、Cloudflareがこの高頻度の要求と拒否を疑わしいパターンとして検知した可能性がある
- これは確定した原因ではなく、あくまであり得る説明である
- その後、フィンガープリンティング防止によって最初のアクセスは通過したものの、Cloudflareが一連の出来事を悪意ある行動と解釈し、ブラウザを疑わしい対象としてマークした可能性があると見ている
- 社内サイトへのアクセスをGoogle Chromeで試したときはブロックされなかった
- Firefoxでのみブロックされ、Chromeではブロックされなかった点から、Cloudflareのブロックはブラウザフィンガープリントまたはフィンガープリントの欠如に基づいているとの判断につながった
- 2つのリクエストは同じセキュリティ証明書、同じ会社VPN、同じ端末、同じ時間帯に行われた
- 違いは使用したブラウザだけだった
- ChromeはFirefoxと同等のプライバシー・セキュリティ強化設計を持たず、フィンガープリンティングへの耐性も同程度ではなく、設定変更も求めないと考えている
業務上の影響
- 当面、社内業務サイトへのアクセスにはChromeを使う必要がある
- Cloudflareで「保護」されている社内外のWebサイトが今後どれだけブロックされるのか分からない
- Firefoxの再インストールを試すこともできるが、すでに推測に基づく対応で状況を悪化させた経験があるため、次の対処に確信が持てない
- 利用者が自力で解決できる明確な手順がなく、社内ディレクトリでそのページを担当するシステム管理者を探し、アクセス許可を求めなければならない可能性がある
Web全体への懸念
- 強い本人確認の証拠があっても、想定された行動から一歩外れるだけで必要なリソースへのアクセスが止められる可能性がある点が、Webの将来への懸念につながっている
- リモートアテステーションや「セキュリティ」対策がオンラインバンキングのような領域に適用されれば、個人生活のほぼあらゆる面に影響し得る
- de-Googled Androidの利用者は、銀行アプリを使うためにハードウェアアテステーションが正しく動作するよう多くの努力を払わなければならない
- GrapheneOSのattestation compatibility guideがその例である
- 個人端末で自分のお金にアクセスすることと、Googleに端末との相互作用を監視させることの間に中間地帯が乏しいと見ている
- 個人より責任追及しにくい企業にさらに多くの権限を与えるWeb提案は、利用者が見えないルールに合わせようとして迷わされる状況を増やしかねない
- 実質的な制裁がプライバシー法違反企業に科され始めたのはここ数年のことであり、GDPR違反によるFacebookへの12億ユーロの制裁金がその例として挙げられている
Web Integrity APIとpasskeysが残す問い
- Web Integrity API proposalは、Webの将来をめぐる反発を招いた提案である
- 金融会社がWebサイトにリモートアテステーション方針を導入すれば、個人が利用できるハードウェア、OS、ソフトウェアの種類がさらに制限される可能性がある
- 古くパッチ不可能な脆弱端末を防ぐ正当な理由はあり得るが、企業の判断は個人の自由や権利を代償に企業統制を強める方向へ流れ得ると見ている
- Web Integrity API提案の最初の例は、広告付きWebサイトで広告主がロボットではなく人間に広告を見せるために費用を払える必要性を挙げている
- その結果、人間の利用者が自分は人間だと証明する負担を背負わされることになると見ている
- 提案作成者が広告収益の大きいGoogleに所属している点にも疑問を呈している
- passkeysの導入は、より安全で単純なWebサイトアクセスを提供し得る有用な提案である
- ただし、Cloudflareでの経験のように強い本人確認の証拠があっても無視され得るのであれば、passkeysがCloudflareのようなサービス提供者にどう扱われるのかは分かりにくい
- passkeysには複数の実務的な疑問が残る
- 利用者はpasskeysを自分で作成し、同期できるのか
- 特定のソフトウェアしかpasskeysを使えないなら、その基準は誰が決めるのか
- TPM、DeviceCheck、Integrity APIのような特定のハードウェア・ソフトウェア要件が必要なのか
- passkeysはいつでもあるサービス提供者から書き出して、別の提供者へ移せるのか
- 疑わしい出来事にpasskeyが関与した場合、同じpasskeyを使う別の端末にも疑わしいというマークが伝播するのか
- 疑わしいpasskeysが入っている端末自体も疑わしい対象としてマークされ、その端末からの別の独立したWebサイトへのアクセスまで影響を受けるのか
- パスワードには多くの欠点があるが、個人が自分で作れ、自分の持つ端末で作れ、望む方法で管理できるという強みがある
- VPN、証明書、フィンガープリンティングのような技術がパスワードやコンピューターセキュリティの弱点を補うとしても、基本的な作業をするためにプライバシーを諦めなければならず、それでもブロックされ得るのであれば、その助けは限定的である
1件のコメント
Hacker Newsのコメント
プライバシーに敏感だという人でも、Chromeを使いながらこの点を知らないことが多い
FirefoxではブロックされていたページがChromeでは開けたが、ChromeはFirefoxのようなプライバシー・セキュリティ強化設計を備えておらず、閲覧履歴や個人情報をより多く収集・共有し、フィンガープリント追跡にもあまり強く抵抗しない
同じ証明書、同じ会社のVPN、同じ端末、同じ時間帯で、ブラウザだけ替えて通過したなら、Cloudflareはブラウザのフィンガープリント、またはその欠如を基準にブロックしているように見える
今どき少しでも気にすることがあるなら、Chromeは使うべきではない
この状況でChromeがFirefoxと違ってどんな情報を提供したのかは明確でなく、単にFirefoxのほうが珍しいユーザーエージェントなので、より厳しいフィルタリング対象になっただけかもしれない
サイトでブラウザを変えるとレート制限メッセージが消えるケースを見たことがあり、限られた情報だけで同じIP + 別のユーザーエージェント = 別のコンピューターと推定した可能性もある
少なくとも3つ目のブラウザでも試すべきだ
「Chromeを使え」は解決策ではなく、Firefoxやその他の非Googleソフトウェアを使う人もやはり人間だ
JavaScriptで「ボットではない」と検証する方式は、ユーザーにJavaScriptを有効にし、より多くの広告露出に身をさらすよう強制する手段に見える
市場を独占しオープンインターネットの未来を脅かしているという基準なら、Cloudflareのほうがより大きな脅威であり、Cloudflareの独裁がより不善意なものへ変わる瞬間、誰もがそれを実感することになるだろう
CloudflareのチャレンジプラットフォームPMだが、問題の原因を確認してみたい
反復動作だけでユーザーに減点を付けることはないので、それが原因でブラウザが疑わしいと表示されることはない
個人的にもFirefoxをよく使うがこのような動作は見たことがなく、Firefox全般の問題なら自動アラートが鳴って重大インシデントとして扱われていたはずだ
問題解決に関心があるなら、amartinetti at cloudflare にメールしてもよい
IPアドレスはパケットのルーティングに使うものであって、バックグラウンドでユーザーに「行動スコア」を付けるために使うべきではない。私のIPは昨日はまったく別の人のIPだったかもしれない
TLS署名でWebの半分にアクセスできる人を決めることは、長期的には何も解決せず、ブラウザ独占を強化し、オープンWebの精神に真っ向から反する
趣味プロジェクトでクローラーのようなボットを動かしているので、ある程度は自業自得な面もあるが、ChromeのTLS署名だけ真似すれば今でも動く。技術知識もなく何もしていない友人たちも今回のブロックに巻き込まれた
Cloudflareのサービスは、ある日突然WWWの半分でブロックされる被害を数百万人に与えた可能性が高く、こうした被害はサイトへのアクセス可否を判断するヒューリスティックの論理的帰結だ
自分の国の外にある単一の企業が、自分がWebを使えるかどうかを決めるのもばかげているし、今やFirefoxを使い続けるために怪しい場所でプロキシを買い回らなければならない
たいていは自動で終わるので大事ではないが、先週から頻度が上がったのは体感している
使っているPrivacy Pass拡張のせいかもしれないが、実際に何をしているのかはよく分からない
実際の位置は相変わらずNYCなのに、米国のCloudflare保護サイトにアクセスすると英国から来たように見え、地域紙、食料品店、カード会社など、ますます多くの場所でブロックされる
CloudflareのIPv6ジオロケーション情報が壊れており、IPv4で接続しても干渉しているようだ。そもそもジオロケーションベースの判断は良い考えではない
VPNの別の利用者が悪い行動をしたからかもしれないが、それ以上の原因である可能性のほうが高そうだ
しばらくまったく同じ問題があり、ブラウザ履歴で「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/
数か月、あるいは何年も続いている問題だが、Cloudflare は直す気がないようで、オープンなウェブを嫌い、Chrome/Chromium/Blink 支配を強制したがっているように感じる
rayID には個人識別情報は含まれていないので公開してもよいし、amartinetti at cloudflare にメールしてもよい
まもなく通報メカニズムも展開する予定で、今後はこうした問題をすばやく知らせて対応できるようにするつもりだ
ウェブを使うには、厳格なプライバシー設定のせいでアクセス権を失うか、プライバシーを差し出すかのどちらかで、いずれにせよ代償を払わなければならない。勝ち目がない
別の理由でもう支払ってはいないが、とにかくうまく縁が切れてよかったという気分だ
デスクトップ 1 位のブラウザだが、OS に標準搭載されているわけではなく、Windows には Edge があり、Mac には Safari があるのに、それでもユーザーは自分で Chrome をダウンロードする
インターネットトラフィックの大きな部分が単一の出所によって統制されると、こうした問題が起きる
Cloudflare が恣意的に誰がインターネットを使えるかを決めるだけで、事実上それがルールになってしまう
最初は「悪質な行為者を簡単に止める方法」といった素朴な前提から始まるが、結局は恣意的な基準へと拡大していく
プライバシー保護を擁護するなら、悪い人も許容しなければならないが、平均的なインターネット利用者はこうした機微を理解しない
もっとも善意に解釈した場合でも、誤ったコミット 1 つでインターネットを壊しうるし、Cloudflare ではすでにそういうことが起きている
Cloudflare、Google、Meta のような企業があるからこそ独占禁止法が存在するが、その法律をきちんと使おうとする権限者がいないように見える。20 年後のインターネットは今まで見てきたものとまったく違うものになっているだろうし、それは良い変化ではなさそうだ
顧客は CDN/WAF プロバイダーを複数の中から選べるし、Cloudflare は最大手ですらなく、Akamai のほうが大きい
最も急成長している CDN は CloudFront で、競争も健全に見えるのに、なぜ独占禁止法が適用されるべきなのか分からない
サイト所有者がそれを防ぐために Cloudflare を選んでいるのであって、Cloudflare が強制しているわけではない
Cloudflare の複数のセッション Cookie、「Integrity」ページや「super bot-fight」モードで送られる中間者挿入スクリプトなどを調べると、実際にはウェブワーカーで ブラウザ完全性チェック をヒューリスティックに実行していることが分かる
つまり、ユーザーが操作する実ブラウザは通過するが、ボットが操作するヘッドレスブラウザは失敗するような一連のテストを回しているということだ
たとえば、実ブラウザか生の HTML パーサーかを見分けるために、画像をキャンバスに描画して PNG として書き出し、そのハッシュを比較したり、Puppeteer を Lambda/Cloud Function のデフォルトコンテナで動かしたときに欠けがちなコンシューマー OS 特有のフォントを確認したりする
さらに、プロンプトを有効化する前の無意味なマウス移動やキー入力が人間のミスのように見えるか、最近見た録画再生パターンに似ていないかまで見ているということだ
検証ループに引っかかるなら、それはブラウザ、デバイス、拡張機能がこうしたヒューリスティックを十分に隠すか無効化していて、Cloudflare が人間であるという確かな証拠を得られていないからであり、サイト所有者の設定によっては失敗を知らせる代わりに証拠を得ようとし続ける
ボットに失敗した事実を知らせると、「効かない方法はやめてシールドの周波数を変えろ」というシグナルを与えることになるからだ
コンソール例外もなく、同じページが延々と再読み込みされるだけだ
ときどき見落とされるのは、Cloudflare を使っているサイト所有者が、全体としてどれだけ偏執的に振る舞うかを決められ、さらに個別に非常に細かく攻撃的な WAF ルール まで作れるということだ
そのため、場合によってはサイト所有者が過度に攻撃的なルールを設定したのに Cloudflare が非難される。エンドユーザーに見える効果はたいてい同じだ
以前、Google Cloud、OVH、DigitalOcean のような大規模データセンターから来る未検証のボットトラフィックをすべてブロックする WAF ルールを作ったことがあるが、多くの企業が何らかの理由でその ASN 経由でトラフィックをルーティングしていたため、失敗だった
そのユーザーたちは Cloudflare に腹を立てただろうが、実際の原因は私の設定ミスだった
プログラミングの授業で例として簡単なブラウザーを使っているのだが、CSSやJavaScriptは処理しないので表示は素朴でも動作はする
一部のサイトでは動くが、特に大きなサイトは正体不明のブラウザーだと見なしてコンテンツの配信を拒否する。おそらくボットだと思っているのだろう
たとえボットでも行儀よく動作するなら何が問題なのか分からないし、巨大企業がこんな閉じたウェブを作るのを私たちはなぜ許してしまったのか疑問だ
誰にでもサービスを提供しなければならない義務はない
Cloudflareの検査ページがFirefoxのページ再読み込みを壊すのも腹立たしい
Cloudflareが元のページに戻すとPOSTで移動するのだが、最初のPOSTはCloudflareが横取りする一方、ページを再読み込みするとそのPOSTが実際のページに送られ、そのページはどう処理すればいいか分からずエラーを表示する可能性が高い
解決策は、アドレスバーでEnterを押して再読み込みの代わりに再度移動するか、そのページへ戻るリンクを探すことだけだ
そうしたPOSTのせいで、あるサイトでブロックされても驚かない。「そのページにPOSTしてはいけないと分かっているのに送ったのだから、ハッキングを試みる悪意あるボットだ」と判断されてもおかしくない
Cloudflareが15〜30秒の「checking your connection」ページを見せる回数が異常に多い
私のようにADHDを抱えて生きている人間にとっては、こうした遅延や妨害が一日中積み重なると深刻な影響になりうる
薬をきちんと飲んでいても、この措置は本当に無力感を与え、オンライン体験をひどく消耗するものにする
誰もユーザーにそれを見せたいわけではないが、やむを得ず使うことになる
プライバシーにそれほど悪くない方法で、目にするCAPTCHAの数を大幅に減らしてくれるはずだ
SafariではPrivate Access Tokensを有効にできる: https://blog.cloudflare.com/how-to-enable-private-access-tok...
どちらの方法も、外部の発行者がトークンを生成するという点ではGoogleのウェブDRM提案に似ているが、Googleの試みと違って、トークンを使おうとするページで広告ブロッカーが無効になっていることまでは保証しない
つい昨日、SafariやFirefoxではPayPalログインができず、Chromium系ブラウザーでしかできないことを知った
ますます「このサイトはGoogle Chromeに最適化されています」の時代へ深く入り込んでいる
Firefoxでフィンガープリンティング防止を有効にするとログインできず、二要素認証だけではアカウント保護として不十分らしい
Twitchが私のコンピューターを一意に識別できるようにしないとログインを許可しないので、もうTwitchの配信を見るのをやめた
Windows、Linux、AndroidのFirefoxすべてでそうだったし、幸いアプリにはまだログインできているが、FirefoxでPayPalに入れないせいで、PayPal残高があるのにクレジットカードで支払ったことがある