失効した証明書を使用する中間者。 パート2

前の記事では、証明書の状態を確認する（証明書が失効しているかどうかを確認する）基本的なメカニズムについて説明しました。 この記事では、次の質問に答えます。

1.最新のWebブラウザーでは、証明書ステータス検証メカニズムはどのように実装されていますか？
2. 誰のせいですか？ なぜ彼らはそのように実装されていますか？
3. 何をする ？ 見込みは何ですか？

この記事は、実際に使用されている証明書の状態を確認するメカニズムを理解することに興味がある人に役立ちます。

Habréはすでにこのトピックについて書いています（たとえば、 こことここ ）が、この記事では、最新のブラウザーで実行されるチェックのより詳細な説明、設定に関するより関連情報、最後に、これを修正する方法の説明を提供することにしました将来の状況。

Webブラウザに実装された証明書ステータスチェック

最新のWebブラウザに実装されている証明書ステータス検証メカニズムは、 前述の基本メカニズム（CRL、OCSP、OCSPステープリング）とそれらの変更の組み合わせです。 冗長性を確保するために、基本的なメカニズムの組み合わせが実行されます。証明書のステータスに関する情報のソースの1つが利用できなくなった場合、バックアップが使用されます。 たとえば、OCSPプロトコルは、証明書のステータスを確認するための主要なメカニズムとして使用できますが、OCSPサーバーが利用できない場合や障害が発生した場合は、クライアントに対してより時間がかかるCRLが実行されます。

最新のブラウザに実装されている証明書ステータスチェックの主な問題を理解するには、「中間者」攻撃の次のシナリオを考慮するだけで十分です。



サーバーの秘密キーが侵害されました。 サーバー所有者は、侵害されたキーの証明書を失効させ、新しいキーペアを生成し、新しい証明書を受け取りました。
攻撃者は失効した秘密鍵とサーバー証明書を取得しました。 このシナリオでは、サーバー自体のセキュリティ侵害の結果として、または認証センター（CA）のセキュリティ侵害の結果として、意図的に彼がどのように行ったかを述べていません。 これは、両方の状況でブラウザーがどのように動作するかを示すためです。

侵入者である「中間者」は、クライアントからのすべてのトラフィックを制御します。 このトラフィックを傍受またはブロックでき、他のネットワークサービスに代わってクライアントに応答しようとする場合があります。

サーバーとのTLS接続を確立しようとすると、クライアントのWebブラウザーは「中間者」に接続します。 Man in the Middleは、OCSP応答（別名OCSPステープリング ）が添付されていない失効した証明書を使用するサーバーによって表されます。 攻撃者は、クライアントからすべてのOCSPサーバーおよびCRL配布ポイント（別名CDP ）への要求をブロックします。 また、侵入者は、クライアントがWebブラウザまたはそのコンポーネント（たとえば、後述の「CRLSets」または「OneCRL」ブラックリスト）を更新しようとする試みをブロックします。

すべてのOCSPサーバーおよびCRL配布ポイントへの要求の「中間者」をブロックすることは、最初に攻撃者がサーバーとCAの両方を侵害する可能性がある初期条件をサポートし、次に証明書ステータスチェックを最も完全に実証します。最新のブラウザで実行されます。

以下は、さまざまなWindows Webブラウザによって実行される証明書ステータスチェックの説明です。 他のプラットフォームでは、検査の詳細がわずかに異なる場合があります。

Mozilla Firefox

この攻撃に対するMozilla Firefoxブラウザバージョン54（執筆時点で最も関連性の高い）の動作は、サーバー証明書の種類（DVまたはEV）によって異なります。 DV証明書（ドメイン検証済み）を発行することにより、CAは、証明書で指定されたキーの所有者が証明書で指定されたドメインを制御していることのみを確認します。 ほとんどの証明書はDVです。 EV証明書（拡張検証）は、ドメインの所有権だけでなく、ドメイン所有者の身元も確認します。 このような証明書は、はるかに高価で一般的ではないため、CAによる追加の検証が必要です。

FirefoxによるDV証明書のステータスの確認は、次の図で説明されています。



