HOME»情報処理安全確保支援士掲示板»平成29年春午後Ⅰ 問1の設問2について
投稿する
平成29年春午後Ⅰ 問1の設問2について [0712]
ゆうまさん(No.1)
「Webブラウザの設定でサーバ証明書の検証に失敗した場合は接続しない設定になっている」という前提があり、管理用PCからCRMサーバとHTTPS通信する際のサーバ証明書のサーバ証明書の検証は成功するようです。
そこまではわかるのですが、AさんPCなどの他のPCからCRMサーバとHTTPS通信する際は、そのPCがCRMサーバの正規のサーバ証明書を持っていないためサーバ証明書の検証に失敗し、接続しないため中間者攻撃を防げるということらしいのですが、そこがよくわかりません。
サーバ証明書はHTTPS接続を要求すれば、そのサーバからもらえてPC側で検証するものという認識なので、AさんPCやほかのPCもサーバ証明書を入手できるのでは?と思ってしまいます。この認識がそもそも間違っているのでしょうか?それともCRMサーバはサーバ証明書をHTTPS接続要求をしてきた相手に配布するような設定にはしておらず、管理用PCにはサーバ証明書をあらかじめインストールしているということなのでしょうか?
そこまではわかるのですが、AさんPCなどの他のPCからCRMサーバとHTTPS通信する際は、そのPCがCRMサーバの正規のサーバ証明書を持っていないためサーバ証明書の検証に失敗し、接続しないため中間者攻撃を防げるということらしいのですが、そこがよくわかりません。
サーバ証明書はHTTPS接続を要求すれば、そのサーバからもらえてPC側で検証するものという認識なので、AさんPCやほかのPCもサーバ証明書を入手できるのでは?と思ってしまいます。この認識がそもそも間違っているのでしょうか?それともCRMサーバはサーバ証明書をHTTPS接続要求をしてきた相手に配布するような設定にはしておらず、管理用PCにはサーバ証明書をあらかじめインストールしているということなのでしょうか?
2021.09.08 15:34
わいわいさん(No.2)
サーバ証明書の動作原則として、サーバ証明書だけあっても、
その対になる秘密鍵がなければ正常なSSL通信は実現できません
TLSの盲点を突くようなすごく細かいところで抜け道があるかも
しれませんが大原則として、この動作によってなりすましを
検知するという認識でよいと思います
その対になる秘密鍵がなければ正常なSSL通信は実現できません
TLSの盲点を突くようなすごく細かいところで抜け道があるかも
しれませんが大原則として、この動作によってなりすましを
検知するという認識でよいと思います
2021.09.08 16:25
昭和62年さん(No.3)
サーバ証明書の検証に失敗するのは、その証明書のルート証明書を持っていないからです。
管理用PC:あらかじめ必要なルート証明書をインストールしてある→検証可能
一般PC:必要なルート証明書を持っていない→検証できない
管理用PC:あらかじめ必要なルート証明書をインストールしてある→検証可能
一般PC:必要なルート証明書を持っていない→検証できない
2021.09.08 17:49
受験生さん(No.4)
NO3さんの解釈であってるかと思います。サーバ証明書はPKIの仕組みに基づいているので、サーバから送信されたサーバ証明書は認証局のディジタル証明書が含まれています。この認証局のディジタル証明書を検証することで、送信されたサーバ証明書の真正性を確認するのです。このくっついてきた認証局のディジタル証明書をどのように検証するかというと、これはブラウザにルート認証局のディジタル証明書である「ルート証明書」をインストールしないといけません。普段使っているブラウザが当たり前のようにSSL/TLS通信できるのは、主要なルート証明書がインストールされているからです。認証局は階層構造になっているので、上位の認証局が下位の認証局を認証することができます。「ルート認証局」はその最上位の認証局です。ですのでブラウザは主要なルート証明書のみインストールされていれば大丈夫で、すべての認証局のディジタル証明書をインストールする必要はないのです。
裏を返せば、そのサーバ証明書を署名した認証局のディジタル証明書、もしくはそれを認証している上位の認証局のディジタル証明書がブラウザにインストールされていないと、サーバ証明書を検証できませんから、通信ができないのです。
よくあるのが「プライベートCA」というもので、社内の中のみなど限られた範囲で利用する認証局があります。これは外で使うものではないですから、他の認証局に認証はしてもらわずに、ブラウザに当該認証局のディジタル証明書をインストールすることで、このプライベートCAを検証できるようにします。問題を読んでいないのですが、この辺りではないでしょうか。
手順をおさらいします。ブラウザがサーバにSSL/TLS通信を開始する→サーバからサーバ証明書が送られてくる。→サーバ証明書を認証した認証局を、ブラウザにインストールされているディジタル証明書で検証する→検証できればサーバが正当な通信相手であると確認できる→サーバとクライアントがお互いに乱数を送りあう(ここまで暗号化されていない)→通信を暗号化するための共通鍵を作るための「プレマスタシークレット」をクライアントが発行し、サーバ証明書内のサーバの公開鍵で暗号化してサーバに送信する。→お互いに同じ共通鍵ができるので、それで暗号化通信開始
No2さんの「秘密鍵がなければ~」については、それは暗号化通信で用いる共通鍵という意味で言っていれば、共通鍵はお互いが送りあった乱数とプレマスタシークレットでお互いが同じ鍵を生成するというメカニズムですので誤りですし、ディジタル証明書に含まれる鍵という言う意味で言っていれば、ディジタル証明書に含まれているのは「公開鍵」ですので誤りです。秘密鍵が流出したら大変なことになります。
裏を返せば、そのサーバ証明書を署名した認証局のディジタル証明書、もしくはそれを認証している上位の認証局のディジタル証明書がブラウザにインストールされていないと、サーバ証明書を検証できませんから、通信ができないのです。
よくあるのが「プライベートCA」というもので、社内の中のみなど限られた範囲で利用する認証局があります。これは外で使うものではないですから、他の認証局に認証はしてもらわずに、ブラウザに当該認証局のディジタル証明書をインストールすることで、このプライベートCAを検証できるようにします。問題を読んでいないのですが、この辺りではないでしょうか。
手順をおさらいします。ブラウザがサーバにSSL/TLS通信を開始する→サーバからサーバ証明書が送られてくる。→サーバ証明書を認証した認証局を、ブラウザにインストールされているディジタル証明書で検証する→検証できればサーバが正当な通信相手であると確認できる→サーバとクライアントがお互いに乱数を送りあう(ここまで暗号化されていない)→通信を暗号化するための共通鍵を作るための「プレマスタシークレット」をクライアントが発行し、サーバ証明書内のサーバの公開鍵で暗号化してサーバに送信する。→お互いに同じ共通鍵ができるので、それで暗号化通信開始
No2さんの「秘密鍵がなければ~」については、それは暗号化通信で用いる共通鍵という意味で言っていれば、共通鍵はお互いが送りあった乱数とプレマスタシークレットでお互いが同じ鍵を生成するというメカニズムですので誤りですし、ディジタル証明書に含まれる鍵という言う意味で言っていれば、ディジタル証明書に含まれているのは「公開鍵」ですので誤りです。秘密鍵が流出したら大変なことになります。
2021.09.08 23:57
モフさん(No.5)
No2さんの「秘密鍵がなければ~」はディジタル署名が付与できずAさんのPCがCRMサーバになりすませないという意味だと思われます。
ルート証明書は少なくとも営業業務に携わる従業員のPC全てにインストールされているはずです。ルート証明書で検証できないことを、攻撃を防げる根拠とするには対象の機器が限定的なのでなさそうかなと思います。
ルート証明書は少なくとも営業業務に携わる従業員のPC全てにインストールされているはずです。ルート証明書で検証できないことを、攻撃を防げる根拠とするには対象の機器が限定的なのでなさそうかなと思います。
2021.09.09 01:45
受験生さん(No.6)
今問題読んできました。中間者攻撃の話だったんですね。てっきりブラウザにプライベートCAのディジタル証明書のインストールが足りていないという凡ミスかと思いました。
攻撃名:中間者攻撃 or MITM攻撃
機器名:CRMサーバ
答えは以上であると思います。
今回のケースでは、サーバ証明書は検証可能な認証局による署名付きで、ブラウザは検証不可能なサーバ証明書であった場合ブロックする設定なっています。サーバ証明書は盗聴して奪取することができますが、サーバ証明書を生成した秘密鍵がないと、なりすましサーバにセットしたところでクライアントからのプレマスタシークレットを復号出来ませんので共通鍵も生成できず、通信はできません。No2さんの言っていたこと秘密鍵の意味を理解しました。
では、なりすましサーバでサーバ証明書を作ってしまったらどうなるか。サーバ証明書を発行することはできますが、認証局がそのディジタル証明書を署名してくれないので、認証局の署名なしサーバ証明書(オレオレ証明書)をサーバにセットするほかありません。そのようなサーバ証明書はブロックする設定になっていれば、なりすましサーバをブロックできますよね?
攻撃名:中間者攻撃 or MITM攻撃
機器名:CRMサーバ
答えは以上であると思います。
今回のケースでは、サーバ証明書は検証可能な認証局による署名付きで、ブラウザは検証不可能なサーバ証明書であった場合ブロックする設定なっています。サーバ証明書は盗聴して奪取することができますが、サーバ証明書を生成した秘密鍵がないと、なりすましサーバにセットしたところでクライアントからのプレマスタシークレットを復号出来ませんので共通鍵も生成できず、通信はできません。No2さんの言っていたこと秘密鍵の意味を理解しました。
では、なりすましサーバでサーバ証明書を作ってしまったらどうなるか。サーバ証明書を発行することはできますが、認証局がそのディジタル証明書を署名してくれないので、認証局の署名なしサーバ証明書(オレオレ証明書)をサーバにセットするほかありません。そのようなサーバ証明書はブロックする設定になっていれば、なりすましサーバをブロックできますよね?
2021.09.09 03:10
ゆうまさん(No.7)
皆さんのおかげで9割方わかったような気がします!本当にありがとうございました!
ただ、No.3さんがおっしゃられてる
管理用PC:あらかじめ必要なルート証明書をインストールしてある→検証可能
一般PC:必要なルート証明書を持っていない→検証できない
というのがちょっとよくわかんなかったです。
本問では、AさんのPCや一般のPCは業務上CRMサーバとHTTPS通信して顧客情報を参照することと、FWにおいてもPCセグメントからCRMサーバへのHTTPS通信が許可されていることが記述されているので、管理用PCだけでなく一般PCもCRMサーバのサーバ証明書に対するルート証明書がインストールしてあるんじゃないか?と思ったのですが、そこら辺はどういう感じになっているのでしょうか?
また、サーバ証明書の検証の動作についても少し疑問が残っています。
本問において、例えば、AさんPCがCRMサーバになりすまそうとして、他のPCにCRMサーバのサーバ証明書を送った場合(他のPCにルート証明書はインストールされている前提で)
①他のPCはサーバ証明書の検証には成功するけど、その後の共通鍵を生成する段階でCRMサーバの秘密鍵がないからエラーが起きる
②サーバ証明書の検証中にAさんPC側でCRMサーバの秘密鍵を使わないといけない処理があり、検証そのものが失敗する
この場合どっちのパターンで失敗するのでしょうか?
ただ、No.3さんがおっしゃられてる
管理用PC:あらかじめ必要なルート証明書をインストールしてある→検証可能
一般PC:必要なルート証明書を持っていない→検証できない
というのがちょっとよくわかんなかったです。
本問では、AさんのPCや一般のPCは業務上CRMサーバとHTTPS通信して顧客情報を参照することと、FWにおいてもPCセグメントからCRMサーバへのHTTPS通信が許可されていることが記述されているので、管理用PCだけでなく一般PCもCRMサーバのサーバ証明書に対するルート証明書がインストールしてあるんじゃないか?と思ったのですが、そこら辺はどういう感じになっているのでしょうか?
また、サーバ証明書の検証の動作についても少し疑問が残っています。
本問において、例えば、AさんPCがCRMサーバになりすまそうとして、他のPCにCRMサーバのサーバ証明書を送った場合(他のPCにルート証明書はインストールされている前提で)
①他のPCはサーバ証明書の検証には成功するけど、その後の共通鍵を生成する段階でCRMサーバの秘密鍵がないからエラーが起きる
②サーバ証明書の検証中にAさんPC側でCRMサーバの秘密鍵を使わないといけない処理があり、検証そのものが失敗する
この場合どっちのパターンで失敗するのでしょうか?
2021.09.09 22:41
昭和62年さん(No.8)
No.3です。
管理用PCからCRMサーバとHTTPS通信する際のサーバ証明書のサーバ証明書の検証は成功するようです。
(中略)
AさんPCなどの他のPCからCRMサーバとHTTPS通信する際は、そのPCがCRMサーバの正規のサーバ証明書を持っていないためサーバ証明書の検証に失敗し、
の部分だけ読んで、問題文や解答を読まずに書き込んだので、No.3の2行目と3行目は見当違いです。
見当違いなので、わからなくて当然です。(すみません)
・AさんのPCがCRMサーバになりすまそうとしたときに、本物のサーバ証明書を使った場合
本物の証明書なので検証は成功します。
しかし、証明書に含まれる公開鍵とペアになる秘密鍵をAさんPCは持っていないはずなので、暗号化通信のフェーズに進めません。※CRMサーバから秘密鍵を取り出せていたら中間者攻撃は成功します。
・AさんのPCがCRMサーバになりすまそうとしたときに、偽のサーバ証明書を使った場合
偽のサーバ証明書の検証には、偽のサーバ証明書用のルート証明が必要です。
各PCは、偽のサーバ証明書用のルート証明は持っていないので、ブラウザがサーバ証明書の検証に失敗します。
ちなみに、オレオレ証明書ですが、ちゃんと署名されていて、オレオレ証明書自身で検証できます。
(自己署名証明書)
自分で正しいと主張しているから、「オレオレ」なんです。
しかし、怪しすぎるので、ブラウザは信用できないと判断してくれます。
管理用PCからCRMサーバとHTTPS通信する際のサーバ証明書のサーバ証明書の検証は成功するようです。
(中略)
AさんPCなどの他のPCからCRMサーバとHTTPS通信する際は、そのPCがCRMサーバの正規のサーバ証明書を持っていないためサーバ証明書の検証に失敗し、
の部分だけ読んで、問題文や解答を読まずに書き込んだので、No.3の2行目と3行目は見当違いです。
見当違いなので、わからなくて当然です。(すみません)
・AさんのPCがCRMサーバになりすまそうとしたときに、本物のサーバ証明書を使った場合
本物の証明書なので検証は成功します。
しかし、証明書に含まれる公開鍵とペアになる秘密鍵をAさんPCは持っていないはずなので、暗号化通信のフェーズに進めません。※CRMサーバから秘密鍵を取り出せていたら中間者攻撃は成功します。
・AさんのPCがCRMサーバになりすまそうとしたときに、偽のサーバ証明書を使った場合
偽のサーバ証明書の検証には、偽のサーバ証明書用のルート証明が必要です。
各PCは、偽のサーバ証明書用のルート証明は持っていないので、ブラウザがサーバ証明書の検証に失敗します。
ちなみに、オレオレ証明書ですが、ちゃんと署名されていて、オレオレ証明書自身で検証できます。
(自己署名証明書)
自分で正しいと主張しているから、「オレオレ」なんです。
しかし、怪しすぎるので、ブラウザは信用できないと判断してくれます。
2021.09.10 00:08
わいわいさん(No.9)
この投稿は投稿者により削除されました。(2021.09.10 00:28)
2021.09.10 00:28
わいわいさん(No.10)
この投稿は投稿者により削除されました。(2021.09.10 01:02)
2021.09.10 01:02
わいわいさん(No.11)
長文失礼致します
この問題をよく読み返した結果、私の中で解釈が二転三転しました
この問題自体はかなり広く解釈できると思われますので
私の解釈をお答え致します
No.1さんの質問は「本物のサーバ証明書+秘密鍵がない」の場合についてです
この場合は秘密鍵がないことで正常なHTTPS通信ができなくなります
続く回答はこのケースを論じております
No.3さんのケースは「偽のサーバ証明書+偽の秘密鍵」の場合についての解説です
この場合は発行元のルート証明書がPCに入っていないので証明書パスの
検証で失敗します
■サーバ証明書の検証動作
No.1さんの質問の「本物のサーバ証明書+秘密鍵がない」場合ですが
このケースは多少グレーな部分が存在します
私もその部分の解釈に悩みました
・最初の「証明書パス」の検証はこの段階は秘密鍵を必要としないので
パスできると思われます
共通鍵を生成する部分で、生成に使用するアルゴリズムが
・RSAの場合
ここで秘密鍵が必要になるので、検証に失敗する
・DH,ECDHの場合
ここでは秘密鍵が必要にならないので、パスできる
秘密鍵自体はCRMサーバから外に出ることはないので、このような
ケースはありません
そのほか証明書の検証に失敗するケースとして、ディジタル署名が
考えられます
ディジタル署名使用時はCRMサーバ側で署名のために秘密鍵が必要になるので
その段階で証明書の検証に失敗するでしょう
問題文には「サーバ証明書の検証に失敗」とのみ記述があり
どの段階とは書いていないので、このように深読みができてしまいます
本来の問題を回答する場合にはここまで考慮する必要はないでしょう
シンプルに「本物のサーバ証明書+秘密鍵がない」の場合は
正常にHTTPS通信ができないの解釈で十分と思われます
この問題をよく読み返した結果、私の中で解釈が二転三転しました
この問題自体はかなり広く解釈できると思われますので
私の解釈をお答え致します
No.1さんの質問は「本物のサーバ証明書+秘密鍵がない」の場合についてです
この場合は秘密鍵がないことで正常なHTTPS通信ができなくなります
続く回答はこのケースを論じております
No.3さんのケースは「偽のサーバ証明書+偽の秘密鍵」の場合についての解説です
この場合は発行元のルート証明書がPCに入っていないので証明書パスの
検証で失敗します
■サーバ証明書の検証動作
No.1さんの質問の「本物のサーバ証明書+秘密鍵がない」場合ですが
このケースは多少グレーな部分が存在します
私もその部分の解釈に悩みました
・最初の「証明書パス」の検証はこの段階は秘密鍵を必要としないので
パスできると思われます
>①他のPCはサーバ証明書の検証には成功するけど、
>その後の共通鍵を生成する段階でCRMサーバの秘密鍵がないから
>エラーが起きる
共通鍵を生成する部分で、生成に使用するアルゴリズムが
・RSAの場合
ここで秘密鍵が必要になるので、検証に失敗する
・DH,ECDHの場合
ここでは秘密鍵が必要にならないので、パスできる
>②サーバ証明書の検証中にAさんPC側でCRMサーバの秘密鍵を
>使わないといけない処理があり、検証そのものが失敗する
秘密鍵自体はCRMサーバから外に出ることはないので、このような
ケースはありません
そのほか証明書の検証に失敗するケースとして、ディジタル署名が
考えられます
ディジタル署名使用時はCRMサーバ側で署名のために秘密鍵が必要になるので
その段階で証明書の検証に失敗するでしょう
問題文には「サーバ証明書の検証に失敗」とのみ記述があり
どの段階とは書いていないので、このように深読みができてしまいます
本来の問題を回答する場合にはここまで考慮する必要はないでしょう
シンプルに「本物のサーバ証明書+秘密鍵がない」の場合は
正常にHTTPS通信ができないの解釈で十分と思われます
2021.09.10 01:22
ゆうまさん(No.12)
なるほど!皆様ご丁寧に解説していただき本当にありがとうございました!とても勉強になりました。
また何かわからないこことがあったら聞かせていただくので、その時はまたよろしくお願いいたします
m(_ _)m
また何かわからないこことがあったら聞かせていただくので、その時はまたよろしくお願いいたします
m(_ _)m
2021.09.10 22:46