HAProxyでTLS 1.3強制移行｜旧クライアント互換性の段階的廃止と影響測定

TLS 1.0/1.1廃止が「今すぐ」必要な理由：2026年のCVEランドスケープ

2026年に入り、TLS 1.0・1.1を対象とした脆弱性の悪用報告が再び増加傾向にあります。POODLE・BEAST・SWEET32といった旧来の攻撃手法は既知でありながら、インターネット上には依然としてこれらのプロトコルを受け入れるエンドポイントが残存しており、攻撃者にとって格好の標的となっています。

CVE-2024-xxxx系のTLSダウングレード攻撃に関するアドバイザリも継続的に発行されており、PCI DSS v4.0が2025年3月に完全施行されたことで、カード決済に関わるサービスではTLS 1.2未満の無効化が必須要件となりました。さらに、NIST SP 800-52 Rev.3ドラフトはTLS 1.3を推奨プロトコルとして明確に位置付けています。

HAProxyはリバースプロキシ・ロードバランサとして多くの本番環境で使われており、TLSネゴシエーションの集約点になっているケースがほとんどです。ここを一括で制御できることが強みである一方、設定を誤ると一瞬でサービスが落ちます。段階的な廃止と影響測定を組み合わせたアプローチが、現場で選ばれる理由はそこにあります。

現状の把握：どのクライアントが旧TLSを使っているか

移行を始める前に、現在のトラフィックでTLS 1.0・1.1を利用しているクライアントの割合を把握しておくことが不可欠です。HAProxy 2.6以降では ssl_fc_protocol 変数をログに出力できるため、まずはアクセスログを拡張します。

frontend https-in
    bind *:443 ssl crt /etc/ssl/certs/server.pem alpn h2,http/1.1
    log-format "%ci:%cp [%t] %f %b/%s %Tw/%Tc/%Tt %B %tsc %ac/%fc/%bc/%sc/%rc %{+Q}r ssl_version=%sslv ssl_cipher=%sslc"

数日間このログを収集し、ssl_version=TLSv1 や ssl_version=TLSv1.1 の行数を集計します。

awk '{for(i=1;i<=NF;i++) if($i~/^ssl_version=/) print $i}' /var/log/haproxy.log \
  | sort | uniq -c | sort -rn

この数字が「ゼロに近い」場合は強制移行のリスクが低く、「数パーセント以上」残っている場合は段階的廃止が必要になります。古いモバイルSDKを使っているアプリ、レガシーなBtoBパートナーシステム、組み込みデバイスからのAPIコールは見落としがちな発生源です。ログ期間は最低1週間、月次バッチが走る場合はひと月分取得するのが安全です。

段階的廃止の手順：警告フェーズ→制限フェーズ→強制フェーズ

いきなり ssl-min-ver TLSv1.3 に切り替えるのではなく、フェーズを分けて進めることで切り戻しコストを最小化できます。

フェーズ1：ログ強化（影響なし）

前節のログ設定を本番に投入し、2週間データを蓄積します。この段階では接続拒否は発生しません。アラートを設定して旧TLS接続数の推移を可視化しておくと、後続フェーズの判断材料になります。

フェーズ2：TLS 1.0を無効化（TLS 1.1はまだ許容）

frontend https-in
    bind *:443 ssl crt /etc/ssl/certs/server.pem \
        ssl-min-ver TLSv1.1 \
        alpn h2,http/1.1
    # TLS 1.0接続はここで拒否される

変更後は haproxy -c -f /etc/haproxy/haproxy.cfg で設定ファイルの構文チェックを行い、systemctl reload haproxy でホットリロードします。reload はワーカープロセスを入れ替えるため、既存コネクションを切断せずに設定を反映できます。この点はrestartとの重要な違いです。

フェーズ3：TLS 1.2以上を強制（TLS 1.1も廃止）

frontend https-in
    bind *:443 ssl crt /etc/ssl/certs/server.pem \
        ssl-min-ver TLSv1.2 \
        alpn h2,http/1.1

フェーズ2の安定運用を1〜2週間確認できたら、フェーズ3へ移行します。

フェーズ4：TLS 1.3のみを強制（最終形）

frontend https-in
    bind *:443 ssl crt /etc/ssl/certs/server.pem \
        ssl-min-ver TLSv1.3 \
        alpn h2,http/1.1

    # TLS 1.3のみ許可する暗号スイートを明示
    ssl-default-bind-ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
    ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
    ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tlsv12

ssl-default-bind-ciphers はTLS 1.2以下用、ssl-default-bind-ciphersuites はTLS 1.3用の設定です。TLS 1.3ではRSA鍵交換が廃止されているため、設定上の重複を避けるために両方を明示するのが現場での定番になっています。

影響測定と検証：切り替え後に確認すべき3つの指標

各フェーズの切り替え直後は、以下の3点を集中的に監視します。

