ハクソク

世界を動かす技術を、日本語で。

デフォルトでHTTPS

209日前原文(security.googleblog.com)

概要

  • Chrome 154 で「 Always Use Secure Connections」がデフォルト設定に変更予定。
  • HTTPS未対応サイト への初回アクセス時にユーザー許可が必要となる仕様。
  • HTTP通信のリスク 軽減とユーザー保護の強化が目的。
  • 警告頻度の抑制 やプライベートサイトの例外設定で利便性も確保。
  • 今後も HTTPS普及推進 とローカルネットワーク対応の改善を継続予定。

Chrome 154での「Always Use Secure Connections」デフォルト化

  • 2026年10月 リリース予定の Chrome 154 から、「Always Use Secure Connections」が標準設定。
  • HTTPS未対応のパブリックサイト 初回アクセス時、ユーザーに警告と許可確認。
  • Chrome Security の使命は「安全なリンククリック体験」の実現。
  • HTTP通信 は攻撃者によるナビゲーション乗っ取りやマルウェア感染のリスク源。
  • 実際に HTTPの脆弱性 を悪用した攻撃事例も存在。

HTTPS普及状況と課題

  • GoogleのHTTPS透明性レポート によると、2015年の 30-45% から2020年には 95-99% へ大幅増加。
  • 近年は 普及率が頭打ち、残るHTTP通信への対策が課題。
  • 95% の普及でも、残り数％のHTTP通信が大きなリスク要因。
  • HTTPサイト の多くは即座にHTTPSへリダイレクトするため、ユーザーが危険に気づけないケースも多い。

警告表示の最適化とユーザー体験

  • 全HTTPアクセスへの警告 はユーザー負担増となるため、警告頻度を最適化。
  • 頻繁にアクセスする非HTTPSサイト には繰り返し警告を表示しない仕様。
  • 新規または久しぶりのHTTPサイト アクセス時のみ警告表示。
  • プライベートサイト（ローカルIP等） は攻撃リスクが低いため、警告除外の設定を導入。
  • 企業内や開発者 向けには、プライベートサイト除外で警告数を大幅削減。

ローカルネットワークとHTTPS導入の障壁

  • プライベートアドレス は認証局による証明書発行が困難なため、HTTPS化が難しい現状。
  • ローカルネットワーク機器設定 などでHTTP利用が残りやすい状況。
  • Chromeの新機能 「ローカルネットワークアクセス許可」により、HTTPSサイトでも混在コンテンツブロックを回避可能に。

Chromeの今後の対応と推奨事項

  • Chrome 147（2026年4月予定） で、Enhanced Safe Browsing利用者向けに先行デフォルト化。
  • 設定の無効化 も可能なため、必要に応じてユーザーが警告をオフにできる。
  • サイト運営者やIT担当者 は、早期に「Always Use Secure Connections」設定を有効化し、移行準備を推奨。
  • 追加リソース も提供予定、組織管理者向けの警告制御や対策方法も案内。

今後の展望

  • パブリックHTTPサイトへの警告強化 はWebセキュリティ向上の大きな一歩。
  • ローカルネットワークサイト のHTTPS化障壁解消にも継続的に取り組む方針。
  • より堅牢なHTTP対策 実現に向けた技術開発と普及啓発の継続。

Chris Thompson、Mustafa Emre Acer、Serena Chen、Joe DeBlasio、Emily Stark、David Adrian（Chrome Security Team）より発表

Hackerたちの意見

http://http.rip/ はこういうテストに便利だよね。前は http://neverssl.com/ でテストしてたけど、なんか理由があってHTTPSが追加されたんだよね。

└

IANAの http://example.com にはまだプレーンなhttpバージョンがあるよ。

└

以前はhttp://neverssl.com/でテストしてたけど、なんか理由があってHTTPSを追加したんだよね。最初の反応は「え？それは絶対おかしい…」って感じだった。ちょっとテストしてみたら、https://neverssl.comは読み込めるけど、結局非HTTPSのサブドメインにリダイレクトされるみたい。逆に、リダイレクト前の初回読み込みがHTTPSだったら、ホテルのWi-Fiとかでは動かないはずだから、目的を果たせてない気がする。うーん。

└

neversslは、ドメイン名を入力したときに自動的にHTTPSに接続するブラウザ用にHTTPSバージョンを追加したんだ。サイトのHTTPSバージョンは、neverssl.comのランダムなhttp://サブドメインを読み込むためにJavascriptを使ってるから、自動HTTPSリダイレクトはまだ無効になってる。http.ripは、手動でhttp://プレフィックスを入力しない限り、「ウェブサイトが利用できません」エラーを表示するかもしれないね。

もうこれやってるんじゃない？ネットレベルの認証フローを強制するために、HTTPのドメインを一つか二つ持ってるんだけど（HTTPSに当たると正しく動かないことがあるから）、Chromeからは何年もずっとそのサイトについて警告が出てるよ… 最近そのサイトに行った時だけ警告が出ないんだ。