簡単にするために、図は以前に受信したOCSP応答のキャッシュとの相互作用を示していません。これは、それらが（攻撃によるか、サーバーに十分に長い時間をかけて初めてア​​クセスされるという事実による）か、時代遅れであり、話しているためであると想定しているためです証明書が取り消されていないこと。 2番目の場合、ブラウザの動作は簡単です。接続は許可されます。

そのため、ブラウザーはサーバー証明書のチェーン（中間CAの証明書とサーバー自体の証明書）のステータスをチェックします。 中間CAの証明書の状態を確認するには、クライアントにローカルに保存されているOneCRLブラックリストを使用します。これには、さまざまなCRL配布ポイントから収集された失効した証明書に関する情報が含まれます。 ブラックリストの状態の関連性は、次のように機能する別個のリモートサービスであるCRLアグリゲーターを使用して維持されます。

1.アグリゲーターは、特定のCRL配布ポイントのセットを定期的にポーリングします。
2.受信したCRLから、失効した証明書に関する最も重要な情報（たとえば、秘密キーが侵害されたために失効した証明書）を選択します。
3.この情報に基づいて、ブラウザのブラックリストに更新します。

CRLアグリゲーター、およびその結果、OneCRLブラックリストの内容はMozillaによって制御されます。 OneCRLは、失効したすべての証明書を対象とするのではなく、一部の中間CAの証明書と少数のサーバー証明書のみを対象とします。 これは、ブラックリストのサイズを小さくするために行われます。 「OneCRL」の現在のリストはこちらにあります 。

サーバー証明書のステータスを確認するには、OneCRLから取得した情報、添付されたOCSP応答、またはOCSP要求の結果として受信した応答を使用します。 Firefoxは、中間CAの証明書（ RFC 6961 ）の添付OCSP応答をサポートしていないため、サーバー証明書のみの添付OCSP応答の存在の確認を示しています。

証明書のステータスに関する情報のソースが利用できない場合、証明書は失効したと見なされないことが重要です。 つまり、チェックはソフトフェールモードで実行されます。 したがって、「中間者」攻撃は成功します。 誰のキーが最初に侵害されたか、サーバー自体のキーまたはCAのキーは関係ありません。

さらに、Firefoxに実装されているOCSPプロトコルのクライアント側は、1回限りのランダムコード（nonce）をサポートしていないため、OCSP応答はリプレイ攻撃から保護されていないことに注意してください。

同様の状況は、EV証明書を確認するときに発生します。 唯一の違いは、ブラウザが中間CAの証明書のOCSP要求を追加的に実行することです。



ブラウザーの設定でsecurity.OCSP.requireパラメーターを設定することにより、ブラウザーの動作を変更し、 ハードフェールモードを有効にできます（つまり、証明書ステータス情報が利用できない場合にTLS接続の確立を禁止します）（「about：config」）真実に：



サーバーがDV証明書を提示する場合、この設定は中間CAの証明書に対するOCSPプロトコルの使用をアクティブにしないことに注意してください。

エンドユーザーにとって、Firefoxのハードフェイルは次のようになります。



「中間者」攻撃は依然として可能です！..攻撃者は、OCSP応答を再生するために攻撃を実行し、証明書が取り消される前に生成された「古い」OCSP応答を送信する必要があることに注意してください。 ただし、この攻撃は「古い」OCSP応答が期限切れになるまでしか実行できません。 さらに、OCSP応答の有効期間は非常に長くなる可能性があります。 多くの場合、1週間に相当します。

Microsoft Internet Explorer /エッジ

Microsoft Internet Explorerバージョン11およびMicrosoft Edgeバージョン40ブラウザーは、DVおよびEV証明書に対して同じように動作します。



スキームでは、以前と同様に、簡単にするために、以前に取得したOCSP応答とCRLのキャッシュとの相互作用は示されていませんが、 別の記事をこれに当てることができます。

チェーン内で検証される証明書ごとに、添付されたOCSP応答がない場合、OCSP要求が実行されます。 同時に、Internet ExplorerおよびEdgeは、中間CAの証明書（ RFC 6961 ）に対する添付OCSP応答をサポートせず、OCSP応答をリプレイ攻撃から保護しません。 OCSPサーバーが使用できない場合、CRLのロードが試行されます。