• SSL handshake エラー率：HAProxyの統計ページ（stats uri /haproxy-stats）またはPrometheusエクスポーター経由で ssl_conn_total と ssl_err_handshake の比率を確認します。ベースラインと比べて急増していれば、切り捨てたプロトコルを使うクライアントが存在します。
• 4xx/5xxエラー増加：TLSネゴシエーション失敗はHTTPレイヤーに上がってこないため、接続タイムアウトや接続リセットとしてアプリ側のエラーログに現れます。アプリ側のエラーモニタリングをあわせて確認します。
• 外形監視による確認：curl や openssl s_client を用いて、意図したTLSバージョンのみが通過できることを外部から確認します。

# TLS 1.2が拒否されることを確認
openssl s_client -connect example.com:443 -tls1_2 2>&1 | grep -E "Protocol|handshake failure"

# TLS 1.3が通ることを確認
openssl s_client -connect example.com:443 -tls1_3 2>&1 | grep "Protocol"

TLS 1.2を強制した接続が handshake failure を返し、TLS 1.3の接続が TLSv1.3 を返せば、設定が正しく機能しています。CI/CDパイプラインにこの確認を組み込んでおくと、設定変更時のデグレを自動検知できます。

切り戻しと注意点：「元に戻せる」設計を維持する

切り戻しはシンプルです。ssl-min-ver の値を前フェーズに戻してreloadするだけです。HAProxyの設定はテキストファイル1枚なので、Gitで管理して変更履歴を追うのが安全策として広く採用されています。

注意点として、いくつかの運用現場で踏まれているトラップを挙げます。

• バックエンドのTLS設定との不整合：HAProxyからバックエンドサーバー間もTLS通信している場合、ssl-default-server-* 系のオプションも同様に更新が必要です。フロントエンドだけ変更して終わりにすると、内部通信でTLS 1.1が継続するケースがあります。
• OCSP staplingとの組み合わせ：TLS 1.3ではOCSP staplingの挙動が変わる実装があります。HAProxy 2.8以降では ocsp-update on が推奨設定ですが、古いバージョンでは手動更新が必要です。
• セッションチケットの扱い：TLS 1.3のセッション再開はセッションチケットではなくPSK（Pre-Shared Key）方式になります。複数のHAProxyインスタンスをクラスタ構成にしている場合、セッション継続性の設計を見直す必要があります。
• WAF・IDSとの連携：インライン配置のWAFがTLS 1.3のオフロードに対応していないケースが稀にあります。HAProxy側だけ進んでWAFがTLS 1.3を解析できないと、検査が素通りになるリスクがあります。

2026年現行環境での差分：HAProxy 3.xと最新ディストリ固有の考慮事項

HAProxy 3.0（2024年リリース）以降、いくつかのデフォルト値が変更されています。2026年現在、Ubuntu 24.04やRHEL 9系のリポジトリで提供されているHAProxyはおおむね2.8〜3.1系であり、以下の差分が運用上の注意点です。

HAProxy 3.0ではTLSライブラリとしてOpenSSL 3.xが標準となり、FIPS 140-3モジュールとの統合が容易になりました。OpenSSL 3.xではTLS 1.0・1.1はデフォルトで無効化されており、HAProxy側で明示的に有効化しない限りそもそも使えません。つまり、Ubuntu 24.04以降の新規構築環境であれば、TLS 1.0/1.1はデフォルトで既に無効化されているケースが多いです。

一方で、古いOSから移行せずに稼働し続けているCentOS 7系やDebian 10系の環境では、OpenSSL 1.0/1.1が使われており、HAProxy側の設定変更だけでは不十分な場合があります。openssl version と haproxy -vv | grep OpenSSL でリンクされているOpenSSLバージョンを確認し、必要であればOSレベルのcrypto-policyも更新します。

# RHEL/CentOS系でシステム全体のTLSポリシーをTLS 1.2以上に強制する場合
update-crypto-policies --set DEFAULT:NO-SHA1

# 確認
update-crypto-policies --show

また、HAProxy 2.9以降では tune.ssl.default-dh-param のデフォルト値が4096ビットに引き上げられています。旧バージョンから設定ファイルを流用している場合、明示的に小さい値を設定しているケースがあります。TLS 1.3ではDH鍵交換はECDHEが主体になるため実質的な影響は限定的ですが、TLS 1.2との混在期間中は見直しておくべき項目です。

HAProxy Enterpriseを利用している環境では、2026年現在のバージョンでTLS 1.3のPost-Quantum暗号（X25519Kyber768）の実験的サポートが提供されています。PQ暗号はまだ本番投入には早い段階ですが、将来の準備として動作確認だけ進めておく現場も増えています。

TLS 1.3への強制移行は、設定変更そのものよりも「どのクライアントが影響を受けるか」の事前測定と、フェーズを区切った段階的な切り替えにこそ工数をかけるべき作業です。ログの収集から始めて、数週間かけてフェーズを進める計画を立てることが、ダウンタイムゼロでの移行を実現するための現実的な道筋です。