H29 春  午後2-1問2(2)

Mikiさん  
(No.1)
掲題の件について質問をさせていただきます。

「発行した証明書と対応する秘密鍵」というのは(1)より、被疑サーバの証明書と秘密鍵ということですか?

もしそうであるならば、どうやって被疑サーバの秘密鍵を取得できるのでしょうか。
2024.03.08 18:18
Mikiさん  
(No.2)
よろしくお願いいたします。
2024.03.08 18:18
pixさん 
SC ダイヤモンドマイスター
(No.3)
質問は「H29 春 午後2【問1 設問2】(2)」でしょうか。

パケット検査のためのHTTPS復号についての問題です。
参考になる質問が以下スレッドにありましたので、よろしければご参考までに。
https://www.sc-siken.com/bbs/1381.html
[1381] 平成31年春 午後Ⅱ 問1 設問6

被疑サーバの秘密鍵を入手することは不可能です。
そのため自前で偽装用のサーバ証明書と秘密鍵を用意する必要があります。

用意する方法ですが、問中には具体的な方法は書かれていません。
しかし、以下のような手順であると推測されます。
プライベート認証局を用意し、
・秘密鍵の生成
・コモンネームが被疑サーバであるサーバ証明書の発行
を行います。
加えて、プライベート認証局のサーバ証明書を被疑PCに
「信頼するCAのデジタル証明書」
として追加しておきます。
2024.03.08 20:29
Mikiさん  
(No.4)
早々にご説明いただきありがとう御座います。

HTTPSの通信に必要なサーバの検証をするという意味でサーバ証明書をダウンロードするのはわかったのですが、

そもそもHTTPSは共通鍵で暗号化・復号化を行うので、クライアントが持っている共通鍵を使えば良いのではないでしょうか。
秘密鍵は何に使うのでしょうか。

無知で申し訳ありません。
よろしくお願いいたします。
2024.03.09 12:50
Mikiさん  
(No.5)
プライベート認証局で発行した被疑サーバのサーバ証明書をクライアント(被疑pc)の信頼できるCAのデジタル証明書として登録する(pixさんのご説明)

→証明書に対する秘密鍵を中継サーバ1に組み込む

→HTTPSで暗号復号に必要な共通鍵を受け渡しできるようになる(サーバ証明書にある公開鍵で暗号化された共通鍵を秘密鍵で復号する)

→HTTPS通信内容を復号できるようになる

という流れであっておりますでしょうか!?

連投してしまい恐縮ですが、ご確認のほどよろしくお願いいたします。
2024.03.09 15:13
pixさん 
SC ダイヤモンドマイスター
(No.6)
スレ主様の以下の流れは
>→HTTPSで暗号復号に必要な共通鍵を受け渡しできるようになる(サーバ証明書にある
>公開鍵で暗号化された共通鍵を秘密鍵で復号する)
これは鍵交換アルゴリズムにRSAを利用した場合の動作になります。
その際はここで公開鍵と秘密鍵が利用されます。

もし、鍵交換アルゴリズムにDH(Diffie-Hellman)を利用した場合は、ここでは公開鍵と
秘密鍵は利用されません。
しかし、DHのパラメータの認証にデジタル署名が必要となります。ここで署名アルゴリズム
としてRSAが利用され、公開鍵と秘密鍵が利用されます。
2024.03.09 16:06
Mikiさん  
(No.7)
承知いたしました。
ご回答いただきありがとうございます。

ちなみに、中継サーバ2からは再びHTTPS通信が始まっていますので暗号化が必要になるわけですよね、
その場合、被疑PCから共通鍵を受け取って暗号化をして被疑サーバまで通信を行なっているということになるのでしょうか。

よろしくお願いいたします。
2024.03.09 18:32
pixさん 
SC ダイヤモンドマイスター
(No.8)
>ちなみに、中継サーバ2からは再びHTTPS通信が始まっていますので暗号化が必要に
>なるわけですよね、
>その場合、被疑PCから共通鍵を受け取って暗号化をして被疑サーバまで通信を行なって
>いるということになるのでしょうか。
いいえ違います。中継サーバ2が被疑PCに偽装します。
被疑サーバからは中継サーバ2が被疑PCに見えています。
TLSセッションは以下2つが存在します。これらは別々のものです。
・被疑PC - 中継サーバ1間  ※被疑PCには中継サーバ1が被疑サーバに見える
・中継サーバ2 - 被疑サーバ間  ※被疑サーバには中継サーバ2が被疑PCにみえる
中継サーバ1 - 中継サーバ2間は暗号化されていないHTTP通信となります。

HTTPS復号の原理はMITM攻撃(中間者攻撃)を行っているのと同じです。
目的が悪意あるものか、パケット検査のためかの違いしかありません。
2024.03.09 18:47
Mikiさん  
(No.9)
ありがとう御座います。

中継サーバ2と被疑サーバで新しいhttps通信を行っているわけですね。
問題文の理解、中間者攻撃への理解が深まりました。

最後に気になったこととして、
下線②の直前「マルウェアがhttps通信を行う際、サーバ証明書の検証を行っている可能性を考慮し、」とあるのは
マルウェアがサーバの検証を行っていないと特別なアクションを起こすということなのでしょうか。
2024.03.09 19:11
pixさん 
SC ダイヤモンドマイスター
(No.10)
>最後に気になったこととして、
>下線②の直前「マルウェアがhttps通信を行う際、サーバ証明書の検証を
>行っている可能性を考慮し、」とあるのはマルウェアがサーバの検証を
>行っていないと特別なアクションを起こすということなのでしょうか。
考え方が逆です。
通常のWebブラウザなどの正規のプログラムは証明書の
・証明書チェーン(正規の認証局から発行されているか)
・証明書の期限
・接続先サーバのFQDNと証明書のコモンネームが一致するか
などを検証する必要があります。

ですが、マルウェアはべつに正規のプログラムというわけではないです。
そのため作りが適当なマルウェアは証明書の検証などを行いません。
とはいえ、今回検査の対象となるマルウェアが証明書の検証まできっちりするように
作り込まれている可能性もあるため、本問のようなHTTPS検査を行える環境を
準備し、被疑PCに対して、偽装した証明書を本物と思わせるような環境を準備した
ということになります。
2024.03.09 19:20
Mikiさん  
(No.11)
なるほど…
正規のプログラムにマルウェアが合わせてくることを考慮してhttps環境を構築しているわけですね。

pixさんの解説で非常に理解が深まりました。

本当にありがとう御座いました。
2024.03.09 19:59

返信投稿用フォーム

スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。

その他のスレッド


Pagetop