検証はソフトフェイルモードでも実行されます。 したがって、中間者攻撃も成功し、サーバーのキー自体またはCAのキーが最初に侵害されたことが関係ありません。

たとえば、レジ​​ストリキー値「HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe」を1に設定することにより、Internet Explorerの動作を変更することができます。アドレスバーに小さな警告が表示されます。



Edgeの場合、そのような設定は見つかりませんでした。

Google Chrome /クロム

Google ChromeおよびChromiumバージョン59ブラウザーは、DV証明書を検証するときに次のように動作します。



Chromeによって実行されるチェックは、Firefoxによって実行されるチェックと似ていますが、Chromeは一般にDV証明書のチェック時にOCSP要求の実行を拒否しました。 Chromeの「CRLSets」は、Firefoxの「OneCRL」に似ています（厳密には、「CRLSets」メカニズムはさらに以前に登場しました）で、エンドユーザーに対する不完全性と制御不能という同じ問題があります。

EV証明書をチェックする際にOCSPリクエストが使用されます（ここでの画像は、Firefoxで観察したものとほぼ同じになります）



他のブラウザーと同様に、ChromeとChromiumはソフトフェールモードで動作します。 中間CA証明書（ RFC 6961 ）の添付OCSP応答およびリプレイ攻撃からのOCSP応答の保護はサポートされていません。

グループポリシーに変更を加え（ 手順はこちら ）、次のオプションを含めることにより、ChromeとChromiumの動作を変更できます。



Linux でも同等の構成が可能です（ こちら ）。

これらの変更を行った後、ChromeとChromiumはInternet Explorerが行うのと同様のチェックを実行します（OCSP応答が添付されていない場合、証明書チェーン全体のCRLダウンロードへのロールバックでOCSPリクエストの実行を開始します）が、 ハードailモードで。、OCSPサーバーとCRL配布ポイントが利用できない場合、接続は拒否されます。



「中間者」攻撃は依然として可能です。 攻撃者はOCSPをブロックし、CRLリプレイ攻撃を実行して、証明書が取り消される前に生成された「古い」CRLを送信する必要があります。 ただし、この攻撃は、「古い」CRLの有効期限が切れるまで実行できません。 この場合、CRLの有効期間は非常に長くなる可能性があります。 たとえば、www.google.com証明書のCRLは1週間有効です。

その他のブラウザとプラットフォーム

他の一般的なブラウザおよびプラットフォームの場合、状況は同じです。証明書ステータスのチェックはどこでもソフトフェイルモードで実行されるか、まったく実行されません。 詳細はこちらまたはこちらをご覧ください 。

なぜ今すべてがこのように機能しているのですか？

これは、Adam Langleyのブログによく書かれています。 ハードフェイルが存在せず 、クライアント側で明示的にOCSP要求を実行することを拒否するのは、次の要因によるものです。

• CAインフラストラクチャは、単一障害点になります。 OCSPサーバーが使用できないと、インターネットのセグメント全体でサービス拒否が発生する可能性があります。 CAインフラストラクチャはDDoSの新しい目標になりつつあります。
• インフラストラクチャをサポートするためのCAコストの増加。 CAは、より高い帯域幅のチャネルを購入し、DDoSから保護する必要があります。
• 不安定またはノイズの多いネットワーク（モバイルネットワークなど）でのTLS接続の信頼性の低下。
• 転送されるトラフィックの量が増加し、大きな帯域幅が必要になります。これもモバイルクライアントにとって重要です。
• OCSPとキャプティブポータルを併用する際の問題。 通常、パスワードはTLSを介して転送されますが、OCSPサーバーからの応答が受信されるまで、TLS接続を確立して認証することはできません。 OCSPサーバー（少なくとも中間CAの証明書用）は通常インターネット上にあり、この段階ではアクセスできないため、OCSP要求を送信することはできません。 この問題は添付OCSP応答の助けを借りて解決できますが、中間CAの証明書の添付OCSP応答（ RFC 6961 ）をサポートするブラウザはないため、現時点で中間証明書のステータスを確認するにはOCSP要求を送信する必要があります。

