--- title: Transport Layer Security slug: Web/Security/Transport_Layer_Security tags: - Cryptography - Guide - SSL - Security - TLS - セキュリティ - 暗号化 - 認証 translation_of: Web/Security/Transport_Layer_Security ---

Transport Layer Security (TLS) を使用した接続のセキュリティは、選択されている暗号スイートとセキュリティ引数に強く依存します。この記事の目的は、クライアントとサーバの間の機密性と完全性の通信を確実にするために、選択の参考になることです。 Mozilla Operations Security (OpSec) チームは、サーバの設定項目のリファレンスが付いたウィキ記事を管理しています

Transport Layer Security (TLS) プロトコルは、ネットワークで結ばれた二つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。

歴史

HTTPS が導入されたときは Secure Sockets Layer (SSL) 2.0 という、 Netscape がもたらした技術に基づいていました。その後で間もなく SSL 3.0 に更新され、用途が拡大し、Web ブラウザーとサーバの間の相互運用性を保証するために、共通で標準化された暗号化技術を規定することが必要になりました。 Internet Engineering Task Force (IETF) は TLS 1.0 を {{RFC(2246)}} で1999年1月に規定しました。 TLS の現在のバージョンは 1.3 ({{RFC(8446)}}) です。

Web では暗号化に TLS を使用するようになったという事実に関わらず、多くの人々はまだ習慣的に "SSL" と呼んでいます。

TLS はどのような低水準のトランスポートプロトコルの上でも使用することができますが、このプロトコルの本来の目標は HTTP トラフィックを暗号化することでした。 HTTP を TLS で暗号化することは、一般に {{Glossary("HTTPS")}} と呼ばれています。暗号化されていない HTTP が既定で80番ポートを使用するのに対し、 TLS で暗号化されたWeb トラフィックは、慣習として既定で443番ポートで交わされます。 HTTPS は引き続き、 TLS の重要な用途です。

HTTP over TLS

TLS は、それと交換されるデータの安全性とセキュリティを確保するための3つの主要なサービスを提供しています。

認証
認証は、通信の各当事者が相手が自分の主張する人物であることを確認することを可能にします。
暗号化
データは、ユーザーエージェントとサーバの間で送信されている間は暗号化されており、権限のない者によって読み取られたり解釈されたりすることを防ぐことができます。
完全性
TLS は、データの暗号化から送信、復号化までの間に、情報の紛失、破損、改ざん、偽造がないことを保証します。

TLS 接続は、クライアントとサーバが共有シークレットに合意し、暗号スイートのような重要なパラメータがネゴシエートされるハンドシェイクフェーズから始まります。一旦、パラメータと HTTP などのアプリケーションデータが交換されるデータ交換モードになります。

暗号スイート

TLS のハンドシェイクがネゴシエートする主なパラメータは {{interwiki("wikipedia", "cipher suite")}} です。

TLS 1.2 およびそれ以前のバージョンでは、ネゴシエートされた暗号スイートには、共有秘密のネゴシエート、サーバの認証手段、データの暗号化に使用される方法を提供する一連の暗号アルゴリズムが含まれています。

TLS 1.3 の暗号化スイートは主にデータの暗号化を管理し、鍵の合意と認証には個別のネゴシエーション方法が使用されます。

異なるソフトウェアでは、同じ暗号スイートに対して異なる名前を使用している場合があります。例えば、OpenSSL や GnuTLS で使われている名前は TLS 標準のものとは異なります。Mozilla OpSec チームの TLS 設定に関する記事の暗号名対応表には、これらの名前と互換性やセキュリティレベルに関する情報が記載されています。

サーバの構築

サーバを正しく設定することは非常に重要です。一般的には、サイトに接続できるようにしたいブラウザと互換性のある、可能な限り最新の暗号をサポートするようにしてください。Mozilla OpSec ガイドの TLS 設定では、推奨される設定についての詳細な情報を提供しています。

サイトの設定を支援するために、Mozilla は以下の Web サーバ用の設定ファイルを生成する便利な TLS 設定ジェネレータを提供しています。

必要に応じて設定を作成するには、コンフィグレータを使用することをお勧めします。設定ファイルをコピーしてサーバ上の適切なファイルに貼り付け、サーバを再起動して変更を反映させます。設定ファイルにはカスタム設定を含めるための調整が必要な場合がありますので、使用する前に生成された設定を確認してください。ドメイン名などの参照が正しいことを確認せずに設定ファイルをインストールすると、サーバが動作しなくなります。

TLS 1.3

{{RFC("8446", "TLS 1.3")}} は、TLS のメジャーリビジョンです。TLS 1.3 には、セキュリティとパフォーマンスを向上させる多数の変更が含まれています。TLS 1.3 の目標は以下の通りです。

TLS 1.3 はプロトコルの基本的な部分の多くを変更していますが、以前のバージョンの TLS と同様に基本的な機能のほとんどすべてを保持しています。Web では、TLS 1.3 はいくつかのまれな例外を除いて、互換性に影響を与えることなく有効にすることができます (以下を参照)。

TLS 1.3 の主な変更点は以下の通りです。

TLS 1.3 のドラフト版の実装が公開されています。TLS 1.3  は 0-RTT モードを含むいくつかのブラウザで有効になっています。TLS 1.3 を有効にしている Web サーバでは、TLS 1.3 が正常に動作するように設定を調整する必要があるかもしれません。

TLS 1.3 では、重要な新しいユースケースが 1 つだけ追加されました。0-RTT ハンドシェイクは、Web のようなレイテンシに敏感なアプリケーションに大きなパフォーマンスの向上をもたらします。0-RTT を有効にするには、導入を確実に成功させ、リプレイ攻撃のリスクを管理するための追加のステップが必要です。

TLS 1.3 でリネゴシエーションが削除されたことは、証明書を使ったクライアント認証に依存する一部の Web サーバに影響を与える可能性があります。一部の Web サーバは、クライアント証明書が暗号化されていることを確実にするため、あるいは特定のリソースが要求されたときにのみクライアント証明書を要求するために、リネゴシエーションを使用しています。クライアント証明書のプライバシーを守るために、TLS 1.3 ハンドシェイクの暗号化によってクライアント証明書の暗号化が確実に行われますが、これにはソフトウェアの変更が必要になるかもしれません。証明書を使ったリアクティブなクライアント認証は TLS 1.3 でサポートされていますが、広くは実装されていません。代替のメカニズムは現在開発中で、HTTP/2 もサポートする予定です。

古いバージョンの TLS の引退

よりモダンで安全な Web に向けての取り組みにより、2020 年第 1 四半期に TLS 1.0 および 1.1 のサポートがすべての主要ブラウザーから削除されます。 Web サーバが今後 TLS 1.2 または 1.3 をサポートすることを確認する必要があります。

Firefox はバージョン 74 以降、古い TLS バージョンを使用してサーバに接続すると Secure Connection Failed エラーを返します ({{bug(1606734)}}) 。

TLS ハンドシェイクタイムアウト値

何らかの理由で TLS ハンドシェイクが遅くなったり、反応しなくなったりすると、ユーザーの体験に大きな影響を与える可能性があります。この問題を軽減するために、最近のブラウザはハンドシェイクのタイムアウトを実装しています。

関連情報

{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}