証明書の失効が機能しない

現在、私たちには小さな問題がありますが、私の意見では、時間の経過とともに状況は悪化するだけです。 ますます多くのサイトが証明書（HTTPSを実装するために必要なドキュメント）を受信して​​いますが、不正使用から保護するメカニズムはありません。

認証

ますます多くのサイトがHTTPSを採用しているため、証明書をめぐる真のゴールドラッシュが発生しています。 セキュリティとプライバシーの明らかな利点に加えて、安全な接続を実装することには他の利点があります。これについては、「 HTTPSは必要ないと思いますか？ 「。 一般に「SSL証明書」または「HTTPS証明書」と呼ばれることは、インターネットの歴史で見たことのない速度で飛散します。 毎日、トラフィックの最初の100万からサイトを調査し、それらのセキュリティのさまざまな側面を分析し、6か月ごとにレポートを発行しています。 これらのレポートはここで調べることができますが、今のところはHTTPS実装のペースを見てみましょう。





Alexaの統計によると、HTTPSバージョンへのリダイレクトがある最初の100万の最も人気のあるサイトからのサイトの割合



HTTPSの実装を継続しているだけでなく、実装の速度も向上しています。 本当に進歩しているようです。 優れたLet's Encryptのおかげで、時間の経過とともに証明書を取得するプロセスがより簡単になります。さらに、証明書が無料になりました。 つまり、証明書署名要求（CSR）を証明機関（CA）に送信するだけで、彼はドメインの所有権の証明を申し出ます。 これは通常、DNS TXTレコードを変更するか、ドメインのランダムなURLのどこかにカスタムコードを配置することによって行われます。 タスクが完了すると、CAは証明書を発行し、ブラウザーに提示して、アドレスバーに緑色のロックとHTTPSを表示できます。







開始場所 、 正しくアップグレードする方法、 二重証明書の使用方法など、このプロセスに関するいくつかの指示を書きました。 それはすべて素晴らしいですね。 しかし、問題は何ですか？ そして、すべてが計画通りに進み、あなたが悪い日を過ごしたときに問題が発生します。

ハッキングされた

誰もこれらの言葉を聞きたくありませんが、現実は、私たちが望むよりも頻繁にそれらを聞かなければならないということです。 ハッカーはサーバーにアクセスできれば何でも入手でき、多くの場合、秘密鍵が必要です。 HTTPS証明書は、サイトのすべての訪問者に送信する公開ドキュメントですが、他の人が同じ証明書を使用できないようにする唯一のことは、秘密キーの欠如です。 ブラウザがサイトへの安全な接続を確立すると、使用されている証明書の秘密鍵がサーバーにあることを確認します。 だから誰も私たちの証明書を使用できません。 ハッカーが秘密鍵を受け取ると、状況は変わります。







攻撃者が秘密鍵を所有している場合、攻撃者は私たちになりすますことができます。 これを繰り返しましょう。インターネット上の誰かが自分があなたであることを証明できますが、実際にはそうではありません。 これは本当の問題であり、あなたが考える前に、「これは私には決して起こりません」とHeartbleedを思い出してください。 OpenSSLライブラリのこの小さなバグにより、すべてのセキュリティ対策を講じた場合でも、攻撃者は秘密鍵を盗むことができました。 また、偶然または過失により秘密鍵が漏洩したケースは無数にあります。 現実には、秘密キーを紛失する可能性があり、これが発生した場合、攻撃者が証明書を使用できないようにする方法が必要です。 彼を思い出す必要があります。

フィードバック

侵害された場合、悪用の可能性を排除するために証明書を失効させる必要があります。 証明書が失効としてマークされると、ブラウザは、期限が切れていなくても信頼できないことを認識します。 所有者がレビューを要求したため、クライアントはこの証明書を受け入れてはなりません。







ハッキングの事実を知るとすぐに、CAに連絡し、証明書の取り消しを依頼します。 証明書を所有していることを証明する必要があります。これを行うとすぐに、CAは証明書を失効としてマークします。 次に、この情報を必要とするすべてのクライアントにこの事実を伝える方法が必要です。 現時点では、ブラウザはもちろん何も知りません。これは問題です。 情報の配布に使用される2つのメカニズムがあります。証明書失効リスト（CRL）とオンライン証明書ステータスプロトコル（OCSP）です。

証明書失効リスト

CRLは実際には非常に単純な概念であり、CAが失効とマークしたすべての証明書のリストにすぎません。 クライアントは、CRLサーバーに要求を送信し、リストのコピーをダウンロードできます。 このリストのコピーがあると、ブラウザは提示された証明書をチェックします。 存在する場合、ブラウザは証明書が無効であり、信頼できないことを認識し、エラーをスローして切断します。 証明書がリストにない場合、すべてが正常であり、ブラウザは引き続き動作します。







