SSLとTLSプロトコル：その違いとは？

SSLおよびTLSは、クライアントとサーバー間でやり取りされるデータを暗号化する暗号プロトコルです。すべてのSSLバージョンは非推奨かつ安全ではないため、TLSがSSLに取って代わりました。現在、「SSL」という用語は、ほぼ例外なくTLSの通称として使われています。SSL/TLSプロトコル、トランスポート層セキュリティ（TLS）、およびセキュア・ソケット・レイヤー（SSL）の微妙な違いを理解することで、Webサーバーやメールインフラストラクチャのコンプライアンスを維持し、完全に保護することができます。

SSLおよびTLSプロトコルとは何ですか？

Secure Sockets Layer（SSL）およびTransport Layer Security（TLS）プロトコルは、ネットワーク上を伝送されるデータを保護するために設計された暗号技術の単一のファミリーに属しています。これらは、現代のデジタル通信の基盤となっているトランスポート層セキュリティプロトコルの、世代を重ねた進化形です。

ユーザーがウェブサイトにアクセスしたり、電子メールを送信したり、クラウドアプリケーションにログインしたりする際、そのデバイスと受信サーバー間の通信は、盗聴や改ざんから保護される必要があります。これら両方のプロトコルは、サーバーの認証を行い、データペイロードがパブリックインターネットを経由する前に暗号化することで、この保護を実現しています。

業界ではこれらの用語がしばしば混同して使われるため、混乱を招くことがあります。しかし、Secure Sockets Layer（SSL）は、現代の暗号化技術の礎となった、より古い基盤技術です。一方、Transport Layer Security（TLS）は、その元の基盤を基盤として、より新しく、高度なセキュリティを備えたアップグレード版に過ぎません。両者には、データ伝送のための安全なトンネルを構築するという、同じ主たる目的があります。

TLSおよびSSLプロトコルとは何かを理解することは、ITチームやセキュリティチームがサーバーを正しく設定する上で役立ちます。両者は同じ目的を共有していますが、その内部の仕組みは大きく異なります。組織は、この共通の起源を認識しつつ、セキュリティコンプライアンスを維持するために、最新バージョンのみを使用することを厳格に徹底しなければなりません。

SSLとは何ですか？

SSL（Secure Sockets Layer）は、 ネットスケープ が1990年代半ばにインターネット通信の安全性を確保するために開発した最初の暗号プロトコルです。これは、ウェブブラウザとウェブサーバーの間で送信されるデータを暗号化し、クレジットカード情報やログイン認証情報などの機密情報が傍受されるのを防ぐように設計されました。

SSLは3つのバージョンを経てきました：

• SSL 1.0 は、深刻なセキュリティ上の欠陥があったため、一般には公開されませんでした。
• SSL 2.0がリリースされたが、すぐに脆弱性が発見された。
• SSL 3.0は1996年にリリースされた最終バージョンであり、重大な脆弱性が発見されて安全でなくなるまでは広く採用されていました。

現在、SSLのすべてのバージョンは非推奨となっています。主要なウェブブラウザではSSLがサポートされなくなっており、現在これを使用することは、ユーザーや組織に重大なリスクをもたらします。

TLSとは何ですか？

TLS（Transport Layer Security）は、SSLの後継となる最新のプロトコルです。これは、SSLに見られたセキュリティ上の脆弱性に対処するとともに、パフォーマンスと暗号化強度を向上させることを目的として、1999年にインターネット技術タスクフォース（IETF）によって導入されました。

TLSは現在、安全なWeb通信の業界標準となっています。以下のような分野で広く利用されています：

• HTTPS対応のウェブサイト
• メールサービス
• VPN
• クラウドプラットフォーム
• ネットワーク上で暗号化された通信を必要とするあらゆるアプリケーション

TLS暗号化 は、導入以来4つのバージョンを経てきました。TLS 1.3は現在利用可能な最も安全な標準規格であり、詳細については以下のSSLおよびTLSプロトコルバージョンの解説をご覧ください。

SSLおよびTLSプロトコルのバージョン：完全な年表

4つのSSLプロトコルとは何かと疑問に思われるかもしれませんが、これらはSSL 1.0、SSL 2.0、SSL 3.0、そして実質的にSSL 3.1として機能していた初期のTLS 1.0リリースを指します。これらのレガシープロトコルバージョンは、安全なWebトラフィックの基盤を築きましたが、深刻な暗号上の脆弱性を抱えていました。

