Windows Server 2019 で意図せず TLS 1.3 通信が行われたことによるトラブル事例

Windows Server 2019ではTLS 1.3がサポートされませんが、その上で稼働するHTTPサーバアプリケーション (TLS 1.3に対応したもの) の設定によっては、TLS 1.3での接続が確立される場合があります。ここでは、Windows Server 2019上のIBM HTTP ServerでTLS 1.3での通信が意図せず行われた事例を紹介します。

本記事は、筆者が過去に対応したトラブル事例について技術的な部分にフォーカスして作成したものです。技術的な内容を解説する上で本質的でない情報 (業務的な文脈や環境固有の情報など) は伏せてあります。

トラブルの概要

ある業務アプリケーションにて、特定の処理を実行した際の異常終了が偶発的に起きていました。異常終了時のログには「セキュリティで保護されたチャネル サポートでエラーが発生しました」というメッセージが確認されました。

システム構成について

以降の解説のために必要なので、業務アプリケーションの実行環境に関する最小限の説明をします。

• 業務アプリケーションはWindows 10またはWindows 11上で動作する (以降、クライアントと呼びます)
• クライアントは、問題の処理を実行する際にサーバ (Windows Server 2019) と通信を行う
• サーバ上ではIBM HTTP Server(IHS) / WebSphere Application Server(WAS) が稼働しており、クライアントとIHSの間はTLSで通信する (サーバ側にはデータベースもあるが、重要ではないので説明を省略)
  • IHSのバージョンは9.0.5.12 (TLS 1.3に対応しているバージョン¹)

発生条件

• クライアントのOSがWindows 11であり、TLS 1.3が有効になっていること²
• サーバがWindows Server 2019、またはそれ以前であること
• IHSでTLS 1.3が有効に設定されていること (詳しくは後述)

上記の条件がすべて満たされる場合に、クライアントとサーバ (IHS) 間での通信がTLS 1.3によるものとなります。つまり、ハンドシェイクによる合意バージョンがTLS 1.3となります³。

発生事象

上記条件の下で特定の処理を開始してしばらくすると、サーバからTLS通信の切断が行われます。その際、サーバ側には以下のエラーメッセージが出力されます。

セキュリティで保護されたチャネル サポートでエラーが発生しました。

エラーの原因と解決方法

詳しい解説の前に、このエラーの出どころと対処方法について大まかに説明します。

上記エラーの理由を端的に述べると「TLS 1.3通信がサポートされないWindows Server 2019において、TLS 1.3での接続を確立してしまったから」です。このとき、サーバ上のSecure Channelから上記の「セキュリティで保護された～～」のエラーが発せられ、TLS通信が終了します (Secure Channelについては後述)。

IHS 9.0.5.2以降ではTLS 1.3がデフォルトで有効となります。したがって、「IHSでTLS 1.3を無効化するよう明示的に設定すること」でエラーを回避できます。

具体的な設定内容は、以下のようにSSLProtocolDisableにTLSv13を明示的に記述します。

httpd.conf (抜粋)

SSLEnable
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11 TLSv13
SSLProtocolEnable TLSv12

なお、クライアントがWindows 10のケースでは本事象の発生は確認されませんでしたが、これはWindows 10ではTLS 1.2までしかサポートされておらず、TLSハンドシェイクの合意バージョンが1.2となったためです。

技術的な補足

ここまでトラブル事例の概略を説明しましたが、以降は個々の技術要素についてもう少し深堀りして説明します。

TLSの合意バージョンについて

今回の対応の際に、クライアント側でパケットキャプチャを行ってTLSハンドシェイクの中身 (特に、合意したTLSバージョン) を確認しました。

前提条件:

• クライアントのOSはWindows 11またはWindows 10で、TLSの設定はともにデフォルトのままである。すなわち、
  • Windows 11では、TLS 1.2/1.3が有効
  • Windows 10では、TLS 1.2のみ有効
• サーバではIHS 9.0.5.12が稼働しており、TLS1.2/1.3が有効に設定されている

クライアントがWindows 11の場合

クライアント、サーバがサポートするTLSバージョンは下記のようになります。

• クライアント: TLS1.2, TLS1.3
• サーバ: TLS1.2, TLS1.3

よって、合意バージョンはクライアントとサーバが共通してサポートする最大バージョンであるTLS 1.3となります。

実際にパケットキャプチャ結果を確認したところ、以下のようになっていました。

• Client Hello
  • クライアントがサポートするバージョンは、拡張フィールドsupported_versionに格納される。格納されていた値はTLS 1.3, TLS 1.2
• Server Hello
  • サーバが提示するバージョンは、拡張フィールドsupported_versionに格納される。格納されていた値はTLS 1.3

よって、クライアント・サーバ間の通信はTLS 1.3で行われることになります。

クライアントがWindows 10の場合

クライアント、サーバがサポートするTLSバージョンは下記のようになります。

• クライアント: TLS1.2
• サーバ: TLS1.2, TLS1.3

この場合、合意バージョンはTLS 1.2となります。

実際にパケットキャプチャ結果を確認したところ、以下のようになっていました。

• Client Hello
  • クライアントがサポートするバージョンは、フィールドVersionに格納される。格納されていた値はTLS 1.2
• Server Hello
  • サーバが提示するバージョンは、フィールドVersionに格納される。格納されていた値はTLS 1.2

よって、クライアント・サーバ間の通信はTLS 1.2で行われることになります。

