管理

HTTPとHTTPSの違い:鍵マークが保証すること・しないこと

この記事はAIの支援を受けて原文を翻訳したものです。専門用語や数式は原文とあわせて確認してください。

HTTPSとは、HTTPの通信を暗号化プロトコルのTLSの上で行う仕組みです。この接続で保証されるのは、ネットワーク上の第三者が送受信の内容を読めないこと、内容を書き換えられたら検知できること、そして接続先のサーバーがアドレスバーのドメインについて有効な証明書を持っていることの3つです。一方、サイトそのものが誠実かどうかは保証されず、鍵マーク(Chromeでは新しい「調整アイコン」)が示すのも通信の状態であって、運営者の信頼性ではありません。フィッシングサイトのほとんどもHTTPSを使っています。

HTTPとHTTPSを並べた比較図。HTTP(http://、標準ポート80)では、読み取れるパスワードを含むログイン要求がブラウザからWebサイトへ届き、Wi-Fi・ルーター・ISPの経路上にいる人がページやパスワードを読み、検知されずにページを書き換え、サイトになりすませる。HTTPS(https://、標準ポート443)では、同じ要求が暗号化されたデータとしてトンネルの中を通り、経路上の人に見えるのはドメイン名、IPアドレス、データ量だけ。
図1. HTTPでは、経路上の誰もが通信の内容を読み、書き換えられます。HTTPSなら、通信の宛先とデータ量は見えても、内容は見えません。ログインの値は例です。

HTTPとHTTPSの違い:「S」が加えるもの

HTTPは、ブラウザとサーバーがページを要求し、受け渡すための取り決めです。そのままでは、通信の中身が平文(暗号化されていない文字列)で流れます。HTTPSは、同じ要求と応答をTLS(Transport Layer Security)の中に入れて送ります。TLSはSSLというプロトコルの後継で、いまも「SSL証明書」と呼ばれるのはそのためです。SSL 3.0は2015年に正式に非推奨となり、TLS 1.0と1.1も2021年に続きました。現在使われているのはTLS 1.2と1.3です。

項目HTTPHTTPS
アドレスの先頭http://https://
標準のポート番号80443
ネットワーク上での内容経路上の誰でも読める暗号化される
通信中の改ざん気づけない検知され、接続が失敗する
サーバーの身元確認なしそのドメインに対する有効な証明書が必須
Chromeのアドレスバー「保護されていない通信」中立的な調整アイコン

TLS 1.3の仕様(RFC 8446)は、TLSが提供する性質を次の3つで整理しています。

  • 機密性:接続が確立したあとは、ブラウザとサーバーだけがデータを読めます。ドメインの後ろにあるページのパス、フォームの入力内容、パスワード、Cookieもここに含まれます。
  • 完全性:通信中のデータを、検知されずに書き換えることはできません。たとえば、カフェのルーターがページに広告やマルウェアを紛れ込ませても、改ざんとして検知されます。
  • 認証:サーバーは必ず証明書で自分の身元を示します。一方、ブラウザ(クライアント)側は、通常は身元を示しません。

ただし、限界も2つあります。1つは、TLSが送受信するデータの量までは隠さないこと。もう1つは、ドメイン名が通常は見えたままであることです。端末はDNSでドメイン名を問い合わせ、最初のハンドシェイクのメッセージでもサイト名を相手に伝えるためです。暗号化DNSや、新しい拡張のEncrypted Client Hello(ECH)を使えば隠せますが、通信する双方が対応している場合に限られます。

HTTPS接続はどう始まる? TLSハンドシェイクの流れ

ページ本体を要求する前に、ブラウザとサーバーはTLSハンドシェイクを行います。TLS 1.3では、これが1往復で終わります。

  1. ClientHello。ブラウザが、接続したいサイト名、対応しているTLSのバージョンと暗号方式の一覧、そして鍵交換に使う自分側の値(鍵共有値)を送ります。
  2. ServerHello。サーバーが使う方式を選び、自分側の値を返します。これで双方が同じセッション鍵を計算できます。鍵そのものはネットワークを流れず、この先のやり取りはすべて暗号化されます。
  3. 証明書と署名。サーバーが証明書を送り、対応する秘密鍵でハンドシェイクの内容に署名します。証明書をコピーしただけの偽物ではなく、秘密鍵を持つ本人であることを示すためです。
  4. ブラウザによる確認。証明書が、ブラウザやOSの信頼する認証局(CA)までたどれること、訪問先のドメイン名が書かれていること、有効期間内であることを確かめます。
  5. 暗号化されたHTTP。ハンドシェイクの内容が途中で変えられていないことを双方が確認し、通常のリクエストとレスポンスが暗号化された通路を流れ始めます。
ブラウザとWebサーバーの間で行われるTLS 1.3ハンドシェイクを簡略化したシーケンス図。1 ClientHello(サイト名、TLSバージョン、鍵共有値)、2 ServerHello(サーバーの鍵共有値。この時点で双方が同じセッション鍵を計算する)、3 暗号化されたCertificate・署名・Finished、4 ブラウザが証明書を確認(信頼できるCA、ドメインの一致、有効期限内)。失敗するとChromeは「この接続ではプライバシーが保護されません」と表示、5 双方向の暗号化されたHTTP。
図2. TLS 1.3ハンドシェイクの簡略図。手順4の証明書チェックが、なりすましサーバーを防ぎます。セッション鍵は双方で計算され、通信路に送られることはありません。

手順4で確認に失敗すると、ブラウザは処理を止めて全画面の警告を出します。Chromeなら「この接続ではプライバシーが保護されません」という画面です。これは、HTTPSがなりすましの可能性を見つけたときの反応で、単なる不具合として読み飛ばしてよいものではありません。証明書の期限切れでも同じ警告が出ますが、ログインや支払いのあるサイトでは進まないのが原則です。

鍵マークが教えてくれないこと

証明書が証明するのは、そのドメイン名を誰が管理しているかであって、その事業を誰が運営しているか、誠実かどうかではありません。基本となるのはドメイン認証(DV)型で、認証局は申請者がドメインを管理していることだけを確認します。たとえば、指定されたファイルやDNSレコードを公開してもらう方法です。無料で自動化された認証局であるLet’s Encryptが発行するのはDV証明書だけで、有効期間は標準で90日です。これはHTTPSの普及を後押ししましたが、同時に、架空のアドレス(たとえば yourbank.com.verify-login.net)に置いたフィッシングページでも、有効な証明書を取得できることを意味します。ブラウザは「安全な接続」と正しく報告しますが、その接続先は目的のサイトではありません。

2列のチェックリスト。接続について保証されること:通信内容の機密性、完全性、表示中のドメインに対するサーバー認証。サイトについて保証されないこと:意図したサイトであること、運営者が誠実であること、届いた後もデータが安全に扱われること、ダウンロードしたファイルが安全であること、アクセスが誰にも見えないこと(ドメイン名とIPアドレスは見えたまま)。
図3. HTTPSが守るのは、ブラウザとサーバーの間の通り道です。そのサーバーが信頼できる相手のものかどうかは、別の問題です。
証明書の種類認証局が確認すること利用者にわかること
DV(ドメイン認証)ドメインの管理権限このサーバーがその名前を使う権限を持つ、という点だけ
OV(企業実在認証)ドメインの管理権限に加え、組織の登記情報証明書の詳細に会社名が載る
EV(EV認証)組織の法的な実在性をより厳しく確認OVと同じ。Chromeは2019年のバージョン77で、会社名の表示をアドレスバーの外に移した

また、HTTPSはダウンロードしたファイルのマルウェアを検査するものではなく、サーバーに保存されたあとのデータを守るものでもありません。手元の端末がすでに感染していれば、役には立ちません。

Chromeが鍵マークを調整アイコンに変えた理由

鍵マークは、HTTPSがまだ珍しかった時代の名残です。Googleによると、2013年にHTTPSに対応していた上位100万サイトは14%にとどまりましたが、2023年にはWindows版Chromeのページ読み込みの95%超がHTTPSでした。2021年のGoogleの調査では、鍵マークの意味を正しく理解していた参加者は11%だけで、多くの人が「このサイトは信頼できる」という意味に受け取っていました。フィッシングサイトのほとんどが同じ鍵マークを表示するため、この誤解は危険です。実際、FBIも2019年に、鍵マークや「https」だけを理由にサイトを信用しないよう注意を呼びかけていました。

2023年9月に公開されたChrome 117では、デスクトップ版とAndroid版で、鍵マークが中立的な調整アイコン(スライダーが2本並んだ形)に置き換わりました。クリックするとサイト情報や設定が開きます。HTTPのページについては、2018年7月のChrome 68以来、引き続き「保護されていない通信」と表示されます。さらに2025年10月、Googleは「常に安全な接続を使用する」設定を標準で有効にする計画(Chrome 154で予定)を発表しました。HTTPSに対応していない公開サイトを開く前に、Chromeが確認を求める仕組みです。

Chromeのセキュリティ表示の年表。2013年:上位100万サイトのうちHTTPS対応は14%。2018年7月:Chrome 68がすべてのHTTPページに「保護されていない通信」と表示。2021年:Chromeの調査で鍵マークの意味を理解していた参加者は11%。2023年9月:Chrome 117が鍵マークを中立的な調整アイコンに置き換え。2025年10月:Googleが、HTTPの公開サイトを開く前に確認を求める計画を発表。2023年までにWindows版Chromeのページ読み込みの95%超がHTTPSだった。
図4. HTTPSが当たり前になるにつれ、Chromeのアドレスバー表示は「HTTPには警告を出し、HTTPSを信頼の印として見せない」方向へ変わってきました。数値はGoogleのChromeに関する発表によるものです。

パスワードやカード番号を入力する前の確認事項

  1. 本当のドメインを読む。https:// の後ろから最初の「/」までの部分に注目し、右側から読みます。yourbank.com.verify-login.net なら、実際のサイトは yourbank.com ではなく verify-login.net です。
  2. 安全な経路で開く。メールやSMS、QRコードのリンクをたどらず、アドレスを自分で入力するか、ブックマークから開きます。
  3. 証明書の警告は押し切らない。ログインや支払いをするサイトで警告が出たら、先へ進まずにタブを閉じます。
  4. パスワードマネージャーやパスキーにドメインを確認させる。これらは保存したサイトでしか認証情報を差し出さないので、そっくりなページには何も渡りません。
  5. 「保護されていない通信」では重要な情報を入力しない。HTTPのページでは、入力した内容が平文のままネットワークを流れるためです。
  6. アイコンの外側も見る。不自然に急かす文面、頼んでいないログインの要求、安すぎる価格のほうが、アドレスバーのどんな記号よりも確かな警告サインです。

よくある質問

公共Wi-Fiでも、HTTPSなら十分ですか?

通信の内容は、同じWi-Fiの他の利用者やアクセスポイントの運営者から守られます。ただし、どのドメインにアクセスしているかは見えます。偽のアクセスポイントは、証明書の警告を出さずにHTTPS通信の中身を読むことはできませんが、そっくりなサイトへ誘導することはできます。ドメインの確認は欠かせません。

無料の証明書は、有料のものより安全性が低いのですか?

通信の安全性については、そうではありません。暗号の強さを決めるのは、サーバーが使うTLSのバージョンや設定であり、証明書の値段ではありません。有料のOV・EV証明書には組織の審査が加わりますが、ChromeもSafariも、もうアドレスバーでは目立たせていません。

会社や学校は、自分のHTTPS通信を見られますか?

通常、見えるのはドメインまでで、内容は見えません。ただし、組織が管理する端末では、組織が独自のルート証明書をインストールし、セキュリティゲートウェイを通じてHTTPS通信を検査できます。その場合、ブラウザの警告は出ません。自分で管理していない端末では、検査される可能性があると考えてください。

出典:IETF RFC 8446「TLSプロトコル バージョン1.3」、Chromium Blog「鍵アイコンに関する更新」(2023年)、FBI IC3「フィッシングに悪用される『安全な』サイト」(2019年)、Let’s Encrypt よくある質問

関連記事

本文の理解を助けるために制作したオリジナルイラストです。