└

今はURLバーに「Not Secure」っていう小さなバブルが表示されるだけだと思う。（だから、ある意味では「警告」だね。）TFAは、HTTP接続を試みるとインタースティシャルが表示されるようになるって言ってる。HSTSもこれに関わるかもしれないけど、HSTSサイトはChromeがHTTPSに行くようにするだけだと思う（その接続が成功するか失敗するかは別として）。> ネットレベルの認証フローを強制するために（HTTPSに当たると正しく動かないことがある） HTTPSの本質は、基本的にこれらが機能すべきじゃないってことだよね。ベンダーは接続をMitMで変なネットレベルの認証を実装するのをやめるべきだし、DHCPにはネットワークに参加する人に認証のためにURLに行く必要があることを知らせるオプションがある。こういうMitMは厄介者で、アプリケーションでの悪い挙動を引き起こすことが多いんだ…

└

Chromeは約1年前からシークレットモードでHTTP警告を表示していて、アドバンスドプロテクションモードでは約2-3年前から警告を表示してるよ。

何年も前からデフォルトでHTTPSなんだけど、どのサイトがHTTPSじゃないかっていうのは、年ごとの変化があまり感じられないね。ほとんどがLet's Encryptが始まる前の古いサイトだし（おそらく誰もHTTPSを追加しなかったんだろうね）。2007年に更新が止まったニュースサイトとか、2011年に誰かが最後に投稿したブログとか、そんな感じ。ティムの玩具みたいなハイパーメディアシステム（「ワールドワイドウェブ」）にはセキュリティが組み込まれてなかったけど、普通のユーザーはそれを理解してないと思う。http://foo.example/ がfoo.exampleであることが保証されてると思ってるから、HTTPSにアップグレードすることでそれが真実になるのは、何十億人にもそのことを教えるよりずっと簡単だよね。イギリスのAPP詐欺を思い出すな。「Authorized Push Payment」って、普通の人が「大手法律事務所」にお金を払ってると思ってたら、実は詐欺師が自分の口座にお金を振り込ませるように仕向けてたっていう状況。イギリスの決済システムは名前を気にしなかったから、「大手法律事務所」口座#123456789への支払いは、「ジェーン・スミス」口座#123456789への支払いと同じだったんだよね。詐欺師は「大手法律事務所」の名義で口座を開くための書類を持ってないのに。これを解決するために、今のイギリスの決済システムは名前を必ず一致させるようにしてるから、「大手法律事務所」と言ってジェーンの口座に支払いをしようとすると、ソフトウェアが「違うよ、詐欺にあってる？」って言ってくれる。だから、意図してない人にお金を渡す理由がないから安全なんだ。イギリスの何千万の住民に名前が無視されてることを教えるのは現実的じゃないから、決済システムをアップグレードして名前を確認するのは難しかったけど可能だったんだよね。

└

自分のブログは暗号化されてないHTTP/1.1で運営してるけど、これは第三者に依存せずにオンラインでコンテンツを公開できるってことを示すためなんだ。で、WhatsappがChromeよりもひどいことに気づいたんだけど、HTTPリンクを共有してもHTTPSを開いちゃうんだよね。

└

Googleやその仲間たちはHTTPSを推進するのが好きだけど、広告やAI生成コンテンツを使って人を騙す方がずっと簡単だよね。普通のHTTPが怖いって言うのは、正直なところストローマン論法に見える。

http://www.slackware.com/ は、暗号化されたトラフィックを提供していないサイトの中で、私が知っている中で一番大きいサイトだと思うけど、他にも暗号化していない便利なリソースがいくつかあるよ。[1] （理由はわからないけど、armサブドメインでは除外されてる）

└

最初のディストロはSlackwareだった。いい思い出だな。ARMサブドメインはかなりメンテされてるみたいで、2025年の投稿もある。slackware.comのソースは絶対に見ない方がいいよ。

2012年にPandoraのプレミアムプランに登録しようとしたことをはっきり覚えてるんだけど、その時のクレジットカードフォームがHTTPで処理されてたんだよね。フォームを直してくれたらお金を払いたいってメールしたけど、結局数年返事もなかったし、修正もされなかった。だからその間にSpotifyにお金を払ってた。あの頃はHTTPSが普通じゃなかったし、人々を切り替えさせるのは大変だった。内部ネットワークや他のいくつかのことには面倒だけど、必要なことなんだよね。

└

2000年代初頭には、クレジットカードフォームにHTTPSを使うのは結構一般的だった気がする。Pandoraみたいな会社が2010年代にはそれを使ってなかったのは驚きだね。

└

