HOME»情報処理安全確保支援士掲示板»令和５年 午後 問2 (2)c,d
投稿する
[1469] 令和５年 午後 問2 (2)c,d
なぜさん(No.1)
別にRFCで定義されているわけでもないですし、ブラウザの実装次第でいくらでも回答が変わりますよね。
代表的なブラウザChromeやIEがこのような表示をしているのでしょうか？
不思議な問題でした。
代表的なブラウザChromeやIEがこのような表示をしているのでしょうか？
不思議な問題でした。
2024.03.31 16:15
pixさん(No.2)
★SC ダイヤモンドマイスター
質問は『令和５年【秋】 午後 問2 【設問1】(2)c,d』でしょうか。
一般的に証明書の検証項目として以下の4項目が挙げられます。
・証明書チェーン（信頼されているCAから発行されているか）
・FQDNと証明書のCNの一致
・証明書の失効（CRL,OCSP)
・証明書の期限
ブラウザによって、文言は異なりますが、この4つを検証するのはWebブラウザとして
デファクトスタンダードです。
一般的に証明書の検証項目として以下の4項目が挙げられます。
・証明書チェーン（信頼されているCAから発行されているか）
・FQDNと証明書のCNの一致
・証明書の失効（CRL,OCSP)
・証明書の期限
ブラウザによって、文言は異なりますが、この4つを検証するのはWebブラウザとして
デファクトスタンダードです。
2024.03.31 16:26
なぜさん(No.3)
ありがとうございます！理解いたしました
2024.04.01 22:15
seta6261さん(No.4)
@pixさん
すみません、私もこの設問の解答には疑問持ってます。
接続するサイトのサーバ名(FQDN)と証明書に記載しているサーバ名が異なるというのは理解できないです。
1,偽サイトを用意するときには、偽サーバのFQDNを正規サーバのFQDNに設定できないですか？
2,偽証明書CNには偽サイトのサーバ名を設定できないですか？
設定できれば、エラーメッセージが表示されないと考えています。設問の中では特に偽サーバのサーバ名や偽証明書のCNが設定間違ってるとは見当たらないですね。
いつも丁寧に回答して下さって、本当に感謝します。よろしくお願いします。
すみません、私もこの設問の解答には疑問持ってます。
接続するサイトのサーバ名(FQDN)と証明書に記載しているサーバ名が異なるというのは理解できないです。
1,偽サイトを用意するときには、偽サーバのFQDNを正規サーバのFQDNに設定できないですか？
2,偽証明書CNには偽サイトのサーバ名を設定できないですか？
設定できれば、エラーメッセージが表示されないと考えています。設問の中では特に偽サーバのサーバ名や偽証明書のCNが設定間違ってるとは見当たらないですね。
いつも丁寧に回答して下さって、本当に感謝します。よろしくお願いします。
2024.04.05 16:39
pixさん(No.5)
★SC ダイヤモンドマイスター
すみません。具体的内容が汲み取れなかったので、わかる範囲で解答いたします。
とても細かい話になりますが、一般的なWebサーバにはFQDNを設定する箇所は
ありません。FQDNと似たものでServerNameというものはあります。しかし
FQDNとは役割が異なります。
そのため、偽サイト自体にFQDNを設定する必要はありません。
FQDNはDNSのAレコードでIPアドレスと紐づけるために設定されます。
クライアントはDNSクエリでFQDNを正引きしてIPアドレスを取得します。
したがって、FQDNを認識しているのはクライアント側ということになります。
このDNSクエリで名前解決する時に、DNSキャッシュポイズニングなどで不正な
IPアドレスを返すことで、クライアントはFQDNのIPアドレスの紐づけを誤解する
ことになります。
あとは、この不正なIPアドレスにアクセスし、証明書を取得した際に
クライアント側で自分が接続したと認識しているFQDNと証明書のCNを比較して
差異がないかをチェックします。
偽証明書のCNを偽サイトのサーバ名に設定することは簡単です。
・プライべート認証局から証明書を発行
・自己署名証明書を作成
これらの方法で簡単にできます。
この証明書ならば、クライアントが認識しているFQDNと証明書のCNは一致します。
そのため、「FQDNと証明書のCNの一致」はパスします。
しかし、この証明書は正規のCAから発行されたものではないので、
「証明書チェーン」の検証で失敗します。
以上のように証明書の真正性の根拠として一番重要なのは「証明書チェーン」の
検証です。
攻撃者がどんなに周到に準備しても、正規のCAから発行された証明書（厳密には
証明書と秘密鍵）を入手できないかぎり、証明書チェーンの検証が失敗します。
この証明書チェーンの検証によって、いくら偽の証明書を準備したとしても
確実に見破られるという事実が、証明書の安全性を担保している根拠の大元と
なります。
>1,偽サイトを用意するときには、偽サーバのFQDNを正規サーバのFQDNに
>設定できないですか？
とても細かい話になりますが、一般的なWebサーバにはFQDNを設定する箇所は
ありません。FQDNと似たものでServerNameというものはあります。しかし
FQDNとは役割が異なります。
そのため、偽サイト自体にFQDNを設定する必要はありません。
FQDNはDNSのAレコードでIPアドレスと紐づけるために設定されます。
クライアントはDNSクエリでFQDNを正引きしてIPアドレスを取得します。
したがって、FQDNを認識しているのはクライアント側ということになります。
このDNSクエリで名前解決する時に、DNSキャッシュポイズニングなどで不正な
IPアドレスを返すことで、クライアントはFQDNのIPアドレスの紐づけを誤解する
ことになります。
あとは、この不正なIPアドレスにアクセスし、証明書を取得した際に
クライアント側で自分が接続したと認識しているFQDNと証明書のCNを比較して
差異がないかをチェックします。
>2,偽証明書CNには偽サイトのサーバ名を設定できないですか？
偽証明書のCNを偽サイトのサーバ名に設定することは簡単です。
・プライべート認証局から証明書を発行
・自己署名証明書を作成
これらの方法で簡単にできます。
この証明書ならば、クライアントが認識しているFQDNと証明書のCNは一致します。
そのため、「FQDNと証明書のCNの一致」はパスします。
しかし、この証明書は正規のCAから発行されたものではないので、
「証明書チェーン」の検証で失敗します。
以上のように証明書の真正性の根拠として一番重要なのは「証明書チェーン」の
検証です。
攻撃者がどんなに周到に準備しても、正規のCAから発行された証明書（厳密には
証明書と秘密鍵）を入手できないかぎり、証明書チェーンの検証が失敗します。
この証明書チェーンの検証によって、いくら偽の証明書を準備したとしても
確実に見破られるという事実が、証明書の安全性を担保している根拠の大元と
なります。
2024.04.05 17:07
pixさん(No.6)
★SC ダイヤモンドマイスター
補足いたします。
証明書技術については、
・以下の3つの名前違いと使われるOSI階層
DNSでのFQDN
証明書のCN
WebサーバのServerName
・一般的なWebサーバの設定方法、
特にServerName,VirtualHost,SNI
・一般的なWebサーバへのアクセス方法
サーバへのアクセスは全てIPアドレスで行われる
IPアドレスを知るにはFQDNをDNSクエリで正引きする必要がある
これらすべての知識を有していることが、
証明書技術を正確に理解するために必要になります。
証明書技術については、
・以下の3つの名前違いと使われるOSI階層
DNSでのFQDN
証明書のCN
WebサーバのServerName
・一般的なWebサーバの設定方法、
特にServerName,VirtualHost,SNI
・一般的なWebサーバへのアクセス方法
サーバへのアクセスは全てIPアドレスで行われる
IPアドレスを知るにはFQDNをDNSクエリで正引きする必要がある
これらすべての知識を有していることが、
証明書技術を正確に理解するために必要になります。
2024.04.05 17:16
pixさん(No.7)
★SC ダイヤモンドマイスター
度々の補足失礼いたします。
さらに細かいことを言えば、
クライアントからアクセスする際に以下にFQDNがセットされます。
・HTTP ホストヘッダー
・TLSのSNI
この値はWebサーバ側でServerNameと照合されます。
そういった意味ではFQDN = ServerNameと考えてもよいかもしれません。
しかし、Webサーバ側でVirtulHostがない場合は、デフォルトホストに
接続するため、FQDNとしてのServerName設定は必須ではないです。
偽サイトであれば、なおの事VirtualHostを持つ意味ないので
FQDNとしてのServerNameの設定は意味がないと考えられます。
さらに細かいことを言えば、
クライアントからアクセスする際に以下にFQDNがセットされます。
・HTTP ホストヘッダー
・TLSのSNI
この値はWebサーバ側でServerNameと照合されます。
そういった意味ではFQDN = ServerNameと考えてもよいかもしれません。
しかし、Webサーバ側でVirtulHostがない場合は、デフォルトホストに
接続するため、FQDNとしてのServerName設定は必須ではないです。
偽サイトであれば、なおの事VirtualHostを持つ意味ないので
FQDNとしてのServerNameの設定は意味がないと考えられます。
2024.04.05 17:28
seta6261さん(No.8)
@pixさん
本当に感謝いたします。解説してくださって、理解できました。
こちらで確認したかったのは偽サーバ証明書のCNに正規サイトのFQDNを設定したら、設問の中のFQDNが異なるというエラーメッセージは出なくなることです。結論は偽AP、偽DNS、偽サイトを用意しても、最後では証明書チェーンのチェックで失敗します。
問題文には特に偽サーバ証明書のCNに違うFQDNを書いてるとの記述はなくて、FQDNが異なる答えが導きにくいなぁと思います。
ただし、自分の疑問をクリアできていて、感謝します。
ありがとうございます！
本当に感謝いたします。解説してくださって、理解できました。
こちらで確認したかったのは偽サーバ証明書のCNに正規サイトのFQDNを設定したら、設問の中のFQDNが異なるというエラーメッセージは出なくなることです。結論は偽AP、偽DNS、偽サイトを用意しても、最後では証明書チェーンのチェックで失敗します。
問題文には特に偽サーバ証明書のCNに違うFQDNを書いてるとの記述はなくて、FQDNが異なる答えが導きにくいなぁと思います。
ただし、自分の疑問をクリアできていて、感謝します。
ありがとうございます！
2024.04.05 18:05