NginxとApacheにおけるTLS 1.3設定完全ガイド: セキュリティリスクを最小限に抑える

出典： 日本の上場企業3715社の公式サイトのSSL/TLSセキュリティ脆弱性ダッシュボード

TLS1.3の設定方法

NginxでのTLS 1.3の有効化

1. OpenSSL 1.1.1以上のインストール: TLS 1.3を使用するためには、OpenSSL 1.1.1以上が必要です。システムが古いバージョンを使用している場合は、最新バージョンにアップグレードしてください。
2. Nginx設定の更新: Nginxの設定ファイル（通常は**/etc/nginx/nginx.confやサイト設定ファイル内）を編集し、ssl_protocols**ディレクティブを含めてTLS 1.3を有効にします。

server {
    listen 443 ssl;
    ssl_protocols TLSv1.2 TLSv1.3; # TLS 1.2とTLS 1.3を有効にする
    ssl_ciphers [適切な暗号スイート];
    ...
}

Nginxの再起動: 設定を適用するためにNginxを再起動します。

sudo systemctl restart nginx

ApacheでのTLS 1.3の有効化

1. OpenSSL 1.1.1以上のインストール: こちらもNginxと同様に、OpenSSL 1.1.1以上が必要です。
2. Apache設定の更新: Apacheの設定ファイル（**/etc/httpd/conf/httpd.confやサイト設定ファイルなど）を編集し、SSLProtocol**ディレクティブを使用してTLS 1.3を有効にします。

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite [適切な暗号スイート]
    ...
</VirtualHost>

Apacheの再起動: 設定を適用するためにApacheを再起動します。

sudo systemctl restart httpd

古いプロトコルの削除

SSL ProtocolsディレクティブにTLSv1.3を追記することに加え、**古いプロトコル（例えば、SSL v3、TLS 1.0、TLS 1.1）を無効化することも重要です。これは、Tlsv1.2未満のプロトコルをSSLProtocolsディレクティブに「含めない」ことにより達成できます。**NginxとApacheそれぞれで同じです。

ブラウザのTLS 1.3サポート設定

ほとんどの現代のウェブブラウザはデフォルトでTLS 1.3をサポートしています。特に設定を変更する必要はありませんが、使用しているブラウザがTLS 1.3をサポートしているかどうか、または特定のサイトでTLS 1.3が使用されているかどうかを確認したい場合は、ブラウザの設定や開発者ツールをチェックすることができます。

TLSv1.3対応の設定ファイルを簡単に自動生成する方法：Mozilla SSL Configuration Generator

Mozilla SSL Configuration Generatorを使うことでTLS1.3に対応したサーバー設定テンプレートを簡単に生成することができます。Server Softwareから当該サーバーソフトを選択し、Mozilla ConfigurationからModernもしくはIntermediateを選択することで、可能です。以下は、最も汎用性が高い、Intermediateで生成した例です。

Mozilla SSL Configuration Generator TLS1.3対応コード Nginx Intermediate設定

# generated 2024-03-11, Mozilla Guideline v5.7, nginx 1.17.7, OpenSSL 1.1.1k, intermediate configuration
# https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=intermediate&openssl=1.1.1k&guideline=5.7
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions
    ssl_session_tickets off;

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
    ssl_dhparam /path/to/dhparam;

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

    # HSTS (ngx_http_headers_module is required) (63072000 seconds)
    add_header Strict-Transport-Security "max-age=63072000" always;

    # OCSP stapling
    ssl_stapling on;
    ssl_stapling_verify on;

    # verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    # replace with the IP address of your resolver
    resolver 127.0.0.1;
}

Mozilla SSL Configuration Generator TLS1.3対応コード Apache Intermediate設定

# generated 2024-03-11, Mozilla Guideline v5.7, Apache 2.4.41, OpenSSL 1.1.1k, intermediate configuration
# https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=intermediate&openssl=1.1.1k&guideline=5.7

# this configuration requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    SSLEngine on

    # curl https://ssl-config.mozilla.org/ffdhe2048.txt >> /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateFile      /path/to/signed_cert_and_intermediate_certs_and_dhparams
    SSLCertificateKeyFile   /path/to/private_key

    # enable HTTP/2, if available
    Protocols h2 http/1.1

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"
</VirtualHost>

# intermediate configuration
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

そもそもTLS1.3とは何か

TLS 1.3とは、インターネット上でデータを安全に送受信するためのプロトコルである「トランスポート層セキュリティ」(Transport Layer Security)のバージョン1.3を指します。TLSは、ウェブサイトの閲覧、電子メールの送受信、インスタントメッセージング、およびVoice over IP (VoIP)など、インターネット上で安全にデータを交換するために広く使用されています。

TLS 1.3は、2018年に正式に発表され、それ以前のバージョンに比べていくつかの重要な改善が行われています。主な改善点は以下の通りです。

1. 速度の向上: TLS 1.3では、接続確立時のハンドシェイクが簡素化され、従来のバージョンに比べて速く安全な接続が行えるようになりました。これは、ラウンドトリップ時間を削減することで実現しています。
2. セキュリティの強化: 不安全とされる古い暗号スイートやプロトコルの機能が削除され、より安全な暗号化方法に焦点を当てています。これにより、中間者攻撃やその他のセキュリティ脅威に対する耐性が向上しました。
3. フォワードセキュリティ: すべてのTLS 1.3の通信にはフォワードセキュリティが必須となり、過去に記録された通信が将来的に解読されるリスクを減少させます。
4. プライバシーの向上: セッション再開メカニズムが改善され、以前のセッションの識別子を使って新しいセッションを速やかに確立できるようになりました。これはプライバシー保護にも寄与しています。