2000年代初頭から中頃なら信じられるけど、2012年に大手のeコマースプロバイダーがそれをやってたとは思えないな。PCI DSSは、クレジットカード決済をオンラインで受け付けるために必要なデータセキュリティ基準だよ。2004年に1.0が出てから、カード保持者の情報を送信する際に暗号化された接続を要求する要件4.1があった。商業サイトには、製品情報やカタログ、カテゴリー、説明がHTTP（www.shop.com）で提供されていて、実際のチェックアウトプロセスはSSL/TLSを使った別のドメイン（secure.shop.com）で始まることが多かった。これは、2000年代初頭のSSLのオーバーヘッドや証明書のコストが原因だった。インテルのプロセッサがAESなどのハードウェアアクセラレーションをサポートするようになって、証明書がもっと手頃になったり、Let's Encryptが簡単にしてくれたおかげで、こういうことはほとんどなくなった。2000年代や2010年代には、HTTPで提供されていて、ターゲットがHTTPSのURLのHTMLフォームを見ることもあったけど、それも珍しかった。チェックアウトボタンが全く別のサイトに飛ぶだけの方が簡単だったからね。

さらに悪いことに、今日の多くのプレーンテキストHTTP接続はユーザーには完全に見えない。HTTPサイトはすぐにHTTPSサイトにリダイレクトされることがあるから、リスクが発生した後にChromeの「安全ではありません」っていうURLバーの警告を見る機会がないし、最初から自分を守る機会もない。具体的に何のリスクがあるの？悪意のあるHTTPSサイトへの中間者リダイレクト？

└

MITM（中間者攻撃者）がリダイレクトを悪意のあるコンテンツに置き換えることができるって、ブログに書いてあったよね。

└

そうそう、似たようなドメイン名にリダイレクトされる可能性もあるよね。

予想だけど、Wi-Fiのキャプティブポータル業者は、顧客の90%が資金不足になるまで反応しないと思う。公共のWi-Fiキャプティブポータルは、HTTPやDNSリクエストの検査が必要なハックの積み重ねで作られてることが多いんだよね。*確かにもっと良いツールはあるけど、あんまり使われてないし、ポータル、WAP、クライアントのサポートが必要なんだ。大抵の業者は、新しい fancy な機能をオフにして、HTTPSを無効にしてHTTPで進めるように言うだけだよ。

└

まあ、キャプティブポータルネットワークに接続する人は、ほとんどがスマホでやってるからね。iOSではキャプティブWi-Fiログイン用の非Safariブラウザを許可してないと思う。Androidではどうやって解決するのかは分からないけど。

└

何言ってるの？カスタムDNSサーバーを設定すれば、キャプティブポータルは簡単に作れるし、HTTPSは関係ないよ！実際、ローカルネットワークでは何年も前からこれをやってる。Appleはこのインターセプトを検出する機能もサポートしてるから、OSがユーザーにキャプティブポータルを表示できるんだ。OSメーカーはネットワーク管理者に公式な方法でキャプティブポータルを強制させる手段を提供してるし、HTTPSがあってもそれはなくならないよ。

これはユーザーにとってはいいことだけど、GoogleがChromeを所有していることで、ウェブに対する独占的な影響力を再確認させられるね。俺の会社もCDNを運営してるけど、Googleがみんなに積ませるレイヤーの多さは驚異的だよ。最初はシンプルなTCP+HTTPだったのに、HTTPSが登場してサーバーにかなりのCPU負荷をかけるようになった。その後、SPDYが生まれてHTTP2になったけど、ウェブサイトの資産使用が爆発的に増えたからね（ほとんどJS）。さらに、QUIC（社内開発）でレイヤー4を再発明してHTTP3になった。今はこれだよ。それぞれが、シンプルなメッセージやファイル交換プロトコルに、もっと複雑さとデータフレーミングを追加してる。しかも、顧客は自分のウェブサイトをチェックするためにウェブサイトチェッカーに入れて、すべてのトラフィックライトが緑であることを望んでいるから、オプトアウトできないんだ。

正直言って、これはちょっと残念だね。HTTPSはすごく重要だけど、年に一度しか読まないかもしれないブログXが本当にそのブログなのか確認する必要があるのかな？多くのサイトにとってはあまり意味がないけど、人間の性質からこうなってるんだよね。

└

問題はサイトじゃなくて、その間のネットワークなんだ。パス上の攻撃者は、広告を表示したり、トラッキングトークンを挿入したり、他の目的でブラウザをハイジャックするために、どのサイトをMITMするかなんて気にしないんだよ。サイトはベクトルであって、ターゲットじゃない。

httpsに対する唯一の課題は、httpと比べて証明書が必要なことだね。証明書がなければ、ローカルホストや社内イントラネットを含めて、どこでも数秒でhttpsサーバーを立てられるのに。あと、個人的にはhttpsをデフォルトにするのはやめて、WSS（TLS WebSockets）に直接行きたいな。WebSocketsは、HTTPに比べて全ての面で優れてるけど、HTTPがセッションレスなところだけはちょっと違うんだよね。