多くの管理者が、TLS 1.2 や 1.3 は安全なのかと尋ねます。答えは「はい」です。TLS 1.2 は、脆弱な暗号スイートを排除するように設定されていれば、引き続き有効かつ安全です。しかし、TLS 1.3 は現在のトランスポート層セキュリティの最高水準と言えます。TLS 1.3 を導入することで、廃止された暗号アルゴリズムが完全に排除され、フォワードシークレシーが義務付けられるため、将来的に鍵が漏洩したとしても、過去のセッションは厳重に暗号化された状態が維持されます。

SSL 対 TLS：主な違い

ここが核心となる疑問です。SSLとTLSの違いは何でしょうか？その違いは、セキュリティ、パフォーマンス、そして設計に集約されます。TLSは、SSLの欠点を改善するために特別に構築されたものであり、そのことはプロトコルのあらゆるレイヤーに表れています。

以下に直接比較を示します：

暗号化アルゴリズム

SSLは、現在では解読されたり廃止されたりしている、古く脆弱な暗号化アルゴリズムに依存しています。一方、TLSはAES（Advanced Encryption Standard）やChaCha20といったより強力な暗号化アルゴリズムを採用しており、転送中のデータを大幅に強固に保護します。

メッセージ認証

SSLはメッセージ認証にMD5アルゴリズムを使用していますが、これは現在、暗号学的に破られていると見なされています。一方、TLSはハッシュベースのメッセージ認証コード（HMAC）を使用しており、改ざん攻撃や衝突攻撃に対してはるかに耐性があります。また、TLSはSSLと比較して、より安全な鍵交換方式をサポートしており、その一例として ディフィー・ヘルマン・エフェメラル（DHE） や 楕円曲線ディフィー・ヘルマン（ECDHE）など、SSLに比べてより安全な鍵交換方式をサポートしています。

握手の手順

SSLハンドシェイクのプロセスでは、安全な接続を確立するためにより多くのラウンドトリップが必要となるため、処理速度が遅くなり、ネゴシエーション中はセキュリティ上のリスクが高まります。 TLSハンドシェイク の方がはるかに効率的です。

暗号スイート

TLSは、より幅広いセキュアな暗号スイートをサポートしています。SSLではサポートできる範囲が限られており、その暗号スイートの多くは現在、危険なほど脆弱であると見なされています。TLS 1.3では、すべてのレガシーな暗号スイートや脆弱な暗号スイートが完全に削除されました。

鍵交換プロトコル

TLSは、改良された最新の安全な鍵交換プロトコルを採用しています。TLS 1.3はフォワードシークレットな鍵交換方式のみをサポートしており、たとえ後で秘密鍵が漏洩したとしても、過去のセッションを復号することはできません。

SSLが非推奨となった理由

SSLは、いくらパッチを当ててもその根本的な設計上の欠陥を修正できなかったため、非推奨となりました。POODLEやBEASTといった重大なセキュリティ脆弱性は、SSLが構造的に安全ではないことを証明しました。主要なブラウザは最終的にSSLのサポートを完全に廃止し、PCI DSSなどのコンプライアンスフレームワークもこれに追随しました。

POODLE攻撃

2014年に発見された、 POODLE （Padding Oracle On Downgraded Legacy Encryption）は、SSL 3.0の根本的な欠陥を悪用するものでした。これにより、攻撃者は以下のことが可能となりました：

• ブラウザに、SSL 3.0 への接続ダウングレードを強制する。
• セッション Cookie や認証情報などの機密データを復号します。
• 標準的な SSL 3.0 実装であればどれに対してもこの攻撃を実行できる。
  唯一確実な対処法は、SSLを完全に無効にすることだった。

BEAST攻撃

BEAST（Browser Exploit Against SSL/TLS）は、SSLで使用される暗号ブロック連鎖モードを標的とし、中間者攻撃者が暗号化されたデータを復号できるようにするものでした。初期のTLSバージョンも一時的に影響を受けましたが、TLSは更新することができました。一方、SSLにはそれができませんでした。

ブラウザの非推奨

主要なブラウザはすべて、SSLのサポートを完全に廃止しました：

• Chrome、Firefox、Safari、EdgeはいずれもSSLのサポートを終了しました。
• SSLを使用しているサイトでは、アドレスバーに「安全ではありません」という警告が表示されます。
  これはユーザーの信頼に直接影響を与えるだけでなく、GoogleがHTTPSを強力なランキングシグナルとして扱っているため、SEOの順位にも影響を及ぼす可能性があります。

コンプライアンス要件

