HOME»情報処理安全確保支援士掲示板»H29秋、午後1、問3、設問2(2)
投稿する
おっしゃるとおり、TLSハンドシェイクのクライアントからの
プリマスタシークレットを復号する時にサーバの秘密鍵が使われます。
この段階で秘密鍵が本物でないと、プリマスタシークレットの復号に
失敗します。その場合、その後のマスタシークレットの生成できず、
TLSハンドシェイク失敗となりセッションを確立できなくなります。
セッションが確立できなければ、そもそも成りすますことができません。
ここを一番誤解されているようです。
サーバ証明書内のCNと偽サイトのFQDNは一致します。
前提として、本物のサイトのFQDNと偽サイトのFQDNが一致してなければ
それは偽サイトではありません。
通常時、本物のサイトにアクセスする際は、DNSでFQDNをIPアドレスに
変換して、アクセスします。
しかし、DNSキャッシュポイズニングによって、DNSのキャッシュが汚染
されると、FQDNとIPアドレスの紐づけがおかしくなります。
それによって、本物のサイトのFQDNを名前解決したときに、偽のサイトの
IPアドレスに変換されてしまいます。
その結果、偽サイトにアクセスすることになります。
偽サイトのIPアドレスで接続する偽サイトは、
・本物のサイトと同じFQDN
・本物のサイトと同じ証明書
・本物のサイトから流出した秘密鍵
で構築されています。
まとめると、
・DNSキャッキュポイズニングによって接続先を強制的に偽サイトへ誘導
・偽サイトは本物のサイトと同じ構成をしているため、TLSセッションの
確立が成功してしまう
です。
ご指摘頂きありがとうございます。
秘密鍵の使用用途は
「偽サイトへHTTPSアクセスした際の証明書検証を成功させる」
ではなく、
「TLSセッションを張る際のプレマスタシークレットの復号に使う」が
正しいです。
訂正いたします。
H29秋、午後1、問3、設問2(2) [0917]
まんちかんさん(No.1)
重点対策の解説では、危殆化した鍵を使用していたサーバ使用者が受ける被害として、
「偽サイトにアクセスしても、それを正規のサイトとして認証してしまう」とあり、ここが分かりません。
CNとFQDNが一致しないので正規のサイトではないと分かるのではないでしょうか？
それとも、偽サイトがFQDNを修正したサーバ証明書を発行してもらっているのでしょうか？
この場合、公開鍵は既に正規サイトが登録済みなので重複すると思うのですが、
CAは重複チェックとかは実施していないのでしょうか？
すいませんが、どなたかご解説をお願い致します。
「偽サイトにアクセスしても、それを正規のサイトとして認証してしまう」とあり、ここが分かりません。
CNとFQDNが一致しないので正規のサイトではないと分かるのではないでしょうか？
それとも、偽サイトがFQDNを修正したサーバ証明書を発行してもらっているのでしょうか？
この場合、公開鍵は既に正規サイトが登録済みなので重複すると思うのですが、
CAは重複チェックとかは実施していないのでしょうか？
すいませんが、どなたかご解説をお願い致します。
2022.09.05 21:41
pixさん(No.2)
★SC ダイヤモンドマイスター
偽サイトの用意のために、新規に偽の証明書を発行する必要はありません。
偽サイトへの誘導には以下の段階があります。
１．DNSキャッシュポイズニングによって、正規サイトへの接続を
偽サイトに誘導する
２．偽サイトへHTTPSアクセスした際の証明書検証を成功させる
です。
この手順ですが、１．の実現自体は特に制限なく実現できます。
しかし、２．を実現するのは非常に難しいです。
理由ですが、HTTPSアクセスに用いられる秘密鍵は厳重にサーバ側で機密として
管理されているからです。
現代のサイトの安全性はこの２．を実現することが不可能であることが
大前提となっています。
しかしこの点は諸刃の剣で、秘密鍵が外部に漏れてしまえば、
２．が簡単に実現されてしまいます。
正規サイトの証明書は公開されているものなので、だれでも簡単に入手できます。
これを漏えいした秘密鍵と併せれば、証明書は正規の機関から発行されたもの
なので、証明書の検証が成功してしまいます。
偽サイトへの誘導には以下の段階があります。
１．DNSキャッシュポイズニングによって、正規サイトへの接続を
偽サイトに誘導する
２．偽サイトへHTTPSアクセスした際の証明書検証を成功させる
です。
この手順ですが、１．の実現自体は特に制限なく実現できます。
しかし、２．を実現するのは非常に難しいです。
理由ですが、HTTPSアクセスに用いられる秘密鍵は厳重にサーバ側で機密として
管理されているからです。
現代のサイトの安全性はこの２．を実現することが不可能であることが
大前提となっています。
しかしこの点は諸刃の剣で、秘密鍵が外部に漏れてしまえば、
２．が簡単に実現されてしまいます。
正規サイトの証明書は公開されているものなので、だれでも簡単に入手できます。
これを漏えいした秘密鍵と併せれば、証明書は正規の機関から発行されたもの
なので、証明書の検証が成功してしまいます。
2022.09.05 22:35
まんちかんさん(No.3)
pixさん、さっそくのご回答ありがとうございます。
ここの原理が、なぜ実現出来るのかまだよくわかっていないです。
手持ちの参考書では、TLSハンドシェイクにおけるサーバの秘密鍵の使用箇所が、
クライアントから貰う共通鍵の素の復号以外に登場しません。
これでなぜ、サーバ秘密鍵の漏洩が成りすましに直結するのでしょうか？
※どこで秘密鍵が使用され、成りすましに利用されているのかが分かりません。
※実はCertificateの際に、デジタル署名も付与しているのでしょうか？
ハッシュ値については計算結果が一致することは分かりますが、
サーバ証明書内のCNと偽サイトのFQDNが一致しないと思います。
TLSハンドシェイク内の検証としてしは成功するものなのでしょうか？
何か勘違いしている可能性も多々ありますが、引き続きよろしくお願いいたします。
＞２．が簡単に実現されてしまいます。
ここの原理が、なぜ実現出来るのかまだよくわかっていないです。
手持ちの参考書では、TLSハンドシェイクにおけるサーバの秘密鍵の使用箇所が、
クライアントから貰う共通鍵の素の復号以外に登場しません。
これでなぜ、サーバ秘密鍵の漏洩が成りすましに直結するのでしょうか？
※どこで秘密鍵が使用され、成りすましに利用されているのかが分かりません。
※実はCertificateの際に、デジタル署名も付与しているのでしょうか？
＞なので、証明書の検証が成功してしまいます。
ハッシュ値については計算結果が一致することは分かりますが、
サーバ証明書内のCNと偽サイトのFQDNが一致しないと思います。
TLSハンドシェイク内の検証としてしは成功するものなのでしょうか？
何か勘違いしている可能性も多々ありますが、引き続きよろしくお願いいたします。
2022.09.05 23:41
pixさん(No.4)
★SC ダイヤモンドマイスター
>手持ちの参考書では、TLSハンドシェイクにおけるサーバの秘密鍵の使用箇所が、
>クライアントから貰う共通鍵の素の復号以外に登場しません。
おっしゃるとおり、TLSハンドシェイクのクライアントからの
プリマスタシークレットを復号する時にサーバの秘密鍵が使われます。
この段階で秘密鍵が本物でないと、プリマスタシークレットの復号に
失敗します。その場合、その後のマスタシークレットの生成できず、
TLSハンドシェイク失敗となりセッションを確立できなくなります。
セッションが確立できなければ、そもそも成りすますことができません。
>サーバ証明書内のCNと偽サイトのFQDNが一致しないと思います。
>TLSハンドシェイク内の検証としてしは成功するものなのでしょうか？
ここを一番誤解されているようです。
サーバ証明書内のCNと偽サイトのFQDNは一致します。
前提として、本物のサイトのFQDNと偽サイトのFQDNが一致してなければ
それは偽サイトではありません。
通常時、本物のサイトにアクセスする際は、DNSでFQDNをIPアドレスに
変換して、アクセスします。
しかし、DNSキャッシュポイズニングによって、DNSのキャッシュが汚染
されると、FQDNとIPアドレスの紐づけがおかしくなります。
それによって、本物のサイトのFQDNを名前解決したときに、偽のサイトの
IPアドレスに変換されてしまいます。
その結果、偽サイトにアクセスすることになります。
偽サイトのIPアドレスで接続する偽サイトは、
・本物のサイトと同じFQDN
・本物のサイトと同じ証明書
・本物のサイトから流出した秘密鍵
で構築されています。
まとめると、
・DNSキャッキュポイズニングによって接続先を強制的に偽サイトへ誘導
・偽サイトは本物のサイトと同じ構成をしているため、TLSセッションの
確立が成功してしまう
です。
2022.09.06 06:08
まんちかんさん(No.5)
pixさん、再度のご回答ありがとうございます。
ようやく理解できました。スッキリしました。
お忙しいところ詳細なご解説をありがとうございました。
ようやく理解できました。スッキリしました。
お忙しいところ詳細なご解説をありがとうございました。
2022.09.06 08:32
昭和62年さん(No.6)
pixさんへ
サーバの秘密鍵でサーバ証明書の検証を行うみたいな書きぶりですが、
証明書の検証はブラウザが持っているルート証明書で行うはずなので、
説明がおかしくないですか
> ２．偽サイトへHTTPSアクセスした際の証明書検証を成功させる
> しかし、２．を実現するのは非常に難しいです。
> 理由ですが、HTTPSアクセスに用いられる秘密鍵は厳重にサーバ側で機密として
> 管理されているからです。
> 現代のサイトの安全性はこの２．を実現することが不可能であることが
> 大前提となっています。
サーバの秘密鍵でサーバ証明書の検証を行うみたいな書きぶりですが、
証明書の検証はブラウザが持っているルート証明書で行うはずなので、
説明がおかしくないですか
2022.09.06 09:10
pixさん(No.7)
★SC ダイヤモンドマイスター
この投稿は投稿者により削除されました。(2022.09.06 09:28)
2022.09.06 09:28
pixさん(No.8)
★SC ダイヤモンドマイスター
>サーバの秘密鍵でサーバ証明書の検証を行うみたいな書きぶりですが、
>証明書の検証はブラウザが持っているルート証明書で行うはずなので、
>説明がおかしくないですか
ご指摘頂きありがとうございます。
秘密鍵の使用用途は
「偽サイトへHTTPSアクセスした際の証明書検証を成功させる」
ではなく、
「TLSセッションを張る際のプレマスタシークレットの復号に使う」が
正しいです。
訂正いたします。
2022.09.06 09:29