Loading article…
公開鍵暗号では、証明書は有効期限が切れる前に失効される可能性があり、これは証明書が有効でなくなったことを示します。失効が行われないと、攻撃者は有効期限が切れるまで、侵害された証明書や誤って発行された証明書を悪用する可能性があります。したがって、失効は公開鍵インフラストラクチャの重要な部分です。失効は発行証明機関によって実行され、発行証明機関は暗号的に認証された失効ステートメントを作成します。
失効情報をクライアントに配布する場合、失効の発見の適時性 (したがって、攻撃者が侵害された証明書を悪用する機会) と、失効ステータスの照会におけるリソースの使用およびプライバシーの懸念との間でトレードオフが生じます。失効情報が利用できない場合 (事故または攻撃のいずれかが原因)、クライアントは、フェイルハードにして証明書が失効しているものとして扱う (したがって可用性が低下する) か、フェイルソフトにして証明書が失効していないものとして扱う (したがって、攻撃者が失効を回避できるようにする) かを決定する必要があります。
失効チェックのコストと、信頼性の低い可能性のあるリモート サービスによる可用性への影響のため、Web ブラウザーは実行する失効チェックを制限し、実行する場合にはソフトにフェイルします。証明書失効リストは日常的に使用するには帯域幅のコストがかかりすぎ、オンライン証明書ステータス プロトコルは接続の遅延とプライバシーの問題を引き起こします。フェイルハード チェックを可能にする他のスキームも提案されていますが、まだうまく展開されていません。
頭字語の用語集
- アクメ
- 自動証明書管理環境
- カナダ
- 証明機関
- タクシー
- CA/ブラウザフォーラム
- CRL
- 証明書失効リスト
- CR-V
- 証明書失効ベクトル
- OCSP
- オンライン証明書ステータスプロトコル
- PKI の
- 公開鍵インフラストラクチャ
- TLS
- トランスポート層セキュリティ
歴史
2014年に公開されたハートブリード脆弱性により、証明書の秘密鍵が漏洩した可能性があるため、大量の証明書失効が引き起こされました。GlobalSignは発行した証明書の50%以上を失効させました。StartComは無料の証明書を発行しながら、失効に料金を課したことで批判されました。[1]
2015年の調査では、Webで使用される証明書の全体的な失効率は8%であることがわかりましたが、[2]これはHeartbleedの影響で上昇した可能性があります。[3]
ウェブセキュリティはほとんどのブラウザにとって優先事項であるにもかかわらず、OCSPとCRLに関連する遅延と帯域幅の要件のため、ブラウザは証明書ステータスのチェックに制限を設けています。[4] 2015年には、Google ChromeはExtended Validation証明書のみをアクティブにチェックし、有効性チェックを実行したモバイルブラウザはなく、すべての証明書を完全にチェックしたブラウザはありませんでした。[5] ChromeとFirefoxは、重要と見なされる少数のドメインに対してプッシュベースのチェックを実行します。[6]ブラウザは、証明書の有効性に関するコーナーケースではほとんど一致せず、経験豊富なユーザーでさえ混乱する可能性があります。[7]
Web PKIの証明書の数は2010年代後半に大幅に増加し、2017年1月の3,000万から2020年1月の4億3,400万にまで増加しました。この増加の大きな要因は、Let's Encryptがドメイン検証済みの証明書を無料で提供していることです。取り消し可能な証明書セットのサイズが大きいため、取り消しメカニズムのスケーラビリティが求められます。[4]
Chuat et al. (2020) は、失効を「悪名高いほど難しい」と呼んでいます。[8] 2022年、RFC 9325は、証明書の失効を「完全かつ効率的な解決策がない」重要な問題として特徴づけました。OCSPとOCSPステープリングは、「可能な解決策の基盤」として推奨されています。[9]
必要性
証明書の失効は、攻撃や偶発的な侵害に対処するための「重要なツール」です。RFC 9325 では、TLS 実装に証明書を信頼しない手段を備えることを規範的に要求しています。[9]失効がなければ、攻撃者は侵害された証明書を使用して、有効期限が切れるまで所有者になりすますことができます。[4]
有効期間が十分短い証明書（数時間から数日程度、OCSPレスポンスの有効期間と同程度）の場合、失効は不要である可能性がある。関連する頻繁な証明書発行には通常、自動化（ACMEプロトコルなど）が必要であり、他のインフラストラクチャ要素（透明性ログなど）に負荷をかける可能性がある。[10]有効期間が短い証明書は、必ずしも克服できないわけではないが、TLS接続の再開に複雑な問題を引き起こすこともある。 [11]
手順
失効は、証明書保有者（例えば、秘密鍵が侵害されたことを知っている）がCAに通知することで開始される可能性があります。CAは、証明書が失効したことを示す暗号認証された証明書を作成し、配布します。[12] CA/Bの要件では、CAが侵害の可能性を認識した場合、CAが自主的に証明書を失効させることも許可されています。[13]誰でもそのような証拠を提出できます。[14]
失効ステータスは、通常、証明書の有効期限を過ぎても長期間保存およびアーカイブされないため、失効動作の調査と監査が困難になります。[15]この問題を解決するための 1 つの提案は、失効ごとに「ポスト証明書」を証明書の透明性ログに送信することです。これにより、CA によるアクションなしでも失効を実行できるようになります。[16]また、証明書の透明性に基づいた別の提案では、CA によって CRV が CT ログに送信されます。[17]
クライアントへの通知
考慮事項
失敗モデル
失効ステータスが利用できない場合（無害な場合もあれば、攻撃による場合もあります）、クライアントは証明書を評価する際にジレンマに直面します。フェイルソフトで証明書がまだ有効であると想定するか、フェイルハードで証明書が失効していると想定するかのどちらかです。これはセキュリティと可用性のトレードオフです。フェイルソフトではダウングレード攻撃が可能になり、フェイルハードではサービス拒否（攻撃による）が可能になるか、利用不可になります。[18]
侵害された証明書を提示できる攻撃者は、クライアントがオンラインで失効ステータスチェックを実行するのを阻止する能力も持っている可能性があります。この場合、フェイルソフトは事実上まったく保護を提供しません。ブラウザはジレンマのこの側面を選択し、セキュリティよりも可用性を優先しました。[19]
フェイルハードは、新たなサービス拒否攻撃ベクトルを生み出す可能性があります。たとえば、クライアントがOCSPステープリングを期待し、そうでない場合はフェイルハードを使用すると、OCSPレスポンダに対するサービス拒否は、それらのOCSPレスポンスを使用するすべてのサービスに対するサービス拒否に増幅されます。[10]
リソースの使用
リソース使用状況の評価には、通常の状況と大量失効イベントの2つのシナリオがあります。失効スキームは、通常の状況では効率的であり、大量失効イベント中に機能する必要があります。[4]
失効情報を取得すると、クライアントの帯域幅と遅延コストが発生します。[20]
2014年のHeartbleed大量失効イベントでは失効率が1%から11%に上昇しましたが、Cloudflareは、 GlobalSignがCRLを配布するために使用した帯域幅のコストが40万ドル（2023年には51万ドルに相当[21] ）になった可能性があると推定しました。[22]
適時性
失効ステータスがチェックごとに新しく取得されない場合（キャッシュや定期的な取得など）、証明書が失効してからすべてのクライアントが失効を認識するまでの間に遅延が発生します。これにより、遅延、効率、セキュリティの間でトレードオフが発生します。キャッシュ時間が長くなったり、更新頻度が低くなったりすると、使用するリソースが少なくなり、遅延が短縮されますが、侵害された証明書がより長期間悪用される可能性があります。[23]
プライバシー
プルベースのチェックを実行するクライアントは、ユーザーの閲覧情報を第三者、つまり失効情報の配布者に漏らす可能性があります。[24]
監査可能性
PKIに信頼できる第三者を作成することは避けることが望ましい。スキーム内のアクターが監査可能であれば、クライアント（またはクライアントに代わって行動するエージェント）は、アクターが正しく動作していることを証明できる。[25]
展開可能性
CA に重い負担をかける失効ステータスの配布は、特に CA が実装から相殺利益を引き出せない場合は、成功しない可能性があります。また、変更を加える必要がある関係者の数を減らすことで、導入も容易になります。関係する可能性のある関係者には、CA、クライアント、サーバー管理者、サーバー ソフトウェア プロデューサーが含まれます。前方互換性は諸刃の剣です。古いクライアントとサーバーは新しいスキームによって混乱することはありませんが、ユーザーは失効のメリットを失っていることに気付かない可能性があります。[26]
アーキテクチャ
クライアントが失効ステータスにアクセスする方法には、大きく分けて3つのアーキテクチャがあります。プルベースではクライアントが検証時に失効ステータスを取得します。プッシュベースではクライアントが検証前に失効ステータスを取得してキャッシュします。ネットワークアシストでは失効チェックがTLSプロトコルと緊密に統合されており、個別のチェックは不要になる場合があります。[27]
プルベースのチェックには通常、レイテンシと可用性の問題があります。プルベースのチェックを実行するクライアントは通常、応答を短期間キャッシュします。純粋なプルベースのチェックとフェイルソフトを組み合わせても、セキュリティは向上しません。[28]
プッシュベースのチェックはプルベースのチェックよりも帯域幅効率は劣りますが、可用性とプライバシーが向上します。証明書ごとに異なる方法を使用することができ、トレードオフを微調整できます。Google ChromeとMozilla Firefoxはどちらも、少数の重要な証明書に対してプッシュベースのチェックを実行します。[28]
証明書失効リスト
証明書失効リスト（CRL）は失効した証明書を列挙する。それらは発行CAによって暗号的に認証される。[29]
CRLにはスケーラビリティの問題があり、証明書のステータスを確認する前にクライアントがCRLをダウンロードできるだけのネットワークアクセスを持っていることが必要です。[9]
CRLには、CAによって取り消されたすべての証明書に関する情報が含まれているため、配布者とクライアントは、おそらく無関係な情報の転送コストを負担する必要があります。[30] 2015年の調査では、証明書のCRLの中央値は51kBで、最大のCRLは76MBであることがわかりました。[2]
OCSP
オンライン証明書ステータスプロトコル（OCSP）を使用すると、クライアントは証明書のステータスについてサーバー（OCSPレスポンダー）に対話的に問い合わせ、発行CAによって暗号的に認証された応答を受け取ることができます。 [29]これはCRLの問題に対処するために設計されました。[30]一般的なOCSP応答は1kB未満です。[31]
OCSP にはスケーラビリティの問題があります。証明書の失効ステータスをチェックする時点でクライアントがネットワークにアクセスできる必要があります。さらに、OCSP レスポンダがアクセス可能で、使用可能な応答を生成する必要があります。そうでないとチェックが失敗し、クライアントは failing-soft と failing-hard のいずれかを選択する必要があります。多くの証明機関は中間証明書に対して有用な OCSP 応答を公開していません。[9]
レスポンダへのリクエストはユーザーのブラウジングに応じて行われるため、OCSPレスポンダはユーザーのブラウジングについて知ることができ、これはプライバシーの問題です。また、新しい接続を使用する前にレスポンダに問い合わせる必要があるため、接続に遅延が発生します。 [18]
2018年の調査では、レスポンダーへのリクエストの1.7%がネットワークレベルで利用できず、さらに約2%が使用できないOCSP応答を生成し、CAとクライアントの視点間で大きな異質性があることが判明しました。[32]
OCSP ステープル
OCSPステープルは、接続開始時に証明書とともにOCSP応答がクライアントに提供されることを提供するTLS拡張機能です。[30]
OCSP ステープリングは、OCSP の運用上の課題、つまり遅延やプライバシーの低下を引き起こす追加のネットワーク要求を解決できます。[33]ただし、オンパス攻撃者によるダウングレード攻撃の影響を受ける可能性があります。 [9] RFC 7633 は、有効な OCSP 応答にステープリングされる要件を証明書に埋め込む拡張機能を定義しています。[34]この拡張機能により、ステープリングは、証明書が適切に発行された後に侵害された場合に効果的です。ただし、拡張機能なしで証明書が誤って発行される場合、ステープリングではセキュリティが提供されない可能性があります。[35]
クライアントとCAがステープルとマストステープル拡張機能を有効にするだけでなく、サーバー管理者も定期的に応答を取得し、ハンドシェイク中にクライアントに提供することでステープルをサポートするための措置を講じる必要があります。2018年には、Firefoxのみがマストステープルをサポートしており、最も使用されている2つのWebサーバー（Apache httpdとNginx）はどちらもOCSPステープルをまったくサポートしていませんでした。[36]
CRLite
CRLite は、カスケードされたブルーム フィルタによって失効ステータスを提供します。失効した証明書のリストから作成された単一のフィルタは、誤検知を生成します。オープン ドメインでは、これは失効チェックにとって克服できない問題です。ただし、証明書の透明性を使用して有効期限が切れていないすべての証明書を列挙することで、誤検知の網羅的なリストを作成できます。このリストは、証明書が最初のフィルタと一致する場合 (したがって、厳密に小さいドメインを持つ) に参照される 2 番目のフィルタを作成するために使用されます。2 番目のフィルタが一致しない場合は、真陽性であり、証明書は失効しています。ただし、2 番目のフィルタの一致は偽陰性である可能性があり、3 番目のフィルタが必要になるなどです。宇宙は有限であり、各フィルタのドメインは各ステップで厳密に減少するため、この手順では有限のフィルタ カスケードが生成されます。[37]
CRLiteはクライアントにフェイルハードを許可します。[23]
1 月の Web PKI のすべての証明書の失効状況は、ブルーム フィルター カスケードを使用した場合、1 日あたり 580 KB の更新で 10 MB のサイズと推定されました。2018 年 3 月には、このサイズは 18 MB に増加しました。[28] 1 億の証明書、1 日の有効期限 1%、失効率 2% のシミュレーションでは、CRLite では最初に 3.1 MB の準備が必要で、その後更新のために 1 日あたり 408 KB が必要でした。[38]
すべてのクライアントが同じ情報を取得するため、CRLiteではプライバシーに関する懸念はありません。[23]
CRLiteはまだ広く導入されていません。[9]しかし、導入は可能で、アグリゲータがCAからCRLを取得し、フィルタカスケードとその更新を提供し、クライアントがそれを使用するだけで済みます。CAからのアクションは不要であり、証明書保有者からのアクションも不要です。[23]アグリゲータは信頼できる第三者である必要はありません。フィルタカスケードは、入力されたCRLを正確に反映していることを証明するために監査できます。[39]プライベートCAもCRLite内で特別な処理が必要です。[40]
取り消しましょう
Let's Revoke は、失効ステータスのビット ベクトル(証明書失効ベクトル、または CRV と呼ばれる) を使用して、大量の失効ステータスをクライアントが効率的に取得できるようにします。[4] CA は、有効期限ごとに 1 つの CRV で、独自の証明書の CRV を生成します。CA の CRV のメンテナンスは、発行された証明書の数に比例します。CA は、発行された各証明書に新しいフィールドである失効番号を追加する必要があります。これにより、単一の CA からの証明書を証明書の有効期限と失効番号のタプルで識別できるようになります。このタプルにより、クライアントは CRV 内で識別された証明書のステータスを示すビットを効率的に見つけることができます。CRV は圧縮できます。ほとんどのビットはほとんどの場合設定されていないため、CRV は非常によく圧縮されると予想されます。各 CRV は固定の有効期限に関連付けられているため、古い CRV を効率的に破棄できます。CRV の更新はバッチ処理され、クライアントへの配布用に更新のタイムスタンプが付けられ、署名されます。[41]更新は3つの形式のいずれかで行われ、失効率に応じて最適な選択が行われ、効率的な通常操作と大量失効イベントの両方が可能になります。[42]
CRV はプッシュベースのチェックを可能にするのに十分小さいことが期待されますが、より制約のあるクライアントはプルベースのチェックを実行し、選択した CRV のみにアクセスしたり、証明書の検証まで CRV の取得を延期したりする可能性があります。 [43]プッシュベースのチェックで Let's Revoke を使用するクライアントは、失効番号を持つすべての証明書に対してフェイルハードを実行できます。[23] Let's Revoke のプライバシーへの影響と可用性はアーキテクチャによって異なります。すべてのチェックがプッシュベースである場合、プライバシーの漏洩はなく、サービス拒否やダウンタイムに対する脆弱性が軽減されます。ただし、プルベースのチェックを使用すると、ユーザーのアクティビティに関する情報の一部が漏洩し (CRV がアクセスされる形式で)、検証時に CRV にアクセスできなくなる可能性があります。[23]
1億の証明書、1日あたりの有効期限1%、失効率2%のシミュレーションでは、Let's Revokeでは最初に2.2 MBの準備が必要で、その後更新のために1日あたり114 KBが必要でした。[44]
Let's Revoke はまだ広く導入されていません。[9]クライアント実装の他に、CA が運用上の変更を行う必要があり、[45] CRL や OCSP ほど多くの情報を提供しません (有効性については証明書ごとに 1 ビットのみ)。CRL や OCSP は Let's Revoke を補完し、追加情報を提供するために使用できます。[46]導入は CA ごとに実行でき、クライアントはフェイルハード動作のメリットを徐々に享受できます。CRV は CRL や OCSP 応答よりも効率的であるため、CA は Let's Revoke を導入するインセンティブを得ることができます。[45]
その他の提案
プライベート情報検索技術は、プルベースのチェックによるプライバシーの懸念を和らげることができます。[47]クライアントが失効チェックを実行する代わりに、ミドルボックスが失効チェックのコストを集中化し、多くの接続にわたってそれを償却することができます。クライアントは失効情報専用のストレージを必要としません。[48]別の提案では、 FMラジオで失効情報を放送しました。[37]
参考文献
- ^ Durumeric et al. 2014, p.482.
- ^ ab Liu et al. 2015、p.184。
- ^ Liu et al. 2015、187ページ。
- ^ abcde スミス、ディキンソン＆シーモンズ 2020、p.1。
- ^ Liu et al. 2015、p.190。
- ^ Bruhner et al. 2022、p.2。
- ^ ワザンら。 2017年、IV。結論。
- ^ Chuat et al. 2020、p.3。
- ^ abcdefg シェファー、サンタンドレ、フォッサーティ 2022、7.5。証明書の失効。
- ^ ab スミス、ディキンソン、シーモンズ 2020、p.4。
- ^ Chuat et al. 2020、p.9-10。
- ^ Chung et al. 2018、p.3。
- ^ CA/B 2022、54-55頁。
- ^ CA/B 2022、56頁。
- ^ Korzhitskii & Carlsson 2021、p. 1.
- ^ Korzhitskii、Nemec、Carlsson 2022、p. 1.
- ^ リーボヴィッツら。 2021年、p. 7-8.
- ^ ab Larischら。 2017、p. 542.
- ^ スミス、ディキンソン、シーモンズ 2020年、2頁。
- ^ Liu et al. 2015、p.183。
- ^ 1634–1699: McCusker, JJ (1997)。「実際のお金はいくらですか? 米国経済における貨幣価値のデフレーターとして使用する歴史的物価指数: 補遺と訂正」(PDF)。アメリカ古物協会。1700–1799: McCusker, JJ (1992)。「実際のお金はいくらですか? 米国経済における貨幣価値のデフレーターとして使用する歴史的価格指数」(PDF)。アメリカ古物協会。1800年～現在:ミネアポリス連邦準備銀行。「消費者物価指数（推定）1800年～」 。 2024年2月29日閲覧。
- ^ プリンス 2014年。
- ^ abcdef スミス、ディキンソン＆シーモンズ2020、p.10。
- ^ Chuat et al. 2020、p.11。
- ^ ラリッシュら。 2017、p. 540。
- ^ Chuatら。 2020、p. 11-12。
- ^ スミス、ディキンソン、シーモンズ 2020年、2-3頁。
- ^ abc スミス、ディキンソン＆シーモンズ 2020、p.3。
- ^ ab Larischら。 2017、p. 541.
- ^ abc Liu et al. 2015、p.185。
- ^ Liu et al. 2015、189ページ。
- ^ Chung et al. 2018、p.6-7。
- ^ Chung et al. 2018、p.4。
- ^ ハラム・ベイカー 2015、1ページ。
- ^ ハラム・ベイカー 2015、7ページ。
- ^ Chung et al. 2018、p.2。
- ^ ab Larischら。 2017、p. 543.
- ^ スミス、ディキンソン、シーモンズ 2020年、8-10頁。
- ^ ラリッシュら。 2017、p. 548-9。
- ^ ラリッシュら。 2017、p. 548.
- ^ スミス、ディキンソン、シーモンズ 2020年、4-5頁。
- ^ スミス、ディキンソン、シーモンズ 2020年、6頁。
- ^ スミス、ディキンソン、シーモンズ 2020年、7-8頁。
- ^ スミス、ディキンソン、シーモンズ 2020年、8-9頁。
- ^ ab スミス、ディキンソン＆シーモンズ 2020、p.10-11。
- ^ スミス、ディキンソン、シーモンズ 2020年、8頁。
- ^ コーガン＆コリガン・ギブス 2021年、875-876頁。
- ^ Szalachowskiら2016年。
引用文献
- 「公的に信頼される証明書の発行と管理に関する基本要件」(PDF)。CA /ブラウザ フォーラム。2022 年 12 月 14 日。
- Bruhner, Carl Magnus; Linnarsson, Oscar; Nemec, Matus; Arlitt, Martin; Carlsson, Niklas (2022)。「警備員の交代: インターネット上の証明書と公開鍵の管理」(PDF)。パッシブおよびアクティブ測定。コンピュータサイエンスの講義ノート。第 13210 巻。pp. 50–80。doi : 10.1007 / 978-3-030-98785-5_3。ISBN 978-3-030-98784-8。
- Chuat, Laurent; Abdou, Abdelrahman; Sasse, Ralf; Sprenger, Christoph; Basin, David; Perrig, Adrian (2020). 「SoK: 委任と失効、Web の信頼チェーンにおける欠けているリンク」。2020 IEEE欧州セキュリティおよびプライバシーシンポジウム (EuroS&P)。pp. 624–638。arXiv : 1906.10775。doi : 10.1109 / EuroSP48549.2020.00046。ISBN 978-1-7281-5087-1. S2CID 215827701。
- チョン、テジュン; ロク、ジェイ; チャンドラセカラン、バラクリシュナン; チョフネス、デイビッド; レビン、デイブ; マッグス、ブルース M.; ミスラブ、アラン; ルーラ、ジョン; サリバン、ニック; ウィルソン、クリスト (2018)。「Web は OCSP 必須ステープルに対応していますか?」( PDF)。インターネット測定カンファレンス 2018 の議事録。pp. 105–118。doi : 10.1145/3278532.3278543。ISBN 9781450356190.S2CID 53223350 。
- Durumeric, Zakir; Li, Frank; Kasten, James; Amann, Johanna; Beekman, Jethro; Payer, Mathias; Weaver, Nicolas; Adrian, David; Paxson, Vern; Bailey, Michael; Halderman, J. Alex (2014)。「ハートブリードの問題」。2014年インターネット測定会議会議議事録。pp. 475–488。doi : 10.1145 / 2663716.2663755。ISBN 9781450332132. S2CID 142767。
- Hallam-Baker, Phillip (2015 年 10 月). X.509v3 トランスポート層セキュリティ (TLS) 機能拡張. doi : 10.17487/RFC7633 . RFC 7633.
- Kogan, Dmitry; Corrigan-Gibbs, Henry (2021 年 8 月)。「チェックリストを使用したプライベート ブロックリスト検索」。第 30 回 USENIX セキュリティ シンポジウム (USENIX セキュリティ 21) 。USENIX協会。pp . 875–892。ISBN 978-1-939133-24-3。
- Korzhitskii, Nikita; Carlsson, Niklas (2021). 「インターネット上の失効ステータス」。パッシブおよびアクティブ測定。コンピュータサイエンスの講義ノート。第12671巻。pp . 175–191。arXiv : 2102.04288。doi : 10.1007 /978-3-030-72582-2_11。ISBN 978-3-030-72581-5. S2CID 231846906。
- コルジツキ、ニキータ。ネメック、マトゥス。ニクラス・カールソン (2022)。 「失効の透明性のための事後証明書」。arXiv : 2203.02280。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017)。「CRLite: すべての TLS 失効をすべてのブラウザーにプッシュするためのスケーラブルなシステム」。2017 IEEEセキュリティおよびプライバシーシンポジウム (SP) 。pp . 539–556。doi : 10.1109/ sp.2017.17。ISBN 978-1-5090-5533-3. S2CID 3926509。
- Leibowitz, Hemi; Ghalwash, Haitham; Syta, Ewa; Herzberg, Amir (2021). 「CTng: 安全な証明書と失効の透明性」。Cryptology ePrint Archive。
- Liu, Yabing; Tome, Will; Zhang, Liang; Choffnes, David; Levin, Dave; Maggs, Bruce; Mislove, Alan; Schulman, Aaron; Wilson, Christo (2015)。「Web の PKI における証明書失効のエンドツーエンド測定」。2015年インターネット測定会議の議事録。pp. 183–196。doi : 10.1145 / 2815675.2815685。ISBN 9781450338486. S2CID 1955346。
- プリンス、マシュー( 2014 年 4 月 17 日)。「Heartbleed の隠れたコスト」。Cloudflare ブログ。Cloudflare 。
- Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (2022 年 11 月). トランスポート層セキュリティ (TLS) とデータグラム トランスポート層セキュリティ ( DTLS ) の安全な使用に関する推奨事項。doi : 10.17487/RFC9325 . RFC 9325。
- スミス、トレバー、ディキンソン、ルーク、シーモンズ、ケント( 2020)。「Let's Revoke: スケーラブルなグローバル証明書失効」。2020年ネットワークおよび分散システム セキュリティ シンポジウム議事録。doi : 10.14722 / ndss.2020.24084。ISBN 978-1-891562-61-7. S2CID 211268930。
- Szalachowski, Pawel; Chuat, Laurent; Lee , Taeho; Perrig, Adrian (2016). 「RITM: 中間での失効」。2016 IEEE 36th International Conference on Distributed Computing Systems (ICDCS)。pp. 189–200。arXiv : 1604.08490。doi : 10.1109 / ICDCS.2016.91。ISBN 978-1-5090-1483-5.S2CID 761560 。
- Wazan, AS; Laborde, R.; Chadwick, DW; Barrere, F.; Benzekri, A. (2017 年 9 月 11 日)。「Web ブラウザーによる TLS 接続検証: Web ブラウザーがまだ一致しないのはなぜか?」2017 IEEE 第 41 回年次コンピューター ソフトウェアおよびアプリケーション カンファレンス (COMPSAC)。pp. 665–674。doi : 10.1109 / COMPSAC.2017.240。ISBN 9781538603673. S2CID 28599113。