HTTP と HTTPS の違いを、暗号の仕組みから本質的に理解する

先日、当社ウェブサイトをようやく HTTPS 化しました。「当たり前でしょ」と思うかもしれませんが、そもそもなぜ HTTPS が必要なのかをきちんと説明できる人は意外と少ないものです。

この記事では、HTTP と HTTPS の違いを暗号の仕組みから順番に解説していきます。

HTTP と HTTPS の違い

アドレスバーを見てみると http:// で始まるサイトと https:// で始まるサイトがあります。https:// の末尾の S は Secure（安全）の S です。

ブラウザはサイトが HTTPS でない場合、アドレスバーに「保護されていない通信」と表示します。

HTTP が危ない理由

HTTP は通信内容が 平文（暗号化されていない生のテキスト） でやり取りされます。これがどれほど危険かを3つの観点から見てみましょう。

盗聴

カフェや空港の公共 Wi-Fi を使っているとき、同じネットワークにいる第三者があなたの通信を盗み見ることができます。HTTP のままでは、入力したパスワードやフォームの内容がそのまま流れます。

改ざん

通信の途中でコンテンツを書き換えられる危険があります。広告を勝手に差し込まれたり、フォームの送信先を攻撃者のサーバーに変えられたりといった攻撃が実際に起きています。

なりすまし

本物のサイトに見せかけた偽サイトと通信していても、HTTP だけでは区別する手段がありません。

一言でまとめると：HTTP はハガキ、HTTPS は封書です。 ハガキは配達する人が全員中身を読めますが、封書は封を開けない限り読めません。

暗号化の基本① 共通鍵暗号方式

HTTPS の仕組みを理解するには、まず2種類の暗号方式を知る必要があります。

共通鍵暗号方式は、送る側と受け取る側が同じ鍵を使って暗号化・復号する方式です。

鍵が1本で済むので処理が速く、大量のデータを暗号化するのに向いています。

しかし、致命的な問題があります。 鍵をどうやって相手に渡すか、です。

鍵を安全に渡すためには、安全な通信経路が必要です。でも安全な通信経路があるなら、最初からそれを使えばよい話です。これを 「鍵配送問題」 といいます。

暗号化の基本② 公開鍵暗号方式

この問題を解決したのが公開鍵暗号方式です。この方式では、2本1セットの鍵を使います。

• 公開鍵：誰にでも配っていい鍵
• 秘密鍵：自分だけが持つ鍵

ポイントは次の2つのルールです。

1. 公開鍵で暗号化したデータは、秘密鍵でしか復号できない
2. 秘密鍵で暗号化したデータは、公開鍵でしか復号できない

南京錠で考えるとわかりやすいです。

南京錠（公開鍵）は誰でも入手できます。あなたはその南京錠を使って箱に鍵をかけて送ります。箱を開けられるのは、南京錠の鍵（秘密鍵）を持っている本人だけです。

※ このたとえは「公開鍵で暗号化・秘密鍵で復号」という暗号化通信の方向性を説明したものです。公開鍵暗号にはデジタル署名（秘密鍵で署名・公開鍵で検証）という逆方向の使い方もありますが、本記事では HTTPS の暗号化通信に絞って説明しています。

公開鍵はインターネット上にばらまいても問題ありません。それで暗号化されたデータは、対応する秘密鍵がなければ絶対に開けられないからです。

ただし欠点があります。 公開鍵暗号方式は計算量が多く、処理が重いため、大量のデータをリアルタイムで暗号化するのには向いていません。

なお、公開鍵暗号の実装には複数の方式があります。かつては RSA（大きな数の素因数分解の困難さを利用）が主流でしたが、現在の HTTPS では 楕円曲線暗号（ECC） が広く使われています。楕円曲線暗号は RSA より短い鍵長で同等の安全性を実現できるため、処理が速く、スマートフォンなどの非力なデバイスにも向いています。詳細な数学は省きますが、「今の HTTPS は楕円曲線という数学的構造を使った暗号で守られている」と覚えておくと良いでしょう。

HTTPS は2つの方式を組み合わせている

ここが話の核心です。

HTTPS（正確には TLS という仕組み）は、公開鍵暗号と共通鍵暗号を組み合わせることで、それぞれの弱点を補っています。

通信が始まるとき、次のような作業（TLS ハンドシェイク）が行われます。

① サーバーが公開鍵をブラウザに送る（SSL証明書付き）
② ブラウザが共通鍵を生成し、公開鍵で暗号化してサーバーに送る
③ サーバーが秘密鍵で復号して共通鍵を入手する
④ 以降の通信は共通鍵を使って高速にやり取りする

つまり、「安全な鍵の受け渡しに公開鍵暗号を使い、実際の通信は速い共通鍵暗号で行う」 という構造です。

役割	方式
共通鍵を安全に渡す	公開鍵暗号（遅いが安全）
実際のデータ通信	共通鍵暗号（速い）

SSL 証明書とは何か

「サーバーが公開鍵を送る」と書きましたが、その公開鍵が本物かどうかはどうやって確かめるのでしょうか。

ここで登場するのが SSL 証明書です。証明書には次の情報が含まれています。

• このドメインの公開鍵
• 認証局（CA）による署名「この公開鍵は本物です」という第三者のお墨付き

認証局は厳しい審査を経てブラウザに信頼された機関です。ブラウザはサーバーから受け取った証明書を確認し、信頼できる認証局の署名がなければ警告を表示します。

証明書のない自己署名証明書（いわゆる「オレオレ証明書」）は、「私は本物です、私が証明します」と自分で言っているようなもので、ブラウザに警告されます。

HTTPS にしないと起きること

技術的な話だけでなく、ビジネス上の影響もあります。

ブラウザの警告表示

Chrome や Safari は HTTP サイトに対して「保護されていない通信」と表示します。サイト運営者に悪意がなくても、訪問者には警告として見えてしまうため、意図せず信頼性に影響することがあります。

検索順位への影響

Google は 2014 年から HTTPS を検索順位のシグナルとして採用しています。コンテンツの質が最優先である点は変わりませんが、内容が同等であれば HTTPS のサイトが有利に働きます。

フォーム入力時の不安

お問い合わせフォームや個人情報の入力ページが HTTP のままでは、お客様の情報が平文で流れます。信頼性の問題だけでなく、情報漏洩のリスクもあります。

まとめ

	HTTP	HTTPS
通信内容	平文（丸見え）	暗号化済み
盗聴	される可能性あり	暗号化で防御
改ざん	される可能性あり	検知・防御できる
なりすまし	判別できない	証明書で確認できる
SEO	不利	有利

HTTPS の仕組みをまとめると、

• 共通鍵暗号：速いが鍵の受け渡しが問題
• 公開鍵暗号：安全に鍵を渡せるが遅い
• HTTPS（TLS）：公開鍵で共通鍵を安全に渡し、あとは共通鍵で高速通信

という3層の構造になっています。

毎日何気なく使っているブラウザの裏側では、こうした暗号技術が絶え間なく動いています。「HTTPS の方が何となく安全そう」から一歩進んで、なぜ安全なのかを理解するきっかけになれば幸いです。