CRLの問題は、リストに特定の証明機関からの多くの証明書が含まれていることです。 あまり詳細に説明しなくても、それらは中間CA証明書に分割され、証明機関は小さな部分でリストを発行できますが、問題は同じままです。 CRLにはかなりのサイズがあります。 別の問題は、クライアントがCRLの新しいコピーを持っていないため、サイトへの最初の接続でそれを要求する必要があるため、手順全体が著しく遅くなる可能性があることです。 すべてが見栄えがよくないので、OCSPを見てみましょう。

証明書ステータス検証プロトコル

OCSPは、この問題に対するはるかに美しいソリューションを提供し、CRLに比べて大きな利点があります。 ここでは、CAに単一の特定の証明書のステータスを要求します。 これは、CAが単純な回答のみを返す必要があることを意味します。証明書は有効または無効であり、そのような応答はCRLリストよりもはるかに小さくなります。 いいね！







確かに、OCSPは応答の受信速度においてCRLよりも優れていますが、この利点を支払う必要があります（これが発生した場合も嫌いですか？）。 価格は非常に高い-それはあなたのプライバシーです... OCSPリクエストの本質を考えると、これは単一のHTTPS証明書に対する非常に具体的なリクエストです。 実際、情報の漏洩があります。 OCSPリクエストを送信するとき、文字通り証明機関に尋ねます：

pornhub.comの証明書は有効ですか？

したがって、これは理想的なシナリオではありません。 これで、訪問したサイトの履歴を、あなたが何も知らないサードパーティに、そしてすべてHTTPSのために提供します。これにより、プライバシーとセキュリティが向上します。 しかし、ちょっと、何か他のものがあります。

完全な失敗

上記では、2つのブラウザー証明書検証メカニズムであるCRLとOCSPについて説明しましたが、これらは次のようになります。







証明書を受け取った後、ブラウザはこれらのサービスの1つに連絡し、証明書のステータスを最終的に判断する要求を送信します。 しかし、CAの調子が悪く、インフラストラクチャがオフラインの場合はどうでしょうか。 状況がこのようになったらどうなりますか？







ここでは、ブラウザには2つのオプションしかありません。 証明書のステータスを確認できないため、証明書の受け入れを拒否する場合があります。 または、リスクを取り、証明書が取り消されているかどうかに関係なく、そのステータスを知らずに証明書を受け入れます。 どちらのオプションにも長所と短所があります。 ブラウザが証明書の受け入れを拒否すると、CAインフラストラクチャがオフラインになるたびに、サイトもそこに移動します。 ブラウザが引き続き証明書を受け入れる場合、盗まれた証明書を受け入れる危険があり、ユーザーを危険にさらします。 これは難しい選択ですが、今、今日、実際には何も起こりません...

部分的な故障

実際、今日のブラウザは、部分的な失敗で、いわゆる証明書失効チェックを実行します。 つまり、ブラウザは証明書のステータスをチェックしようとしますが、答えがまったくなかった場合、または短時間で返されなかった場合、ブラウザはそのことを忘れます。 さらに悪いことに、Chromeは証明書を検証しようとさえしません。 はい、あなたはそれを正しく読みました。Chromeは受け取った証明書のステータスをチェックしようとさえしません 。 これは奇妙に思えるかもしれませんが、私は彼らのアプローチに完全に同意し、Firefoxも間もなく動作を開始する可能性が高いことを報告できることを嬉しく思います。 説明させてください。 完全な障害の問題は明らかです。CAに悪い日があれば、我々もそれを抱えることになります。それが、部分的な障害の論理に到達した方法です。 ブラウザは、証明書の失効を確認しようとしますが、時間がかかりすぎる場合、またはCAがオフラインになったと思われる場合は、完全に拒否します。 待って、最後の言葉は何でしたか？ 「CAがオフラインになったと思われる場合」、失効の証明書チェックはキャンセルされます。 攻撃者がそのような状態をシミュレートできるのだろうか？







MiTM攻撃を実行している場合、証明書検証要求をブロックし、CAが機能していないという印象を作成するだけです。 ブラウザは部分的な検証エラーに遭遇し、失効した証明書を引き続き使用します。 誰もあなたを攻撃していない場合、この特定の証明書を確認するたびに、証明書が取り消されていないことを確認するために時間とリソースを費やします。 そして一度、あなたが攻撃されたとき-あなたが本当にそのようなチェックが本当に必要なのは-だけです-攻撃者は単に接続をブロックし、ブラウザは部分的な失敗を経験します。 Googleのアダムラングレーは、証明書の失効とはどのようなものであるかを最もよく説明しています。これは、事故時に破損するシートベルトであり、彼は正しいです。 毎日あなたは車に乗ってシートベルトを締めます-そしてそれはあなたに安全で快適で快適な感覚を与えます。 そして、ある日何かがおかしくなります-あなたは事故に遭い、ここでフロントガラスに飛び出します。 本当に必要なときだけ、シートベルトがあなたを失望させます。