PCI DSS （ペイメント・カード・インダストリー・データ・セキュリティ・スタンダード）では、SSLを安全なプロトコルとして認めなくなりました。オンライン取引、クレジットカード情報、または決済処理を取り扱う組織は、すべてTLSを使用する必要があります。SSLの使用は、現行のPCI DSS基準において、直接的なコンプライアンス違反となります。

SSL/TLSハンドシェイクの仕組み

HTTPS ウェブサイトにアクセスするたびに、データのやり取りが行われる前に、自動的に SSL/TLS ハンドシェイクが行われます。このプロセスにより、安全な接続が確立され、サーバーの身元が確認され、その後のすべての通信を暗号化するために使用されるセッションキーが生成されます。

手順は以下の通りです：

1. Client Hello： ブラウザは、サポートしている TLS バージョン、暗号スイートのリスト、およびランダムに生成された「クライアントランダム」文字列を含むメッセージを送信します。
2. サーバーのHelloメッセージ： サーバーは、選択したTLSバージョン、選択した暗号スイート、および独自の「サーバーランダム」文字列を応答として返します。
3. 証明書の検証： サーバーは、信頼できる認証局（CA）によって発行されたデジタル証明書を提示します。クライアントは、その証明書が信頼できるCAによって署名されているか、有効期限が切れていないか、およびドメイン名が一致しているかを確認します。
4. 鍵交換： クライアントとサーバーは、サーバーの公開鍵を使用して安全な鍵交換を行います。公開鍵で暗号化されたデータを復号できるのは、サーバーの秘密鍵のみです。
5. 生成されたセッションキー： 双方は、交換されたデータから、互いに一致する対称セッションキーをそれぞれ独立して生成します。これらは、以降のすべての通信を暗号化するために使用されます。
6. 暗号化通信の開始： 双方が「finished」メッセージでハンドシェイクの完了を確認し、暗号化通信が開始されます。

TLS 1.3のハンドシェイクは、通信の往復回数を減らすことで、このプロセスを劇的に改善します。旧バージョンでは2回の往復通信が必要でしたが、TLS 1.3では1回の往復通信で全プロセスを完了します。これにより、数ミリ秒の遅延が解消され、接続開始直後からより高速で安全な接続が実現されます。

SSL/TLS と HTTPS：その関係性

多くのユーザーから、「TLS 1.2 は HTTPS と同じものなのか」という質問が寄せられます。両者は密接に関連していますが、まったく同じものではありません。HTTPS は「Hypertext Transfer Protocol Secure」の略で、ユーザーのウェブブラウザとウェブサイトの間でデータを送信するための標準プロトコルです。

HTTPSは、安全なTLS接続上で動作する標準的なHTTPです。TLSによる暗号化レイヤーがない場合、HTTPはデータを平文で送信するため、ネットワークを監視している者なら誰でもパスワードやプライベートメッセージを読み取ることができます。WebサーバーをHTTPSを使用するように設定すると、TLSプロトコルを使用してHTTPトラフィックを暗号化するよう指示することになります。

したがって、TLSのような基盤となる暗号プロトコルがなければ、安全なHTTPS接続を確立することはできません。この2つはシームレスに連携し、現代のウェブにおけるデータの完全性と機密性を確保しています。

SSL/TLS証明書：その仕組み

現在でも「SSL証明書」という呼び方が広く使われていますが、実際には最新の証明書はすべてTLSを採用しています。この名称は過去の慣習によるものです。SSL/TLS証明書とは、認証局（CA）によって発行されるデジタル文書であり、サーバーの身元を認証し、暗号化された通信を可能にするものです。

証明書の内容

• サーバーの公開鍵
• 発行CAのデジタル署名
• 証明書が有効なドメイン名
• 証明書の有効期間

TLS証明書の種類

信頼はどのように築かれるのか

ブラウザは証明書を受信すると、それが信頼できる認証局（CA）によって署名されているかどうかを確認します。ブラウザには、信頼できるルートCAのリストが組み込まれています。その証明書がこれらのルートのいずれかに遡れる場合、その接続は信頼できるものとみなされ、南京錠のアイコンが表示されます。

おすすめ記事： ICA SSL証明書とは？ | 完全ガイド

SSL/TLS証明書の有効期間：変更点について

証明書の有効期間が短縮されており、組織は今から準備を進める必要があります。現在の最大有効期間は398日ですが、2029年3月までにわずか47日へと短縮されるため、セキュリティチームは自動更新ルーチンを設定する際、証明書の有効期間の短縮率を正確に算出する必要があります。

段階的なスケジュール

なぜこれが重要なのか

