こんにちは、かつコーチです。
前回はHTTPメソッド（GET・POST・PUT・DELETE）の使い分けを解説しました。
今回は、URLの先頭が「http://」ではなく「https://」になっている、あの「s」の正体を掘り下げます。
ブラウザのアドレスバーに表示される鍵マークの意味、そしてSSL/TLSという言葉が指す仕組みまで、順を追って理解していきましょう。
HTTPSとは？
封筒に鍵をかけて送る仕組み
以前の記事で、HTTPは「手紙のやり取り」に例えられると説明しました。
ただし通常のHTTPは、封筒に入れずにはがきのまま手紙を送っているようなものです。
内容を誰でも読めてしまいますし、途中で書き換えられても気づけません。
HTTPS（HTTP Secure）とは、この手紙を封筒に入れ、さらに鍵をかけてから送る仕組みのことです。
封筒に鍵をかける役割を担っているのが、SSL/TLS（Secure Sockets Layer / Transport Layer Security、通信を暗号化するための技術）です。
現在主流なのはTLSで、SSLは古い呼び方ですが、慣習的に「SSL/TLS」とまとめて呼ばれることが多くなっています。
なぜHTTPSが必要なのか
HTTPのまま通信すると、次のようなリスクがあります。
- 通信内容を第三者に盗み見られる（盗聴）
- 通信内容を途中で書き換えられる（改ざん）
- 偽サイトに誘導されても気づけない（なりすまし）
特にログインフォームやクレジットカード情報を扱うサイトでは、封筒に鍵をかけずに送るようなHTTP通信は許容できません。
現在はChromeなどの主要ブラウザが、HTTPのままのサイトに「保護されていない通信」という警告を表示するようになりました。
さらにGoogleは検索順位を決める要素の一つにHTTPS化を含めているため、SEOの観点でもHTTPS化はもはや必須の対応です。
SSL/TLSによる暗号化の仕組み
公開鍵と共通鍵、2種類の鍵の役割分担
封筒に鍵をかけると言っても、実際には2種類の鍵が組み合わさっています。
公開鍵暗号方式は、誰でも使える「鍵をかける専用の鍵（公開鍵）」と、持ち主だけが持つ「開ける専用の鍵（秘密鍵）」の組み合わせです。
共通鍵暗号方式は、送信者と受信者が同じ1本の鍵を共有し、その鍵で施錠と開錠を両方行う方式です。
共通鍵暗号は処理が速い一方、鍵そのものを安全に相手へ渡す方法が課題になります。
そこでTLSでは、最初に公開鍵暗号で共通鍵を安全にやり取りし、その後の実際の通信は高速な共通鍵暗号で行う、という2段構えの仕組みを採用しています。
TLSハンドシェイクの流れ
通信の最初に行われる、鍵の受け渡しと確認の手順をTLSハンドシェイクと呼びます。
大まかな流れは次のとおりです。
- クライアントが「これから暗号化通信をしたい」とサーバーに伝える
- サーバーが自分の身元を証明するSSL証明書（運営者情報や公開鍵が記載された電子的な証明書）を送る
- クライアントが証明書を検証し、共通鍵の元になる情報を公開鍵で暗号化して送る
- 双方が共通鍵を持った状態になり、以降は共通鍵で暗号化した通信を行う
このやり取りが、ページを開くたびに一瞬で行われています。
よくあるつまずきポイント・エラー対処
証明書エラーとMixed Content
以前、既存サイトをHTTPからHTTPS化する作業を担当した際、切り替え直後にブラウザのコンソールに警告が大量に出て焦ったことがあります。
原因は、CSSやJavaScriptの中で画像パスをhttp://example.com/img.pngのように絶対パスでhttp指定していたことでした。
ページ自体はHTTPSで暗号化されているのに、一部の画像だけHTTPで読み込もうとするため、ブラウザがMixed Content（保護された通信の中に保護されていない通信が混在する状態）として警告を出していたのです。
<!-- ❌Before：http固定で書かれた画像パス -->
<img src="http://example.com/img/logo.png">
<!-- ✅After：httpsに統一するか、プロトコル省略で記述 -->
<img src="https://example.com/img/logo.png">
<img src="//example.com/img/logo.png">
このときは、サイト内の画像・CSS・JSのパスをすべてhttps固定、もしくはプロトコル省略の記述に置き換えて解決しました。
証明書自体のエラー（期限切れ、ドメイン不一致など）が出ている場合は、Let’s Encryptなどの証明書発行サービスの更新設定を見直すのが第一歩です。
応用・一歩先の使い方
HTTP/2・常時HTTPS化との関係
現在広く使われているHTTP/2（1本の接続で複数のリクエストを効率よく処理できる新しいHTTPの規格）は、事実上HTTPS上でしか動作しません。
つまりHTTPS化は、セキュリティ対策であると同時に、通信を高速化するための前提条件にもなっています。
サイト全体を常にHTTPSで提供する常時HTTPS化が現在の標準で、HTTP接続をHTTPSへ自動転送する設定は、Webサーバー構築の基本作業の一つです。
Let’s EncryptのようなDV証明書を使えば、無料かつ自動更新の仕組みで常時HTTPS化を実現できます。
まとめ
この記事のポイント
- HTTPSは「封筒に鍵をかけて送る」ように、HTTP通信をSSL/TLSで暗号化する仕組み
- 公開鍵暗号で共通鍵を安全に受け渡し、以降は共通鍵暗号で高速に通信する
- Mixed Contentは、HTTPS化したのに一部リソースがHTTPのままのときに発生する
- HTTP/2の利用や検索順位の観点からも、常時HTTPS化は必須の対応
次に読むべき記事
- OSI参照モデルとは？通信を7つの階層で理解する
- TCPとUDPの違い：確実さとスピードのトレードオフ
タグ: ネットワーク, 中級者向け, HTTP