HTTPとHTTPS（TLS） ― 何が違うのか

HTTPSは、Webの通信に使うHTTPを、TLS（Transport Layer Security）という暗号化のしくみで包んだものです。TLSが、HTTPに暗号化・改ざん検知・相手の確認の3つを足します。

HTTPは、Webブラウザとサーバがデータをやり取りするための取り決めです。このような取り決めをプロトコルと呼びます。ただし、HTTP自体には暗号化のしくみがありません。通信の中身は、そのまま経路を流れます。

OSI参照モデルの分類では、HTTPは第7層のアプリケーション層にあたります。TLSは、第6層のプレゼンテーション層の仕事です。

HTTP通信の基本は単純です。ブラウザなどのクライアントが、リクエストを1回送ります。サーバは、レスポンスを1回返します。この1往復の繰り返しで、Webページは組み立てられています。1つのページを表示するために、HTMLや画像・CSSの数だけこの往復が発生します。

GET /articles/http-https/ HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

# 1行目：メソッド（GET） パス（/articles/http-https/） バージョン
# 2行目以降：ヘッダ（宛先ホスト名や使用ブラウザなどの付加情報）

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 5120

<html>...</html>

# 1行目：バージョン ステータスコード（200） 理由句（OK）
# 2行目以降：ヘッダ、空行を挟んで本文（実際に表示するHTML本体など）

リクエストの1行目にあるメソッドは、何をしたいかを表します。主なものは次の4つです。

このGET・POSTなどのメソッドは、ネットワーク機器をREST APIで操作するときにも使われます。機器の操作への当てはめ方は、ネットワーク自動化の記事で説明しています。サービスが出来事を知らせるときにPOSTを送るWebhookも、同じHTTPの上で動きます。

レスポンスの1行目にあるステータスコードは、結果がどうだったかを3桁の数字で表します。401と403、502と504のように似た番号の違いや、画面に出た番号から調べる場所は、HTTPステータスコードの記事にまとめています。代表的なものは次の4つです。

この往復は、決まったポート番号に向けて行われます。URLの先頭がhttp://なら80番、https://なら443番です。アクセスの多いサイトでは、この往復を受け止めるサーバを複数台並べます。届いたリクエストは、ロードバランサが各サーバに分けます。

HTTPのリクエストとレスポンスは、暗号化されずに、先ほどの例で見たような文字列のまま経路を流れます。家庭内LANからインターネットに出るまでの間には、公衆Wi-Fiのアクセスポイントやプロバイダのルータなど、いくつもの中継地点があります。そこに悪意のある第三者がいれば、通信の中身をそのまま読むことも、途中で書き換えることもできてしまいます。

ログインフォームに入力したパスワードやクレジットカード番号、Cookieに入った認証情報も同じです。HTTPのまま流れていれば、それらはすべて経路上の第三者に読まれる可能性があります。Cookieを盗まれるとログイン中の利用者になりすまされる理由は、Cookieの記事を読むと分かります。

書き換えの被害も深刻です。表示されるはずのないページに差し替えられたり、広告や不正なスクリプトを勝手に埋め込まれたりすることもあります。

ファイル転送のFTPや遠隔操作のTELNETも、パスワードを含めて平文で送ります。これらには、通信を暗号化するSSH・SFTP・FTPSという代わりがあります。その違いは、FTP・TELNET・NTPの記事にまとめています。

TLSは、HTTPの下に入って通信路を保護するしくみです。HTTPの中身自体を書き換えるものではありません。HTTPSはHTTPとTLSを組み合わせた構成で、TLSが次の3つを足します。

1. 1

   暗号化

   中身を読めない形に変換します。経路上の第三者が盗み見ても、内容が分かりません。

2. 2

   改ざん検知

   途中で内容が書き換えられていないかを、受け取った側が確認できます。

3. 3

   相手の確認

   証明書によって、通信相手が本当にそのドメインの持ち主かを確かめます。

HTTPでは、クライアントとサーバが平文のまま直接つながります。平文とは、暗号化していないデータのことです。

HTTPSでは、その間に準備の段階が入ります。この段階をTLSハンドシェイクと呼びます。ここで証明書の確認と鍵の共有を済ませてから、暗号化した通信に切り替わります。

この段階があるのは、接続を確立するときの1回だけです。リクエストのたびに繰り返すわけではありません。1回の接続あたりの手間は増えますが、経路上の第三者から内容を守れます。

最近は、HTTP/2やHTTP/3という新しいバージョンも使われています。HTTP/2は、1本のTCP接続の上で、複数のリクエストを並行して送れるようにしたものです。

HTTP/3は、QUICという通信路を使います。QUICは、TCPではなくUDPをベースにしています。いずれも、リクエストを送ってレスポンスを受け取る基本のやり取り自体は変わりません。HTTP/2との違いとUDPを使う理由は、HTTP/3とQUICの記事で説明しています。

TLSハンドシェイクは、実際のデータをやり取りする前に、クライアントとサーバが行う準備の手続きです。

HTTP/1.1やHTTP/2では、TCPの3ウェイハンドシェイクの上でTLSを行います。この場合は、TCPのコネクションが確立した後に、TLSハンドシェイクが始まります。ただし、HTTP/3が使うQUICは、TCPを使わずにUDPの上で通信を確立します。そのため、TCPの後にTLSという順序は、HTTP/3には当てはまりません。

いずれの場合も、目的は2つあります。相手が本物かを確認することと、その後の暗号化に使う鍵を安全に共有することです。なお、宛先のサーバにつながるには、まずDNSでホスト名からIPアドレスが分かっている必要があります。