問題を修正する

今、この特定の瞬間に、現実は私たちが状況を修正できないということです。 ただし、何かを行うことができ、将来、証明書失効メカニズムは本当に信頼できるものになるでしょう。

独自のメカニズム

サイトが危険にさらされ、攻撃者が秘密鍵を受け取った場合、このサイトを偽造して何らかの損害を引き起こす可能性があります。 ここでは何も良いことではありませんが、もっと悪いこともあったでしょう。 CAが侵害され、攻撃者が中間証明書の秘密鍵を取得した場合はどうなりますか？ 攻撃者は自分の証明書に署名することで、文字通り自分が望むあらゆるサイトを偽造できるため、これは災害となります。 したがって、ChromeとFirefoxには、失効の中間証明書をオンラインでチェックする代わりに、同じタスクのための独自のメカニズムがあります。







Chromeでは、 CRLsetsと呼ばれ、FirefoxではOneCRLと呼ばれます 。 これらのメカニズムは、利用可能なCRLを組み合わせてそこから証明書を選択することにより、証明書失効リストをチェックします。 中間証明書のような特に価値のある証明書がチェックされますが、通常の証明書はどうですか？

OCSPマストステープル

OCSP Must-Stapleとは何かを説明するには、まずOCSP Staplingとは何かを簡単に理解する必要があります。 ここではあまり詳しくしませんが、 OCSP Staplingブログから包括的な情報を入手できますが、ここがポイントです。 OCSP Staplingでは、証明書自体とともにOCSP応答を発行することにより、ブラウザーがOCSP要求を送信する必要がなくなります。 これは、サーバーがOCSP応答を証明書で「ステープル」し、それらを一緒に発行する必要があるため、OCSP Staplingと呼ばれます。







一見、これは少し奇妙に思えます。なぜなら、サーバーは自身の証明書を未検証として「認証」しているように見えますが、すべてが正常に機能しているからです。 OCSP応答は短期間のみ有効であり、証明書と同じ方法でCAによって署名されます。 したがって、ブラウザが証明書がCAによって署名されていることを確認できる場合、OCSP応答もCAによって署名されていることを確認できます。 これにより、大きなプライバシーの問題が解消され、クライアントは外部リクエストを実行する負担から解放されます。 最良のオプション！ しかし、本当に最高ではありません、ごめんなさい。 OCSP Staplingは素晴らしいことであり、私たち全員がこの技術をサイトでサポートする必要がありますが、攻撃者がそれをサポートすると本当に考えていますか？ いいえ、私はそうは思いません、もちろん彼はそれをしないでしょう。 本当に必要なのは、サーバーがOCSPステープルをサポートするようにすることであり、それがOCSP Must-Stapleの目的です。 CAに証明書を要求するとき、OCSP Must-Stapleフラグを設定するように彼に依頼します。 このフラグは、証明書が OCSP応答とともに配信されるか、拒否されることをブラウザに通知します。 フラグの設定は簡単です。







このフラグを設定した後、OCSP Stapleが使用されていることを確認する必要があります。使用されていない場合、ブラウザーは証明書を拒否します。 侵害が発生した場合、攻撃者がキーを受け取った場合、OCSP Stapleを証明書と一緒に使用する必要があり、OCSP Stapleを有効にしない場合、OCSP応答は証明書が取り消されたとブラウザが受け入れないことを通知します。 多田！

OCSP Expect-Staple

Must-Stapleは、証明書の失効を検証するための優れたソリューションのように見えますが、これは完全に真実ではありません。 私の意見では、最大の問題の1つは、サイト運営者として、OCSP Stapleタグの信頼性とクライアントがそれらを受け入れる方法を正確に知ることができないということです。 OCSP Must-Stapleが有効になっていない場合、これは問題ではありませんが、OCSP Must-Stapleを有効にし、OCSP Stapleが信頼できるか正しいかどうか不明な場合、これはサイトの問題です。 OCSP Stapleラベルの品質に関するフィードバックを取得するには、OCSP Expect-Stapleという関数をアクティブにします。 以前にそれについて書きましたが、 OCSP Expect-Stapleブログで詳細を確認できますが、ここでも簡単に説明します。 HSTSプリロードリストに加えて、OCSP Stapleラベルに満足している場合は、ブラウザーにレポートを送信するように求めています。 自分でレポートを収集するか、 report-uri.ioサービスを使用できます。どちらの場合も、サイトでOCSP Must-Stapleで問題が発生した正確なタイミングを知ることができます。 HSTSプリロードリストを使用することは私が望むほど明白ではないため、 Expect-Stapleと呼ばれる新しいセキュリティヘッダーを定義するための仕様も作成しました。 これは、Must-Stapleがアクティブになる前であっても、このヘッダーを設定して、非常に必要なレポートを送信する機能を有効にできるようになったという考えです。 他のすべてのセキュリティヘッダーと同様に、ヘッダーの設定は簡単です。