IBM HTTP ServerのTLS関連設定について

IBM HTTP Server (IHS)⁴ の基本的な設定は、httpd.confファイルにディレクティブを記述することで行われます。TLS関連の設定はSecure Sockets Layer (SSL) directivesとしてまとめられています。

TLSプロトコルの有効化に関するディレクティブは以下の3つがあります。

• SSLEnable
  • 仮想ホストに対して、SSL/TLSを有効化する
• SSLProtocolDisable
  • クライアントに使用を許可しないSSL/TLSプロトコル (バージョン) を、仮想ホストごとに指定する
• SSLProtocolEnable
  • 有効化するSSL/TLSプロトコル (バージョン) を指定する

この仕様には少し曖昧な点があります。今回の事例では当初、これらのディレクティブが下記のように設定されていました。

httpd.conf (抜粋)

SSLEnable
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11
SSLProtocolEnable TLSv12

TLS 1.3を意味するTLSv13はSSLProtocolDisable/SSLProtocolEnableのいずれにも指定されておらず、上記仕様からはTLS 1.3が有効になるのか無効になるのかはっきりしません。しかし、PH17128というパッチにはこの回答が示されています。

• For IHS on distributed platforms, TLS 1.3 is implicitly enabled for any virtual host with "SSLEnable"

つまり、(IHS 9.0.5.2以降のバージョンにおいては) SSLEnableディレクティブを記述することでTLS 1.3が暗黙的に有効化されます。上記の設定にはSSLEnableが記述されているため、「TLS 1.3は有効」ということになります。

IHS 9.0.5.2以降でTLS 1.3を無効にするためには、以下のようにSSLProtocolDisableに明示的に指定する必要があります。

httpd.conf (抜粋)

SSLEnable
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11 TLSv13
SSLProtocolEnable TLSv12

Windows Server 2019においてはOSレベルでTLS 1.3がサポートされないため、意図せずTLS 1.3接続が確立されることを防ぐため上記のように設定することが推奨されます。

WindowsのSecure Channel (Schannel) について

冒頭で触れた「セキュリティで保護されたチャネル サポートでエラーが発生しました」というメッセージは、WindowsのSSP (Security Support Provider) であるSecure Channel (Schannel)が出しているものです。

なお、上記の文言は日本語化したWindowsにおけるものです。元の英語のメッセージは "An error occurred in the secure channel support." であり、Secure Channel由来のエラーであることは明白です。

Secure ChannelはWindowsにおけるセキュリティ機能を提供するコンポーネントであり、このメッセージはセキュリティ機能において何かしらの問題が発生したことを示しています。本事例に照らして言えば、Windows Server 2019においてサポートされないTLS 1.3での通信が検出されたことでエラーが発せられたということです。

Secure ChannelにおけるTLSプロトコルのサポートに関する仕様を見てみましょう。

TLS 1.3 is supported starting in Windows 11 and Windows Server 2022. Enabling TLS 1.3 on earlier versions of Windows is not a safe system configuration.

"not a safe system configuration" というのは仕様として中々曖昧な表現ですが、筆者は「Windows 10およびServer 2019以前のOSでは、TLS 1.3の動作が保証されない」と解釈しています。現に、Windows Server 2019との間でTLS 1.3での接続が確立すること自体はありえる話です⁴。この仕様は、そのような場合においてTLS通信の動作が保証されない (何が起きても不思議ではない) ということを表現しています。

これは推測ですが、Secure Channelには通信の安全性をチェックする機構が備わっており、TLS 1.3 (プラットフォーム的にサポートされていない) を不正なものと判断して上記のエラーを発生されていたのではないかと思われます。しかしSecure Channelの実装がオープンになっていない以上、この点については想像の域を出ません。

まとめ

本記事では、Windows Server 2019でTLS 1.3通信が行われたことによるトラブル事例を基に、関連するIHSやWindowsのTLS関連の技術仕様について掘り下げました。エラーの根っこを探っていくと最終的にSecure Channelの実装というブラックボックスに突き当たるため、究極的な根本原因は残念ながら解明できません。

しかし明確に言えるのは、アプリケーションの設定は環境構成を考慮して適切に行わなければならないということです。本事例に照らせば「TLS 1.3の動作が保証されないWindows Server 2019においては、HTTPサーバ (IHS) でTLS 1.3を明示的に無効化するべき」ということです。

最後までお読みいただきありがとうございました。

参考にした情報源

• Secure Sockets Layer (SSL) directives - IBM Documentation
• Secure Channel - Win32 apps
• RFC8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC5246: The Transport Layer Security (TLS) Protocol Version 1.2

1. IHS 9.0.5.2以降でTLS 1.3がサポートされる (https://www.ibm.com/support/pages/apar/PH17128) ↩

2. Windows 11はデフォルトでTLS 1.2および1.3が有効になっている ↩

3. これらの条件を満たしてもセッションが正常に確立できず、データ通信が行われない場合もあります。ここでは実際にデータ通信を行えるかどうかには立ち入らず、ハンドシェイクがTLS 1.3で合意することにのみ着目することにします ↩

4. TLSのサポートに関するレジストリ値を変更することで、Windows Server 2019上で無理やりTLS 1.3を動作させる方法も知られています。しかし、そんなトリッキーなことをしなくても、ごく普通の状況でTLS 1.3での接続が確立しうるということを本事例が示しています ↩ ↩²