トランスポート層セキュリティ

  1. Referer ヘッダーのプライバシーとセキュリティの考慮事項
  2. サブドメインテイクオーバー
  3. サブリソース完全性
  4. トランスポート層セキュリティ
  5. ユーザーによる有効化によって制御される機能
  6. 保護されたコンテキスト
    1. 保護されたコンテキストに制限されている機能
  7. 同一オリジンポリシー
  8. 安全でないパスワード
  9. 実践的なセキュリティ実装ガイド
    1. フォームの自動補完を無効にするには
  10. 攻撃
    1. Clickjacking
  11. 混在コンテンツ
  12. 無信頼の iframe Experimental
  13. 脆弱な署名アルゴリズム
  14. 証明書の透明性

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

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

歴史

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

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

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

HTTP over TLS

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

認証

認証は、通信の各当事者が相手が自分の主張する人物であることを確認することを可能にします。

暗号化

データは、ユーザーエージェントとサーバーの間で送信されている間は暗号化されており、権限のない者によって読み取られたり解釈されたりすることを防ぐことができます。

完全性

TLS は、データの暗号化から送信、復号化までの間に、情報の紛失、破損、改ざん、偽造がないことを保証します。

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

暗号スイート

TLS のハンドシェイクがネゴシエートする主なパラメーターは cipher suite です。

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

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

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

サーバーの構築

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

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

  • Apache
  • Nginx
  • Lighttpd
  • HAProxy
  • Amazon Web Services CloudFormation Elastic Load Balancer

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

TLS 1.3

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

  • TLS 1.2 の未使用で安全でない機能を削除します
  • 強力なセキュリティ分析を設計に含めます
  • プロトコルをより多く暗号化することで、プライバシーを向上させます
  • ハンドシェイクを完了するまでの時間を短縮します

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

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

  • TLS 1.3 のハンドシェイクは、ほとんどの場合 1 回のラウンドトリップで完了し、ハンドシェイクの待ち時間を短縮します
  • サーバーは 0-RTT (ゼロラウンドトリップタイム) ハンドシェイクを有効にすることができます。サーバーに再接続したクライアントはすぐにリクエストを送ることができ、TLS ハンドシェイクの待ち時間を完全に排除できます。0-RTT によるパフォーマンスの向上は大きなものですが、リプレイ攻撃のリスクもありますので、この機能を有効にする前には注意が必要です
  • TLS 1.3 は、接続が再開されるか、事前に共有された鍵を使用しない限り、フォワードセキュアモードのみをサポートしています
  • TLS 1.3 は、TLS 1.3 専用の新しい暗号スイートを定義しています。これらの暗号化スイートはすべて最新の Authenticated Encryption with Associated Data (AEAD) アルゴリズムを使用しています
  • TLS 1.3 のハンドシェイクは、共有シークレットを確立するために必要なメッセージを除き、暗号化されています。特に、これはサーバー証明書とクライアント証明書が暗号化されていることを意味します。ただし、クライアントがサーバーに送信するサーバー ID (サーバー名または SNI 拡張子) は暗号化されないことに注意してください
  • 数多くのメカニズムが無効化されています: リネゴシエーション、一般的なデータ圧縮、デジタル署名アルゴリズム。(DSA) 証明書、静的 RSA 鍵交換、カスタム Diffie-Hellman (DH) グループとの鍵交換

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

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

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

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

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

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

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

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

  • バージョン 58 以降、Firefox は TLS ハンドシェイクのタイムアウトを既定値の 30 秒で実装しています。タイムアウトの値は、about:config の network.http.tls-handshake-timeout 設定値を編集することで変更できます

関連情報