同時に、クライアント側で明示的にOCSPリクエストを実行することに対する完全な拒否は発生しません。クライアントから「遠く」サーバーに「近い」場合、つまり「中間者」から保護できるためです。 TLSトラフィックへのアクセス、ただしOCSPをブロックすることはできません：

見込みは何ですか？

前に述べたすべてのことから明らかな結論：ブラウザーでの証明書の状態チェックは機能せず、これはニュースではありません。 同時に、客観的な理由により、 ハードフェイルに切り替えてハードフェイルに切り替えることは不可能です。

この問題の実用的な解決策はありますか？ この問題に対して既に提案されている多くの部分的なソリューション（特に、TLS機能証明書、短期証明書、CRLアグリゲーターなどの拡張について詳細に説明します）を分析し、まとめた後、どのように考えているのかを説明します証明書のステータスの検証は実際に行われるべきです。

すべてのサービスが証明書ステータスのオンライン検証を必要とするわけではないという主張に基づいています。 ほとんどのサービスでは、 ハードフェールモードでの証明書ステータスの厳密なオンラインチェックの提供に関連するオーバーヘッドは、失効した証明書を使用した中間者攻撃に関連するリスクをカバーしません。 つまり、証明書のステータスを確認するという観点から、サービスは2つのタイプに分けられます。

1. ハードフェールモードでの証明書の厳格なオンラインステータスチェックが行われる少数派。
2.オンライン証明書ステータスチェックがまったく実行されない大部分（他の保護対策が講じられます）。

ブラウザは、サーバー証明書に特別な拡張子が存在することで、そのようなサービスを区別できます。 サービスの種類に応じて、クライアントは「偏執的な」証明書ステータスチェックを実行するか、まったく実行しません。 次に、これら2つのスキームのそれぞれについて詳しく説明します。

妄想的少数者証明書のステータス検証スキーム

2015年、 「TLS機能」と呼ばれる新しいX.509証明書拡張機能の仕様が発表されました（標準開発の初期段階では「OCSPが必要」と呼ばれることもあります ）。 この証明書拡張機能を使用すると、この証明書を提示するTLSサーバーがサポートするために引き受けるTLSプロトコルオプションを証明書に記録できます。 添付されたOCSP応答は、特定のTLSプロトコルオプションです。 この拡張子を持つ証明書の例を以下に図式的に示します。



証明書には、拡張子「TLS機能」（赤で強調表示）が含まれています。これは、TLSサーバーがRFC 6066で指定された添付OCSP応答（「ステータス要求（バージョン1）」）およびこのオプションの新しいバージョン（ 「ステータスリクエスト（バージョン2）」）、 RFC 6961-複数の添付OCSPレスポンスで指定されています 。 TLSプロトコルのこのオプションの新しいバージョンでは、中間CA証明書のOCSP応答を添付できます。

たとえば、「Status Request（Version 1）」オプションをサポートするクライアントを接続するときに、後者が「ClientHello」メッセージでハンドシェイクプロトコルを通知する場合、サーバー「www.example.com」は上図に示す証明書とともに送信されませんでした添付されたOCSP応答がバージョン1の場合、TLS接続のセットアップはエラーで失敗します。 したがって、この種の失効した証明書を使用する「中間者」は、添付されたOCSP応答を破棄できず、この証明書が失効したことを示します。

TLS機能拡張で証明書を使用することに加えて、証明書のステータスをチェックするための「偏執的な」スキームを構築しているため、次の点にも注意する必要があります。

1.添付されたOCSP応答は、リプレイ攻撃から保護する必要があります（ランダムなワンタイムコードを使用する必要があります）。 この拡張機能で証明書を使用する場合でも、攻撃者はOCSP応答の有効性によって決定される攻撃のウィンドウをまだ持っています：証明書が取り消される前に受信したリプレイ攻撃を実行し、クライアントに古いOCSP応答を送信することは依然として可能です。
2. 「ステータスリクエスト（バージョン2）」オプションを使用する必要があります。 このオプションを使用すると、サーバー証明書だけでなく、チェーン内のすべての証明書にOCSP応答を添付できます。 これにより、クライアント側でのOCSPリクエストの明示的な実行と、その固有の前述のすべての欠点を完全に放棄できます。