有効期間が短くなることで、侵害された証明書はより早く無効となり、攻撃者が攻撃を行うことができる時間が制限されます。組織は証明書の管理を徹底し、古い設定を定期的に検出して修正する必要があります。

今すべきこと

47日ごとに手動で証明書を更新することは、大規模な環境では現実的ではありません。組織は、ACMEなどのプロトコルを用いた自動証明書管理を導入し、自動化に対応した認証局（CA）を利用し、証明書の有効期限切れに対する監視とアラートを設定するとともに、現在の証明書の保有状況と更新プロセスを監査する必要があります。

ウェブサイトにTLSを導入する方法

TLSを正しく実装するには、単に証明書をインストールするだけでは不十分です。サーバーを適切に設定し、古いプロトコルを無効にし、強固な暗号スイートのみを使用する必要があります。以下に、実装の全手順を説明します。

手順 1: TLS 証明書を取得する

信頼できる認証局（CA）を選び、利用目的に適した証明書の種類を選択し、サーバー上で証明書署名要求（CSR）を生成して、CAに提出し、その検証プロセスを完了させます。

ステップ 2: 証明書をインストールする

サーバーの種類（Apache、Nginx、IISなど）によって手順が異なるため、CAのインストール手順に従ってください。信頼チェーンを確立するために、必要な中間証明書をすべてインストールしてください。

ステップ3：サーバーの設定

サーバーの設定では、TLS 1.3 を優先バージョンとして有効にし、TLS 1.2 はフォールバックとしてのみ残しておく必要があります。SSL、TLS 1.0、および TLS 1.1 は完全に無効にしてください。AES-GCM や ChaCha20-Poly1305 などの安全な暗号スイートのみを許可し、脆弱な暗号スイートや旧式の暗号スイートはすべて削除してください。

ステップ4：HSTSを有効にする

HTTP Strict Transport Security（HSTS）は、ユーザーが手動で「HTTP」と入力した場合でも、ブラウザが常にHTTPS経由で接続するように強制します。これにより、ダウングレード攻撃を防ぎ、常に安全な接続を確保します。

ステップ 5: HTTP を HTTPS にリダイレクトする

すべてのHTTPトラフィックを自動的にHTTPSにリダイレクトするようにサーバーを設定してください。暗号化されていないデータの送信が一切行われないようにしてください。

ステップ6：設定を確認する

SSLテストツールを使用して、サーバーの設定をスキャンし、脆弱な暗号スイート、プロトコルバージョンの問題、または証明書の問題がないか確認してください。

PowerDMARCの MTA-STSの実装 は、TLSの問題がメール配信に影響を与えている場合に検討する価値があります。MTA-STSはメール送信時にTLSを強制し、メールの内容が漏洩する可能性のあるダウングレード攻撃を防ぎます。また、PowerDMARCの TLS-RPTチェッカー を活用し、メールインフラ全体におけるTLS暗号化の失敗を監視することをお勧めします。

電子メールにおけるTLS：TLS-RPTとMTA-STS

WebのTLSはユーザーのブラウザとWebサーバー間の通信を保護しますが、電子メールのセキュリティには特有の課題があります。電子メールメッセージは、最終的な宛先に到達するまでに、異なるメールサーバー間を複数のホップを経由して送信されます。この転送中に、悪意のある攻撃者は容易にダウングレード攻撃を実行し、接続を平文に戻すことで、機密性の高い通信内容をさらしてしまう可能性があります。

メール配信パイプラインに脆弱性が残っている限り、Webインターフェースのセキュリティ対策だけでは不十分です。そのため、メール転送におけるTLSを規定する専用のプロトコルが存在するのです。 MTA-STS（Mail Transfer Agent Strict Transport Security） は、すべての受信メールに対してTLS暗号化を厳格に適用することで、ダウングレードの問題を解決します。MTA-STSポリシーを公開すると、外部のメールサーバーに対して、サーバーへの接続を安全に暗号化するか、さもなければメールを完全に破棄するよう指示することになります。

ただし、暗号化を徹底するには、配信の失敗状況を把握できる必要があります。 TLS-RPT（TLS レポーティング） は、MTA-STSと連携して、毎日の集計レポートを送信します。これらのレポートにより、メールサーバーがお客様のドメインへの接続を試みたものの、TLSネゴシエーションに失敗した場合は、直ちに通知されます。

