Linuxセキュリティ

TLS 1.3の設定と脆弱性対策：Nginx・Apache対応ガイド

TLS 1.3のNginx・Apacheでの設定方法と脆弱性対策を解説。SSL設定のベストプラクティス、移行手順、既知の脆弱性への対応を網羅。

TLS 1.3NginxApache脆弱性設定SSL2026/5/25

はじめに

TLS 1.3は、従来のTLS 1.2と比較して、セキュリティとパフォーマンスが大幅に向上したプロトコルです。この記事では、主要なWebサーバーであるNginxとApacheにおけるTLS 1.3の設定方法と、脆弱性への対策について解説します。

TLS 1.3の概要と利点

TLS 1.3は2018年にRFC 8446として標準化されました。主な改善点は以下の通りです。

  • ハンドシェイクの高速化: 往復回数が1-RTT（初回接続時）または0-RTT（再接続時）に削減
  • 古い暗号スイートの廃止: 脆弱な暗号（RC4、3DES、CBCモードなど）が削除
  • 前方秘匿性（PFS）の必須化: すべての鍵交換でPFSを強制
  • 暗号スイートの簡素化: AEAD暗号のみをサポート

    • NginxでのTLS 1.3設定

    前提条件

  • Nginx 1.13.0以上（1.13.0でTLS 1.3対応、1.15.0以降で安定）
  • OpenSSL 1.1.1以上

    • 設定手順

    /etc/nginx/nginx.confまたは該当するサイト設定ファイルで、serverブロック内に以下を追記します。

    server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    

    # その他の設定
}

    ssl_protocolsにTLSv1.3を追加します。TLSv1.2も併記することで、TLS 1.3未対応のクライアントへの互換性を維持できます。

    設定確認

    設定後、以下のコマンドで構文チェックとリロードを行います。

    nginx -t
systemctl reload nginx

    ApacheでのTLS 1.3設定

    前提条件

  • Apache 2.4.37以上
  • OpenSSL 1.1.1以上
  • mod_sslが有効

    • 設定手順

    /etc/httpd/conf.d/ssl.confまたは該当するバーチャルホスト設定ファイルで、以下を設定します。

    <VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    SSLCertificateFile /path/to/fullchain.pem
    SSLCertificateKeyFile /path/to/privkey.pem
    

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
    

    # その他の設定
</VirtualHost>

    SSLProtocolで+TLSv1.3を指定します。all -SSLv3 -TLSv1 -TLSv1.1で古いプロトコルを無効にし、+TLSv1.2 +TLSv1.3で有効にします。

    設定確認

    設定後、構文チェックとリロードを行います。

    apachectl configtest
systemctl reload httpd

    TLS 1.3の脆弱性と対策

    TLS 1.3は設計上、多くの既知の脆弱性に対処していますが、実装依存の問題や設定ミスによる脆弱性が存在します。

    主な脆弱性と対策

  • 0-RTTのリプレイ攻撃
    • - 0-RTTはリプレイ攻撃のリスクがあります。特にべき等でないリクエスト（例：POST）では注意が必要です。 - 対策: 0-RTTを無効にするか、アプリケーション側でリプレイ検出を実装します。
  • ダウングレード攻撃
    • - 攻撃者がTLS 1.3をサポートしないふりをして、クライアントとサーバーをTLS 1.2以下に強制する可能性があります。 - 対策: サーバー側でTLS 1.2以上のみ許可し、古いプロトコルを無効にします。また、TLS 1.3のsupported_versions拡張を適切に実装します。
  • 実装バグ
    • - OpenSSLやBoringSSLなどのライブラリにバグがある場合があります。 - 対策: 常に最新の安定版を使用し、セキュリティパッチを適用します。

    設定のベストプラクティス

  • 古いプロトコルを無効化: SSLv2, SSLv3, TLSv1.0, TLSv1.1は無効にします。
  • 暗号スイートの制限: TLS 1.3では限られた暗号スイートのみ使用可能ですが、サーバー側で明示的に指定することも可能です。推奨はTLS_AES_128_GCM_SHA256とTLS_AES_256_GCM_SHA384です。
  • HSTSの有効化: HTTP Strict Transport Securityを設定し、HTTPS接続を強制します。
  • 証明書の管理: 有効な証明書を使用し、Let's Encryptなどの自動更新を活用します。

    • 移行時の注意点

  • 互換性: 一部の古いクライアント（例：Android 4.x以下）はTLS 1.3をサポートしていません。必要に応じてTLS 1.2も有効にしておきます。
  • テスト: 設定後、SSL LabsのSSL Server Testなどで設定を検証します。
  • 段階的ロールアウト: 本番環境ではまず一部のサーバーで有効にし、問題がないことを確認してから全体に展開します。

    • *この記事はArch Linux/btrfs/LUKs環境で実際に検証した内容を基にしています。セキュリティ設定は環境によって異なるため、本番環境への適用前に必ずテスト環境で検証してください。*

    まとめ

    TLS 1.3はセキュリティとパフォーマンスの両面で優れたプロトコルです。NginxやApacheでの設定は比較的簡単で、適切な脆弱性対策を施すことで安全に運用できます。このガイドを参考に、TLS 1.3への移行を進めてください。

    ← 記事一覧に戻る