そのため、最終的には、「偏執病」の証明書ステータス検証スキームは以下に基づいています。

• TLSサーバーは、「TLS機能」拡張機能付きの証明書を使用します。これにより、サーバーはTLSプロトコルオプション「ステータス要求（バージョン1）」および「ステータス要求（バージョン2）」をサポートする必要があります。
• TLSクライアントとTLSサーバーは、リプレイ攻撃からのランダムなワンタイムコードによって保護されている添付OCSP応答を使用する必要があります。
• TLSクライアントが「ステータスリクエスト（バージョン1）」オプションをサポートしているが、「ステータスリクエスト（バージョン2）」オプションをサポートしていない場合、サーバーから「TLS機能」拡張付きの証明書を受信すると、OCSPリクエストを明示的に実行する必要があります（使用ランダムワンタイムコード） ハードフェールモードの中間CAの証明書。

これにより、前述のように、この検証スキームには次の欠点があります。

• CAのOCSPサーバーの負荷の増加。
• CAサーバーに対するDDoS攻撃に対する脆弱性。

最初の問題の解決策は、 セッションIDまたはセッションチケットメカニズムを使用したTLS接続の再開です。 これらのメカニズムは、考慮された中間者攻撃から保護されており、証明書を送信することなく、したがってCAのOCSPサーバーへの要求を実行することなく、以前に確立されたTLS接続を再開できます。 このアプローチを使用すると、OCSPサーバーの負荷が軽減されますが、クライアントとサーバー（またはクライアントのみ）で接続を再開するために必要な追加情報を保存するコストがかかります。

サーバー上の2番目の問題の解決策として、独立したCAによって発行された複数の証明書を交互に使用できます。 この場合、1つのCAのOCSPサーバーはDDoSのために「横たわっています」が、TLSサーバーは攻撃を受けていない別のCAによって発行された代替証明書を使用します。 複数の証明書を使用すると、CA間の負荷を分散することもできます。

クライアント側（Windowsの場合）が明るい未来への移行にどのように準備しているかを評価するには、次の表をご覧ください。

ほとんどの回路

前述のように、ほとんどのサービスでは、 ハードフェールモードでの証明書ステータスの厳密なオンラインチェックの提供に関連するオーバーヘッドは、失効した証明書を使用する中間攻撃者に関連するリスクをカバーしません。 この場合、この攻撃に対して防御するのではなく、この攻撃が可能な期間を最小限に抑えることをお勧めします。 このために、有効期間が短い（1〜2日など）証明書が使用されます。

したがって、ほとんどのサービスは、TLS機能拡張なしで証明書を使用しますが、有効期間は短くなります。 このような証明書の場合、オンライン証明書ステータスチェックはまったく実行されません。 代わりに、急速に古くなる証明書が頻繁に更新されます。

短命証明書の使用は、「TLS機能」拡張機能を備えた証明書の使用と同等であり、リプレイ攻撃から保護されていない添付OCSP応答（つまり、キャッシュされたOCSP応答） TLSサーバー側）。 同時に、有効期間が短い証明書は、トラフィックの節約と証明書の検証に必要な操作の数の点で、わずかに効果的です。

有効期間が短い証明書を使用する方法には多くの利点がありますが、CA証明書には適していません。 このような証明書のステータスを確認するには、「CRLSets」や「OneCRL」に似た定期的に更新されるブラックリストを使用できますが、CRLアグリゲーターをより詳細に制御できます。 たとえば、ユーザーは、ポーリングされた新しいCRL配布ポイントを追加できる必要があります。 一部の組織は内部使用のために独自の非公開CAを展開しているため、これは重要です。 解決策は、プライベートCRLアグリゲーターを使用することです。 この場合、クライアントとCRLアグリゲーターの相互作用のためのオープンプロトコルを開発する必要があります。これにより、さまざまなベンダーのクライアントとアグリゲーターの互換性が保証されます。

まとめ

さて、これまでのところ、すべてが非常に良いというわけではありません。最新のブラウザーでの証明書のステータスチェックは実際には機能しません。

しかし、トンネルの終わりにはまだ光があり、状況は徐々にではありますが、徐々に良くなっています。