Expect-Staple: max-age=31536000; report-uri="https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

偽の証明書

証明書の失効について話している場合、改ざんのトピックを考慮する必要があります。 誰かがCAを侵害しようとしている場合、または何らかの方法で資格のない証明書を取得しようとしている場合、どのように行動しますか？ 今すぐCAをハッキングしてサイトの証明書を取得した場合、ニュースで報告するまでそのことはわかりません。 あなたの会社には、内部手続きを迂回する証明書を受け取るインサイダーさえいるかもしれません。 絶対的な透明性が必要です。すぐに入手できます。 これが証明書の透明性です。

証明書の透明性

CTは、来年の初めに必須となる新しい要件です。 ブラウザがそれらを信頼できるように、すべての証明書を公開ジャーナルに記録する必要があると規定されています。 CTの詳細な説明が記載された記事を読むことができますが、肝心な点は、CAが発行したすべての証明書をCTログに記録することです。







これらの雑誌は完全に公開されており、誰でも見ることができるので、誰かがあなたのサイトの証明書を受け取った場合、あなたはそれについて知るでしょう。 たとえば、 ここでは、私のドメインに発行されたすべての証明書を確認し、自分の証明書を検索できます。 同じ目的でsslmateのCertSpotterサービスもあります。また、特定のドメインの証明書が発行されるたびにメールを送信するFacebook証明書透明性監視ツールを使用しています。 CT規格は素晴らしいアイデアであり、義務化するのが待ちきれませんが、注意点が1つあります。 実際、CTは最初の一歩にすぎません。 これらの証明書について知っておくのは良いことですが、失効に関して言及されているすべての問題がまだ残っています。 ただし、一度に解決できる問題は1つだけです。世界で最高の失効メカニズムでさえ、失効させる必要がある証明書がわからなければ効果がありません。 CTは少なくともこの情報を提供してくれます。

証明機関の承認

証明書の発行を防ぐことは、証明書を取り消すよりもはるかに簡単です。そのため、CAA 承認が必要です。 繰り返しになりますが、詳細は参照により記事に記載されていますが、要するに、本質は、特定の証明機関にのみ証明書を発行する権限を与えることができるということです。 承認は、DNSレコードを作成するのと同じくらい簡単です。



scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"







CA承認は特に強力なメカニズムではなく、証明書の誤った発行のすべての状況で役立つわけではありませんが、場合によっては役立つので、CAAレコードを作成して設定を宣言する必要があります。

おわりに

誰かが秘密鍵を受け取った場合、証明書を取り消すことができないという現実の問題があります。 ハートブリードスケールの次のグローバルな脆弱性が明らかになることを想像してみてください！ できることの1つは、証明書の有効期間を短縮することにより、漏洩による損害の量を制限することです。 3年ではなく、1年以下を示します。 暗号化は、90日間のみ有効な証明書のみを発行します！ 証明書の有効期間を短縮することにより、攻撃者は悪用される時間が少なくなります。 また、ほとんど何もできません。



問題と実際の問題を示すために、サイトで開いた新しいサブドメインrevoked.scotthelme.co.ukにアクセスしてみてください。 おそらくご想像のとおり、失効した証明書はこのサブドメインに添付されており、通常はブラウザに読み込まれます。 そうでない場合、ブラウザに期限切れの警告が表示される場合、それはブラウザが引き続きOCSPリクエストを送信し、あなたが自分のサイトにアクセスしたことをCAに通知したことを意味します。 このようなソフトフェイルチェックが役に立たないことをocsp.int-x3.letsencrypt.org



するには、IPアドレス127.0.0.1



ocsp.int-x3.letsencrypt.org



をhosts



追加するか、他の方法でブロックして、再接続を試みます。 今回は、失効した証明書のチェックが機能しないため、ページは正常にロードされ、ブラウザはページのロードを続行します。 そのようなチェックの感覚...



証明書を取り消す手順を修正する必要があるという質問で記事を終了したいと思います。 ただし、これは別の記事のトピックです。