SSL/TLSとは? HTTPSの暗号化・証明書・ハンドシェイクをやさしく解説

ブラウザとWebサーバー間のHTTPS/TLS通信と、機密性・完全性・真正性の3つの性質を示す図解 IT
TLSは、盗み見を防ぐ機密性、改ざんを検知する完全性、証明書で接続先を確認する真正性を提供します。

私がインターネットに触れ始めたのは、1995年くらいからです。当時はSSLが登場して間もない時期で、現在のように広く使われていたわけではありません。ほとんどのWebサイトは、暗号化されていないTCP/IP通信上のHTTP(Hyper Text Transfer Protocol)で動いていました。(例えば「http://www.xxxxx.ac.jp」みたいな感じ)

いま振り返れば、通信内容が第三者から見えてしまう可能性があるのですから、ずいぶん無防備にも思えます。しかし当時は、Web通信を常に暗号化すべきという認識も、利用者の意識も、現在ほど強くありませんでした(そもそもインターネット利用者自体が少なかった)。インターネットは内容が見えるはがきを何人もの手を経由して送るような仕組みでしたが、そういうものだという認識だったし、なにより世界中に向けて情報を発信できるという開放感や高揚感もあり、ある種の楽観的な雰囲気があったことも事実だと思います。

それから長い時を経て、いまではWebサイトのURLは「https」で始まるのが当たり前になりました。皆さんもご存じのようにインターネットは30年を経てあらゆる人、あらゆるシステム、あらゆるデータが接続されて、注意深くアクセスすべきサイバースペースへと変貌しています。「https(HTTPS)」は通信を守る仕組みとしてインターネットにアクセスする上で必須の条件になったのです。

HTTPSの背後で、ブラウザとWebサーバーの間に暗号化された通信路を作っているのがTLS(Transport Layer Security)です。TLSは内容を読まれにくくするだけでなく、途中での改ざんを検知し、接続先のサーバーが意図した相手かを証明書で確認する役割も担います。

本記事では、SSLとTLSの違い、HTTPSとの関係、証明書やハンドシェイクの役割を、一枚の地図のように整理します。読み終わるころには、ブラウザの鍵マークの裏側で何が行われているのかを、自分の言葉で説明できるようになるはずです。

HTTPSが当たり前ではなかったころ

以前のWebでは、ニュースや個人サイトなど、多くのページがHTTPのまま提供されていました。ネットワークを流れるデータは基本的に平文で、途中から読まれたり、気付かないうちに書き換えられたりする余地がありました。ログイン画面や決済画面だけHTTPSに切り替えるサイトも珍しくありませんでした。

その後、Webサービスが扱う情報が増え、常時HTTPS化が進みました。現在のHTTPSは、特別なページだけを守る仕組みではなく、普段の閲覧を含めたWeb通信全体の土台になっています。

ブラウザとWebサーバー間のHTTPS/TLS通信と、機密性・完全性・真正性の3つの性質を示す図解
TLSは、盗み見を防ぐ機密性、改ざんを検知する完全性、証明書で接続先を確認する真正性を提供します。

SSL/TLSとは

TLSは、クライアントとサーバーの間に安全な通信路を作るプロトコルです。Webではブラウザがクライアント、Webサーバーがサーバーに当たります。TLSはWebだけの技術ではなく、メールやメッセージングなど、複数のアプリケーションプロトコルの通信を保護するために利用されています。

SSL(Secure Sockets Layer)はTLSの前身です。長年使われた名称であるため、今でも「SSL/TLS」「SSL証明書」という言葉が残っています。しかし、現在実際に使用するのはTLSです。古いSSLを使うことを意味して「SSL証明書」と呼んでいるわけではありません。

SSLは過去の名称、TLSは現在の技術です。日常的に「SSL」と呼ばれていても、実際の通信ではTLSが使われている場合がほとんどです。

HTTPとHTTPSの違い

HTTPSは、HTTPという別の通信方式を一から作り直したものではありません。HTTPの通信をTLSで保護したものがHTTPSです。

HTTPは「どのような形でWebの情報をやり取りするか」を受け持ちます。TLSは、そのやり取りを通信経路上で保護します。この役割分担を意識すると、TLSがWeb以外の通信にも応用できる理由が分かります。

TLSが守る3つの性質

TLSの目的は、単に文字を暗号に変換することではありません。安全な通信路の性質は、おもに次の3つに分けて考えられます。

機密性:通信の内容を読ませない

ブラウザとサーバーが送受信する内容を暗号化し、通信経路上で見られても第三者が容易に理解できないようにします。パスワードやCookie、入力フォームの内容、閲覧中のページなど、HTTPでやり取りする情報を保護します。

ただし、TLSは通信に関するあらゆる情報を見えなくする魔法ではありません。たとえば、通信の量やタイミングなど、状況によっては観測可能な情報があります。

真正性:通信相手を確かめる

通信内容を暗号化できても、相手が偽者であれば意味がありません。WebのTLS通信では、通常サーバーが証明書を提示し、ブラウザがその内容を検証します。アクセスしたホスト名と証明書が合っているか、有効期間内か、信頼できる証明書チェーンをたどれるかなどが確認されます。

一般的なWeb閲覧ではサーバー側を認証します。クライアント側も証明書で認証する方式はmTLS(mutual TLS)と呼ばれ、別の用途で利用されます。

完全性:通信の改ざんを検出する

ネットワーク上のデータは、読まれるだけでなく書き換えられる可能性もあります。TLSは、送信後のデータが気付かれないまま改ざんされることを防ぎます。もし保護されたデータが途中で書き換えられれば、受信側は検証の失敗としてそれを検出できます。

HTTPS通信が始まるまで

ブラウザにHTTPSのURLを入力してから、ページのデータを安全に受け取るまでの大きな流れを見てみましょう。

  1. サーバーへ接続する
    ブラウザは名前解決などを経て、目的のサーバーに到達します。
  2. TLSの条件を調整する
    クライアントとサーバーは、対応バージョンや暗号方式に関する情報を交換します。
  3. サーバーを認証する
    サーバーが提示する証明書を、ブラウザが検証します。
  4. 通信用の鍵材料を確立する
    実際の通信データを保護するための秘密を、双方が安全に確立します。
  5. HTTP通信を開始する
    確立した鍵とパラメータを使い、HTTPのリクエストとレスポンスを保護して送受信します。

このうち、通信条件の調整、認証、鍵材料の確立を行う手続きがTLSハンドシェイクです。ハンドシェイクの後、実際のアプリケーションデータはTLSのレコード保護によって守られます。

ハンドシェイクとデータ保護の役割

TLSの動きは、大きく2段階に分けると理解しやすくなります。

  • ハンドシェイク:通信相手を確かめ、使用する方式を決め、共有する鍵材料を確立する
  • レコード保護:ハンドシェイクで確立したパラメータと鍵を使い、実際の通信データを保護する

ハンドシェイクは「相手の身分証と合鍵を確認する手続き」、レコード保護は「実際の荷物を運ぶ専用通路」のような関係です。証明書がHTTPデータのすべてを直接暗号化し続けるわけではありません。

TLSで守られるもの、守られないもの

HTTPSで接続できれば何でも安全、というわけではありません。TLSが得意なのは、あくまでも通信経路を保護し、接続先のサーバーを確認することです。

TLSが守るもの

  • 通信中のHTTPヘッダーやボディの内容
  • 通信経路上の盗聴や改ざんへの防御
  • 証明書検証によるサーバー認証

TLSだけでは守れないもの

  • 侵害された端末やサーバー上のデータ
  • フィッシングサイトの内容や運営者の善良性
  • Webアプリケーションの脆弱性や認可の不備
  • 通信の存在やトラフィック特徴に関するすべてのメタデータ

証明書が正しく、TLS通信が成立していることは、「その通信先との通信路が保護されている」という意味です。サイトに書かれた情報が正しいか、商品や取引が信頼できるかまでをTLSが判断するわけではありません。

SSL証明書とTLS証明書は違うのか

市場では「SSL証明書」という名称が広く使われています。これは慣用的な呼び方であり、現在のTLS通信で使われるサーバー証明書と考えればよいでしょう。「SSL証明書」と「TLS証明書」という別々の証明書商品が、プロトコルごとに存在するわけではありません。

証明書には、サーバーの公開鍵と、その鍵をどの識別情報に結び付けるかといった情報が含まれます。認証局の署名と証明書チェーンを検証することで、ブラウザは通信先の認証に必要な判断材料を得ます。

よくある質問

SSLとTLSはどちらを使えばよいですか?

現在使うべきなのはTLSです。SSLという名称は「SSL/TLS」や「SSL証明書」のように残っていますが、古いSSLプロトコルの使用を推奨する意味ではありません。

HTTPSならWebサイトの内容も安全ですか?

HTTPSは通信先の認証と通信経路の保護を行いますが、サイトの内容や運営者の善良性を保証するものではありません。フィッシングサイトであっても、そのサイトが管理するドメインの正式な証明書を持つことはできます。

TLSはWeb以外にも使われますか?

はい。TLSは上位のアプリケーションプロトコルに依存せず、複数の用途に利用できます。HTTPSはその代表例です。

クライアントにも証明書は必要ですか?

通常のWeb閲覧では、サーバー側が証明書を提示します。クライアント側にも証明書を持たせて相互認証する構成はmTLSと呼ばれます。

まとめ:ブラウザの鍵マークの裏側で起きていること

ここまでの流れを、もう一度ひと続きにしてみましょう。HTTPだけでは、ブラウザとサーバーの間を流れる内容が途中から読まれたり、書き換えられたりする可能性があります。そこでTLSが暗号化された通信路を作り、証明書を使って接続先のサーバーを確認します。その通信路の中でHTTPをやり取りする仕組みがHTTPSです。

  • 機密性:盗み見を防ぐ
  • 真正性:接続先のサーバーが意図した相手かを確認する
  • 完全性:通信の改ざんを検出する

つまり、ブラウザに表示される鍵マークは「このサイトの内容はすべて正しく安全」という印ではありません。「確認した接続先との間に、盗み見や改ざんに強い通信路ができている」ことを示すものです。これが分かれば、HTTPSとTLSの基本的な関係はつかめています。

この全体像の先に、「暗号アルゴリズム」「証明書とPKI」「TLSハンドシェイク」という大きなテーマがあります。次回以降、それぞれを分解して解説していきます。


SSL/TLSを体系的に学びたい方へ

本記事は、SSL/TLSの全体像をつかむための入口です。拙著『SSL/TLS実践入門――Webの安全性を支える暗号化技術の設計思想』では、暗号アルゴリズム、TLS 1.2/1.3のプロトコル解析、PKI、OpenSSLプログラミング、脆弱性、性能、将来展望までを体系的に扱っています。

最終技術確認:2026年10月。TLS 1.3の説明は現行のRFC 9846、運用推奨はRFC 9325を主な確認先としています。

コメント

タイトルとURLをコピーしました