一般的な認証局やCDNで、メール転送のセキュリティに重点を置いているところはありませんが、通信を保護するためにはTLS-RPTとMTA-STSの導入が不可欠です。PowerDMARCはこのプロセス全体を自動化します。当社のプラットフォームは、メールドメインに対して厳格なTLS暗号化を適用すると同時に、接続エラーに関する読みやすく、具体的な対応策がわかるレポートを提供します。

よくあるご質問

SSLおよびTLSプロトコルとは何ですか？

SSLおよびTLSプロトコルは、コンピュータネットワークを介して送信されるデータを暗号化するために設計された暗号化ルールセットです。これらはクライアントとサーバー間の通信を保護し、権限のない第三者が機密情報を傍受したり読み取ったりすることを防ぎます。

SSLプロトコルにはどのような4種類がありますか？

セキュアな転送プロトコルの初期の4つのバージョンには、SSL 1.0、SSL 2.0、SSL 3.0、およびTLS 1.0（当初はSSL 3.1として知られていた）が含まれます。これら4つのレガシープロトコルはすべて、重大なセキュリティ上の欠陥があるため、完全に非推奨となっています。

TLS 1.2 は今でも安全なのでしょうか？

はい、TLS 1.2 は適切に設定されていれば、依然として安全です。管理者は、セキュリティの完全性を維持するために、脆弱な暗号スイートを無効にし、最新のアルゴリズムを優先するようにする必要があります。

どのTLSバージョンを使用すべきでしょうか？

TLS 1.3 は最高レベルのセキュリティと最速のハンドシェイク速度を提供するため、主要プロトコルとして実装すべきです。若干古いクライアントに対応するためのフォールバックとして、TLS 1.2 を引き続き維持することも可能です。

TLSは私のメールを保護してくれますか？

TLSによる保護が有効になるのは、送受信双方のメールサーバーがTLSをサポートし、かつその適用を強制している場合に限られます。転送中の暗号化を強制するMTA-STSのようなプロトコルがなければ、メール通信は容易に傍受され、平文に降格されてしまう可能性があります。

SSLとTLS、どちらが良いのでしょうか？

TLSは間違いなくSSLよりも優れています。TLSは、優れたセキュリティ、パフォーマンス、そして最新の暗号化規格を提供します。SSLのすべてのバージョンは、セキュリティ上の脆弱性があるため、使用が推奨されなくなっています。

HTTPSはSSLとTLSのどちらを使用していますか？

最新のHTTPSでは、TLSプロトコルのみが使用されています。「SSL証明書」という用語は業界では依然として一般的に使われていますが、現在の安全なWeb接続では、実際にはすべてTLSを用いて暗号化が行われています。

TLSが標準となっているのに、なぜ人々は今でも「SSL」と言うのでしょうか？

SSLは、長年にわたり広く普及してきたことや、マーケティング用語に深く定着していることから、現在もなお一般的に使用されています。この用語は、単に証明書の一般的な呼称として定着しているに過ぎません。

サーバーのSSLを完全に無効にできますか？

はい、そうすべきです。古いSSLプロトコルを無効にすることで、既知の「中間者攻撃」の脆弱性やダウングレード攻撃から、サイトとユーザーを保護することができます。

TLSに切り替えた場合、SSL証明書を更新する必要がありますか？

いいえ。証明書は、SSL や TLS のプロトコルバージョンに厳密に紐づいているわけではありません。デジタル証明書が有効である限り、最新の TLS 実装でも問題なく機能します。

PowerDMARCで全体像を確実に把握

SSLとTLSを正しく理解することは、基本的な第一歩です。しかし、攻撃対象領域はブラウザだけにとどまりません。電子メールは、サイバーセキュリティにおいて最も悪用されやすい経路の一つです。適切なプロトコルが導入されていなければ、電子メールドメインがなりすましや傍受の危険にさらされている状況では、Webトラフィックが暗号化されていてもほとんど意味がありません。

そこでPowerDMARCの出番です。PowerTLS-RPTは、メール送信ドメイン全体におけるTLS暗号化の失敗について、自動レポートを提供します。PowerMTA-STSは、受信メールの配信においてTLSを強制し、SMTP接続から暗号化を完全に解除しようとするダウングレード攻撃を阻止します。

PowerDMARCの包括的な認証スイートは、DMARC、SPF、DKIM、BIMIを網羅しています。ドメインのなりすましを防止し、受信トレイへの配信率を向上させ、Google、Yahoo、およびPCI DSSの要件への準拠を維持します。TLSが接続を保護し、PowerDMARCがその背後にあるすべてを保護します。今すぐ PowerDMARCの無料トライアル して、今すぐメールセキュリティの状況を完全に把握しましょう。