TLS 1.3は、インターネット通信のセキュリティと効率を大きく向上させることで、ユーザーのデータ保護に貢献しています。現在、多くのウェブサイトやオンラインサービスで採用されているため、TLS 1.3をサポートするブラウザやシステムを使用することが推奨されます。

なぜTLS1.3が必要なのか

TLS 1.3が必要な理由は、主にセキュリティ、パフォーマンス、およびプライバシーの向上に基づいています。以下に、TLS 1.3が以前のバージョンに比べて持つ重要な利点をいくつか挙げます。

セキュリティの強化

1. 廃止された脆弱な機能: TLS 1.3では、以前のバージョンで使用されていたがセキュリティ上の問題が指摘されていた多くの暗号スイートや機能が削除されました。これにより、脆弱性を突く攻撃のリスクが減少しました。
2. フォワードセキュリティの強制: TLS 1.3では、すべての接続がフォワードセキュリティを使用するようになり、セッションの暗号鍵が将来的に漏洩したとしても、過去の通信が解読されるリスクが大幅に減少します。

パフォーマンスの向上

1. 簡素化されたハンドシェイクプロセス: TLS 1.3では、接続の確立に必要なハンドシェイクのラウンドトリップが減少しました。これにより、特に遅延が大きいネットワーク環境での通信速度が向上します。
2. セッション再開の最適化: セッション再開メカニズムが改善され、以前のセッションからの情報を活用してさらに迅速に安全な接続を確立できるようになりました。

プライバシーの保護

1. 暗号化されたハンドシェイク: TLS 1.3では、ハンドシェイクの初期段階からデータの暗号化を開始します。これにより、中間者が通信の詳細を観察することがより困難になり、ユーザーのプライバシーが強化されます。

互換性と将来性

1. 広範なサポート: 主要なウェブブラウザやオペレーティングシステムはTLS 1.3を広範囲にサポートしており、最新のセキュリティ標準を採用することでユーザーとシステムを保護しています。
2. 将来のセキュリティ基準への準拠: セキュリティは常に進化しており、TLS 1.3は最新の脅威に対応し、将来的なセキュリティ基準に準拠するための基盤を提供します。

これらの理由から、TLS 1.3はオンライン通信の安全性、速度、および信頼性を大幅に向上させる重要な技術です。ウェブサイト運営者やサービスプロバイダーにとって、TLS 1.3へのアップグレードは、ユーザー体験を改善し、最高レベルのセキュリティ保護を提供するための重要なステップとなります。

日本の上場企業のウェブサイトのTLS1.3対応率:44.1%

日本の上場企業のウェブサイト3715件のTLS1.3対応状況についての調査によると、日本企業のウェブサイト全体のTLS1.3対応率は41.1%となっています。(2023年7月時点)

出典： 日本の上場企業3715社の公式サイトのSSL/TLSセキュリティ脆弱性ダッシュボード

日本企業の各業界ごとのTLS1.3対応率は以下のようになります（has_tls13がTLS1.3導入率です）。最大：64％（空運業）、最小：15％（パルプ・製紙業）。低い業界では、業界内の15％しか対応していないという状況です。

出典： 日本の上場企業3715社の公式サイトのSSL/TLSセキュリティ脆弱性ダッシュボード

さらに証券商品業界は39％、銀行業で55%、情報通信業で48％となっており、ウェブサイトで取り扱う通信の機密性が高い業界であっても、低い対応率に留まっています。

憂慮すベき理由

上場企業のウェブサイト[1]は国外の攻撃者から見たとき「日本経済の顔」ですから、機密性の高い情報や顧客情報を扱う場合は当然として、POSTリクエストは問い合わせページでしかしない、という「最小構成」（だから問題ないというスタンス）の場合であっても、TLS1.3に対応することが推奨されます。理由は、すべてのユーザーが機密情報の扱いに高いリテラシーを持つわけではなく、問い合わせフォームで個人情報やパスワードなどのログイン情報を平文で書いてしまうユーザーもいるでしょうから、暗号化の強度の強さはこうした「下ブレリスク」をカバーできます。最も弱い部分から鎖は切れます。よって、極力最新の暗号化プロトコルであるTLS1.3に対応することが、情報資産の善管注意義務という点でも、CSR（将来的にはコンプライアンス）の点でも最適です。なぜなら全ては顧客情報の保護、に関わるからです。

これは必ずしも誇張ではなく、国外の攻撃者は様々な攻撃ベクトルで企業を狙います。当社が最近テイクダウンを行ったフィッシングサイト事案においても、資本金数十億円規模の国内金融機関のウェブサイトが狙われています。これはフィッシングでありソーシャルベクトルからの攻撃ですが、その標的選定調査（ReconPhase）において技術的脆弱性についてのプロファイリングが行われたであろうことは想像にかたくありません。

[1] 上場企業のウェブサイトを例に上げる理由は、国外の攻撃者が標的企業を調べるとき最初に参照するのは四季報のような「投資目録」であり、そこに載るURLは企業の公式ウェブサイトだからです。仮に情報価値の高い処理は別サーバーに分けているとしても、公式サイトが入口になるため、「最も弱い部分」つまりセキュリティ意識の「下限」を知られてしまいます。上場企業の公式サイトのセキュリティ状態の総和は、日本経済のセキュリティ意識の下限の代表値、ということです。