現在主流のTLS 1.3は、RFC 9846で定められています。TLS 1.3では、まず①で、クライアントとサーバが鍵の材料を交換します。それぞれが同じ計算をすることで、同じ共通鍵を導き出します。

次に②で、サーバは証明書と署名を送ります。この署名は、ここまでのやり取り全体に、サーバが自分の秘密鍵で付けたものです。このとき証明書と署名は、①で導いた鍵ですでに暗号化されています。

証明書には、サーバの公開鍵とそのドメインの情報が入っています。ただし、証明書は誰でも写しを送れてしまいます。これだけでは、相手が本物のサーバとは限りません。

そこでクライアントは、③で2つを確認します。1つは、証明書が信頼できる認証局の署名を持っているかです。これは、証明書の内容が改ざんされていないかの確認にあたります。認証局は証明書を発行する機関で、CAとも呼びます。

もう1つは、②でサーバが付けた署名が正しいかの確認です。この確認には、証明書に入っている公開鍵を使います。この確認に成功すれば、相手が確かにその証明書の秘密鍵を持つ本物のサーバだと分かります。

ここまでの鍵交換と確認が済むと、④に進みます。以降のリクエストとレスポンスの本文は、通信用の共通鍵で暗号化してやり取りします。つまり、公開鍵暗号が使われるのは、①〜③の鍵の共有と相手の確認だけです。実際のページの内容そのものは、共通鍵暗号でやり取りされます。

なお、TLS 1.2以前では順序が違いました。証明書は暗号化されずに先に送られ、その後で鍵交換の情報が送られていました。

TLS 1.2までは、クライアントが共通鍵のもとを、証明書の公開鍵で暗号化してサーバに送る方式もありました。この方式をRSA鍵交換と呼びます。RSA鍵交換は、TLS 1.3で廃止されています。

SSLとTLSの関係、バージョンごとの違い、メッセージごとに第三者から何が見えるかは、SSL/TLSの記事で追えます。

鍵の種類ごとに、得意なことと苦手なことがあります。共通鍵暗号は、処理が軽く高速です。代表的な方式に、AESがあります。2つの暗号の違いそのものは、共通鍵暗号と公開鍵暗号の違いの記事で説明しています。

ただし、通信を始める前に、クライアントとサーバが同じ鍵をあらかじめ共有している必要があります。問題は、初対面のクライアントとサーバが、どうやって同じ鍵を安全に渡すかです。間の経路は、盗聴される可能性があります。

公開鍵暗号のしくみは、この問題を解決できます。鍵を共有する方式で現在主流なのは、ECDHEです。ECDHEでは、クライアントとサーバが、それぞれ公開鍵と秘密鍵の組を作ります。

公開鍵同士を交換するだけで、両者だけが同じ共通鍵を計算できます。第三者は公開鍵を盗み見ても、秘密鍵を知らなければ同じ共通鍵を作れません。

ただし、この計算は共通鍵暗号より処理が重いという欠点があります。Webページの本文をすべて公開鍵暗号のしくみでやり取りすると、通信が遅くなってしまいます。

そこでTLSは、2つを使い分けます。処理が重い公開鍵暗号は、最初の鍵の受け渡しという小さな仕事だけに使います。鍵さえ安全に渡せてしまえば、あとは処理が軽い共通鍵暗号に切り替えて、本文をやり取りします。そのため、TLSハンドシェイクのあとも、通信は暗号化されたまま高速に進みます。

証明書には、ドメイン名・サーバの公開鍵・発行したCAの名前・署名などが記載されています。認証局は、証明書を発行する前に、申請した人が本当にそのドメインの持ち主かを確認します。問題がなければ、自分の秘密鍵で証明書に署名します。

ブラウザは、信頼できるCAの一覧をあらかじめ持っています。この一覧をもとに、証明書の署名が正しいかどうかを検証します。

証明書が保証しているのは、証明書に書かれたドメインの持ち主であることだけです。安全なサイトであることは保証しません。

ブラウザの鍵マークが示すのは、通信が暗号化されていることです。相手がドメインの持ち主として確認が取れていることも示します。そのサイトに載っている内容が安全かどうか、詐欺目的のサイトかどうかまでは示しません。

鍵マークがあっても、油断はできません。フィッシングサイトの見分け方は、別に必要です。盗まれたIDとパスワードが悪用される手口と対策は、不正アクセスの記事にあります。HTTPSでも、入力欄から送られた値を悪用する攻撃は防げません。その例がSQLインジェクションとXSSです。

証明書の中身、ルート証明書から続くチェーンの検証、失効の確かめ方は、電子証明書とPKIの記事で説明しています。

TLSによる暗号化は、情報セキュリティの3要素のうち機密性を守る技術にあたります。3要素の考え方と、他の技術との対応は情報セキュリティの3要素の記事で整理しています。

なお、社内ネットワークなどでは、フォワードプロキシを経由してHTTPSサイトを見ることがあります。その場合は、CONNECTメソッドを使ってプロキシ経由のトンネルを開きます。プロキシは、そのトンネルの中を素通しするだけです。

プロキシは通常、暗号化された中身までは読めません。プロキシの仕組みと中身が見えない理由は、プロキシの記事で解説しています。

一方、CDNを使うサイトでは、ブラウザのTLSの接続はCDNのエッジサーバで終わります。エッジサーバが証明書を持つ理由は、CDNの記事を読むと分かります。

HTTPSの通信をキャプチャすると、何が読めて何が読めないかはWiresharkの記事で試せます。