TLS 1.0の問題の解決、第2版
このドキュメントでは、Microsoft オペレーティング システム上に構築されたソフトウェアにおけるトランスポート層セキュリティ (TLS) プロトコル バージョン 1.0 への依存関係をすばやく特定し、削除するための最新のガイダンスを示します。その後、Microsoft によって提供される、ご自分の顧客とオンライン サービスを保護するための製品の変更と新機能の詳細について説明します。 これは、TLS 1.2 以降のネットワーク環境への移行計画を作成するための出発点として使用することを目的としています。 ここで説明するソリューションは、Microsoft 以外のオペレーティング システムや暗号化ライブラリにおいて TLS 1.0の使用を削除するときにも役立つ場合がありますが、このドキュメントでは取り上げません。
TLS 1.0 は、コンピューター ネットワーク上の暗号化チャネルを確立するために、1999年に初めて定義されたセキュリティ プロトコルです。 Microsoft では、Windows XP/サーバー 2003 からこのプロトコルがサポートされています。 TLS 1.0 は、最新 OS で使用される既定のセキュリティ プロトコルではなくなっていますが、下位互換性のために引き続きサポートされています。 TLS 1.0 では規制の要件が増え、新しいセキュリティの脆弱性が発見されています。これは、TLS 1.0を完全に無効にするというインセンティブを企業に与えます。
Microsoft では、お客様に対し、環境内で TLS 1.0の依存関係を削除し、可能であればオペレーティング システム レベルで TLS 1.0を無効にすることで、この問題に対処することをお勧めします。 ソフトウェア業界で TLS 1.0 がサポートされていた期間の長さを考えると、あらゆる TLS 1.0の廃止計画には次を含めることを強くお勧めします。
TLS 1.0 またはそれ以前のセキュリティ プロトコルのハードコードされたインスタンスを検出/修正するためのコード分析。
TLS 1.0 またはそれ以前のプロトコルを使用しているオペレーティング システムを特定するための、ネットワーク エンドポイントのスキャンとトラフィック分析。
TLS 1.0を無効にした状態での、アプリケーション スタック全体を通した完全な回帰テスト。
レガシ オペレーティング システムと開発ライブラリ/フレームワークの、既定で TLS 1.2 とネゴシエートできるバージョンへの移行。
TLS 1.2のサポートに関する問題を特定するための、ビジネスで使用されるオペレーティング システム間での互換性テスト。
ご自分のビジネス パートナーや顧客と連携して、TLS 1.0を廃止する計画を通知する。
TLS 1.0を無効にした場合、ご自分のサーバーに接続できなくなる可能性があるクライアントを把握する。
このドキュメントの目的は、TLS 1.0の無効化を妨げる技術的な障壁を削除するのに役立つ推奨事項を提供すると同時に、この変更による影響をご自身の顧客に対して十分に認識させることです。 このような調査を完了することは、TLS 1.0の次のセキュリティの脆弱性によるビジネスへの影響を軽減するのに役立ちます。 このドキュメントでは、TLS 1.0の廃止のリファレンスに TLS 1.1 も含まれています。
エンタープライズ ソフトウェア開発者は、将来のセキュリティ プロトコルの侵害に対処するために、今後より安全で機敏なソリューション (暗号化の機敏性とも呼ばれます)を採用する必要が戦略的にあります。 このドキュメントでは、TLSのハードコードを排除するためのアジャイル ソリューションを提案していますが、より広範な暗号化の機敏性ソリューションについては、このドキュメントでは扱いません。
Microsoft による TLS 1.0の実装の現在の状態
Microsoft による TLS 1.0の実装には、既知のセキュリティ脆弱性がありません。 Microsoftの実装に固有ではない将来のプロトコル ダウングレード攻撃や、その他の TLS 1.0の脆弱性の可能性により、TLS 1.2 よりも古いすべてのセキュリティ プロトコルへの依存関係を可能な限り削除することをお勧めします (TLS 1.1/1.0/ SSLv3/SSLv2)。
この TLS 1.2 以降への移行を計画するときに、開発者とシステム管理者は、従業員やパートナーによって開発されたアプリケーションにプロトコル バージョンがハードコードされている可能性があることを認識する必要があります。 ここでは、ハードコードとは、TLS バージョンが古いバージョンに固定され、より新しいバージョンよりも安全性が低くなっていることを意味します。 ハードコードされたバージョンより新しい TLS バージョンは、問題のプログラムを変更しない限り、使用できません。 このクラスの問題は、ソース コードの変更とソフトウェア更新プログラムの配置なしに解決することはできません。 プロトコル バージョンのハードコードは、テストとサポート性のために以前は一般的でした。多くの異なるブラウザーとオペレーティング システムには、さまざまなレベルの TLS サポートが備わっていたためです。
Windows でサポートされている TLSのバージョン
多くのオペレーティング システムでは、古い TLS バージョンが既定値になっているか、考慮する必要があるサポート上限があります。
図 1： OS バージョン別のセキュリティ プロトコルのサポート
| Windows OS | SSLv2 | SSLv3 | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|---|---|
| Windows Vista | Enabled | 有効 | Enabled | サポートされていません | サポートされていません | サポートされていません |
| Windows サーバー 2008 | Enabled | 有効 | Enabled | 無効* | 無効* | サポートされていません |
| Windows 7 (WS2008 R2) | Enabled | 有効 | Enabled | 無効* | 無効* | サポートされていません |
| Windows 8 (WS2012) | 無効 | Enabled | 有効 | 有効 | Enabled | サポートされていません |
| Windows 8.1 (WS2012 R2) | 無効 | Enabled | 有効 | 有効 | Enabled | サポートされていません |
| Windows 10 | 無効 | Enabled | 有効 | 有効 | Enabled | サポートされていません |
| Windows 11 | 無効 | Enabled | 有効 | 有効 | 有効 | Enabled |
| Windows サーバー 2016 | サポートされていません | 無効 | Enabled | 有効 | Enabled | サポートされていません |
| Windows サーバー 2016 | サポートされていません | 無効 | Enabled | 有効 | Enabled | サポートされていません |
| Windows サーバー 2019 | サポートされていません | 無効 | Enabled | 有効 | Enabled | サポートされていません |
| Windows サーバー 2019 GS エディション | サポートされていません | 無効 | 無効 | 無効 | Enabled | サポートされていません |
| Windows サーバー 2022 | サポートされていません | 無効 | 無効 | 無効 | Enabled | Enabled |
Windows サーバー 2019 GS エディションは Microsoft SDL に準拠しています。TLS 1.2 は、制限付きの暗号スイートのセットのみを使用します。
Windows サーバー 2022 エディションは、Microsoft SDL に準拠しており、TLS 1.2 および TLS 1.3 は、制限付きの暗号スイートのセットでのみ使用されます。
Windows サーバー 2008 で TLS 1.1/1.2を有効にするには、こちらのオプションの Windows Update パッケージを使用します。
IE/Edge での TLS 1.0/1.1の廃止について詳しくは、「Microsoft Edge および Internet Explorer 11 での TLS 接続の最新化」、「サイト互換性に影響を与える Microsoft Edge への変更」、「新しい Edge ブラウザーでの TLS/1.0 と TLS/1.1の無効化」をご覧ください
さまざまなクライアントがご自分のオンライン サービスに接続するときに、どの TLS バージョンが要求されるかを簡単に判断する方法は、Qualys SSL Labsの Handshake Simulationを参照することです。 このシミュレーションでは、製造元を横断するクライアントの OS とブラウザーの組み合わせを使用できます。 www.microsoft.com に接続したときに、シミュレートされたクライアントのさまざまな OS とブラウザーの組み合わせによってネゴシエートされる TLS プロトコル バージョンの詳細な例については、このドキュメントの最後にある付録 Aを参照してください。
まだ完了していない場合は、ご自分の企業、顧客、およびパートナーによって使用されているオペレーティング システムのインベントリを実行することを強くお勧めします (顧客とパートナーについては、アウトリーチ/コミュニケーションを利用するか、少なくとも HTTP User-Agent 文字列のコレクションを使用します)。 このインベントリは、ご自分の企業ネットワーク エッジでのトラフィック分析によってさらに補完することができます。 このような状況では、トラフィック分析によって、サービスに接続した顧客/パートナーが正常にネゴシエートした TLS バージョンを得られますが、トラフィック自体は暗号化されたままになります。
TLS 1.0 への依存関係を排除するための Microsoft エンジニアリングの改善
このドキュメントのバージョン 1のリリース以降、Microsoft では、TLS 1.0の廃止をサポートするために多数のソフトウェア更新プログラムと新機能を提供しています。 これには以下が含まれます。
クライアント IP/ユーザー エージェント文字列、サービス URI、TLS プロトコル バージョン、および暗号スイートを相互に関連付けるための IIS カスタム ログ。
- このログ記録を使用すると、管理者は最終的に、脆弱な TLS への顧客の接続を定量化できます。
SecureScore - Office 365での TLS 1.0のサポートは 2018年 10月に終了したため、Office 365テナントの管理者が各自の脆弱な TLSの使用を特定するのに役立つように、この情報を共有するために SecureScore ポータルが構築されています。
Office 365テナントの管理者は、このポータルを使用して、TLS 1.0 への依存関係を認識していない可能性がある自分の顧客に連絡するために必要な有益な情報を取得できます。
詳細については、https://securescore.microsoft.com/にアクセスしてください。
アプリ レベルのハードコードを排除し、フレームワークによって継承された TLS 1.0 への依存関係を防止するための .Net Frameworkの更新プログラム。
お客様が脆弱な TLS に対する .Netの依存関係を特定して排除できるようにするために、開発者用ガイダンスとソフトウェア更新プログラムがリリースされています。.NET Framework によるトランスポート層セキュリティ (TLS)のベスト プラクティス
- 参考： .NET 4.5 以下をターゲットとするすべてのアプリは、TLS 1.2をサポートするために変更する必要が生じる可能性があります。
TLS 1.2 は、従来の義務を果たす必要があるお客様を支援するために、Windows サーバー 2008 SP2 と XP POSReady 2009 に移植されています。
追加のお知らせは 2019年の前半に発表され、このドキュメントの後続の更新でお伝えします。
コード内での TLS 1.0 への依存関係の検出と修正
Windows OS によって提供される暗号化ライブラリとセキュリティ プロトコルを使用している製品について、以下のステップはアプリケーション内でのハードコードされた TLS 1.0の使用を特定するのに役立ちます。
AcquireCredentialsHandle()のすべてのインスタンスを特定します。 これにより、レビュー担当者は、TLS がハードコードされている可能性のあるコード ブロックにより接近できます。
ハードコードされた TLSの SecPkgContext_SupportedProtocols 構造および SecPkgContext_ConnectionInfo 構造のインスタンスを確認します。
ネイティブ コードで、0 以外の grbitEnabledProtocolsの割り当てを0 に設定します。 これにより、オペレーティング システムで既定の TLS バージョンを使用できるようになります。
FIPS モードが有効になっている場合は、無効にします。このドキュメントの TLS 1.0/1.1を明示的に無効にするために必要な設定と競合する可能性があるためです。 詳細については、付録 Bをご覧ください。
サーバー 2012 以前でホストされる WinHTTPを使用しているすべてのアプリケーションを更新して再コンパイルします。
マネージド アプリ – 最新の .NET Framework バージョンに向けてリビルドおよび再ターゲットします
アプリケーションに WinHttpSetOptionを使用して TLS 1.2をサポートするためのコードを追加する必要があります
万全の準備をするために、ソース コードとオンライン サービス構成ファイルをスキャンし、TLSのハードコードで一般的に使用される列挙型の値に対応する次のパターンを調べます。
SecurityProtocolType
SSLv2、SSLv23、SSLv3、TLS1、TLS 10、TLS11
WINHTTP_FLAG_Standard EditionCURE_PROTOCOL_
SP_PROT_
NSStreamSocketSecurityLevel
PROTOCOL_SSLまたはPROTOCOL_TLS
上記のすべてのケースで推奨される解決策は、ハードコードされたプロトコル バージョンの選択を削除し、オペレーティング システムの既定値に従うことです。 DevSkimを使用している場合は、こちらをクリックして、独自のコードで使用できる上記のチェックに関するルールを参照してください。
Windows PowerShell スクリプトまたは関連するレジストリ設定を更新する
Windows PowerShell では、使用可能なプロトコルに TLS 1.2 が含まれない .NET Framework 4.5 が使用されます。 これを回避するには、次の2つのソリューションを使用できます。
問題のスクリプトを変更して以下を含めます。
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;.NET アプリから TLS 1.2 接続を作成する必要があるコンピューターに、システム全体のレジストリ キーを追加します (例： グループ ポリシー経由で)。 これにより、.NET では "システム既定の" TLS バージョンが使用されるようになり、使用可能なプロトコルとして TLS 1.2 が追加され、さらに、スクリプトで将来の TLS バージョンを、それが OS でサポートされたときに使用できるようになります。 (例： TLS 1.3)
reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d1/f /reg：64
reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d1/f /reg：32
ソリューション (1) と (2) は相互に排他的です。つまり、これらを一緒に実装する必要はありません。
最新の .Net Framework バージョンを使用してマネージド アプリケーションをリビルド/再ターゲットする
4.7 より前の .NET framework バージョンを使用するアプリケーションでは、基になる OSの既定値に関係なく、TLS 1.0のサポートが効果的に制限される場合があります。 詳細については、以下の図と .NET Framework でのトランスポート層セキュリティ (TLS)のベスト プラクティスを参照してください。
SystemDefaultTLSVersion は、アプリ レベルの TLS バージョンのターゲット設定よりも優先されます。 ベスト プラクティスとして、常に OSの既定の TLS バージョンに従うことをお勧めします。 また、これは、アプリで今後の TLS 1.3のサポートを利用できるようにする、唯一の暗号アジャイル ソリューションでもあります。
4.5.2 や3.5 などの古いバージョンの .NET Frameworkを対象としている場合、既定では、アプリケーションで SSL 3.0 や TLS 1.0 などの古い非推奨のプロトコルが使用されます。 .NET Framework 4.6 などの新しいバージョンの .NET Framework にアップグレードするか、'UseStrongCrypto'の適切なレジストリ キーを設定することを強くお勧めします。
TLS 1.2 以降でのテスト
上記のセクションで推奨されている修正に従った製品は、プロトコル ネゴシエーションに関するエラーと、エンタープライズ内の他のオペレーティング システムとの互換性について、回帰テストを行う必要があります。
この回帰テストにおける最も一般的な問題は、TLS 1.2をサポートしていないオペレーティング システムまたはブラウザーからのクライアント接続の試行に起因する TLS ネゴシエーションの失敗です。
- たとえば、Vista クライアントでは、TLS 1.2 以降用に構成されているサーバーとの TLSのネゴシエートに失敗します。Vista でサポートされている TLSの最大バージョンは 1.0 であるためです。 そのクライアントは、TLS 1.2 以降の環境では、アップグレードするか使用停止にする必要があります。
証明書ベースの相互 TLS 認証を使用する製品では、追加の回帰テストが必要になる場合があります。TLS 1.0 に関連付けられた証明書の選択コードは、TLS 1.2の場合よりも情報が少ないためです。
- 製品が標準以外の場所 (Windowsの標準の名前付き証明書ストアの外部) からの証明書を使用して MTLSをネゴシエートする場合、証明書が正しく取得されるように、そのコードを更新する必要がある場合があります。
問題点を探すためにサービスの相互依存関係を確認する必要があります。
サード パーティのサービスと相互運用するサービスでは、これらサード パーティとの相互運用テストを追加で行う必要があります。
Windows 以外のアプリケーションやサーバー オペレーティング システムが使用されている場合は、それらで TLS 1.2をサポートできることを調査および確認する必要があります。 これを確認する最も簡単な方法は、スキャンすることです。
オンライン サービスでこれらの変更をテストするためのシンプルな計画は、次の要素で構成されます。
運用環境システムのスキャンを実行して、TLS 1.2をサポートしていないオペレーティング システムを特定します。
「コード内での TLS 1.0 への依存関係の検出と修正」の説明に従って、ソース コードとオンライン サービス構成ファイルをスキャンし、ハードコードされた TLSを調べます
必要に応じてアプリケーションを更新および再コンパイルします。
Managed apps
最新の .NET Framework バージョンに対してリビルドします。
OSの既定の設定を使用するために、使用されているすべての SSLProtocols 列挙型が SSLProtocols.None に設定されていることを確認してください。
WinHTTP アプリ – TLS 1.2をサポートするために WinHttpSetOption でリビルドします
レジストリを使用して TLS 1.2 より古いすべてのセキュリティ プロトコルを無効にして、運用前環境またはステージング環境でテストを開始します。
テスト中に発生した TLS ハードコードの残りのインスタンスをすべて修正します。 ソフトウェアを再配置し、新しい回帰テストを実行します。
TLS 1.0の廃止計画をパートナーに通知する
TLS ハードコードに対処し、オペレーティング システムと開発フレームワークの更新が完了したら、TLS 1.0の廃止を選択する場合は顧客とパートナーとの連携が必要になります。
パートナーおよび顧客への早期のアウトリーチは、TLS 1.0 廃止のロールアウトを成功させるために不可欠です。 これは少なくとも、ブログ記事、ホワイトペーパー、またはその他の Web コンテンツで構成されている必要があります。
各パートナーは、前のセクションで説明したオペレーティング システム、コード スキャン、回帰テストのイニシアティブを通じて、各自の TLS 1.2 準備状況を評価する必要があります。
まとめ
TLS 1.0 への依存関係を削除することは、徹底して推進するには複雑な問題です。 現在、Microsoft と業界のパートナーではそのための作業が行われています。OS コンポーネントや開発フレームワークからその上に構築されたアプリケーションやサービスまで、製品スタック全体が既定でより安全になるようにするためです。 このドキュメントに記載されている推奨事項に従うことにより、企業で適切な計画を立て、予想される課題を把握することができます。 また、ご自分の顧客がより適切に移行への準備を行えるようにするためにも役立ちます。
付録 A： www.microsoft.com に接続するさまざまなクライアントの Handshake Simulation (SSLLabs.com 提供)
付録 B： FIPS モードを保持しながら TLS 1.0/1.1を廃止する
ネットワークに FIPS モードが必要で、TLS 1.0/1.1を廃止する必要もある場合は、次のステップに従います。
レジストリを使用して TLS バージョンを構成します。それには、不要な TLS バージョンに対して "Enabled"を0 に設定します。
グループ ポリシーを使用して、Curve 25519を無効にします (サーバー 2016のみ)。
関連する FIPS パブリケーションで許可されていないアルゴリズムを使用するすべての暗号スイートを無効にします。 サーバー 2016の場合 (既定の設定が有効になっていることを仮定します)、これは RC4、PSK、および NULL 暗号を無効にすることを意味します。
共同作成者/感謝
Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson