HTTPS プロトコルを使用している場合、ブラウザと Web サーバー間で転送されるパッケージはすべて暗号化されているようです。そして、ブラウザーが Web サーバーとの通信セッションをサポートする必要があるのは、いわゆる証明書だけです。
したがって、同じ証明書を使用して、HTTPS サイトのログイン中に Wireshark によってキャプチャされたパッケージを復号化できることは明らかだと思います。
グーグルで検索したところ、秘密鍵を提供する必要があるというチュートリアルがいくつか見つかりましたが、これは不可能で非現実的だと思います。
ところで。次のシェル コマンドは、ホストから証明書を取得します。公開鍵を生成するツールはありますか?
echo QUIT | openssl s_client -connect <site>:443 | sed -ne '/BEGIN CERT/,/END CERT/p'
前もって感謝します。
いいえ、証明書を持っていても、ネットワーク キャプチャから HTTPS/SSL セッションを復号化することはできません。これが、 SSL の基礎となる公開鍵暗号化の要点です。
ブラウザのキーストアにあるのは、サーバーの公開鍵の有効性を検証する証明書です。この公開鍵にはアクセスできますが、暗号化アルゴリズムが対称的ではないため、セッション パケットの復号化には使用できません。
SSL セッションを復号化するには、サーバーの秘密鍵が必要ですが、通常の状況では、それらを取得するのは非常に困難です。
詳細については、 TLSに関するウィキペディアの記事も参照してください。
編集：
物事をもう少し明確にするために、上記の2つのリンクから主に切り取られた、素人の言葉でさらに情報を追加します.
公開キー暗号化は、非対称暗号化アルゴリズムに基づいています。これらには、公開鍵と秘密鍵という 1 つではなく2 つの鍵が含まれます。これら 2 つのキーはキー ペアを構成します。十分に強力なアルゴリズムを想定すると、公開鍵で暗号化されたものは何でも秘密鍵でのみ暗号化でき、その逆も同様です。公開鍵は「誰でも」広くアクセスできますが、秘密鍵は安全に保管され、その所有者だけが使用します。これはどのように役立ちますか？
サーバーには、誰でも読み取り可能な公開鍵と、安全に保管された (サーバー自体以外はアクセスできない) 秘密鍵で構成される鍵ペアがあります。
クライアントは、暗号化された各セッションの開始時に、サーバーの公開鍵を使用して対称アルゴリズムのかなり長いランダム鍵を暗号化します。そのキーはサーバーに送信されます。
対称鍵はこのように暗号化されているため、サーバーの秘密鍵を使用してのみ復号化できます。つまり、キャプチャされたネットワーク ストリームから抽出することはできず、残りのセッションで使用されるため、後で送信される情報も抽出できません。
サーバーは秘密鍵を使用してセッション対称鍵を取得しますが、すべて問題ありません。
それは...ですか？上記のスキームにはまだ 1 つの問題があります。クライアントはどのようにしてサーバーの公開鍵を取得しますか? より具体的には、どのようにして自分がサーバーと通信していて、途中で自分自身を挿入した詐欺師ではないことを知るのでしょうか ( Man In The Middle 攻撃を参照)。
クライアントはすべての公開鍵を知ることはできません。何百万もの公開鍵があります。サーバーからそれらを取得し、何らかの方法でそれらが関心のあるサーバーに属していることを確認する必要があります.
ここで、公開鍵暗号化の別の機能が登場します。以前は、公開鍵を使用してデータを暗号化し、目的の宛先のみがデータを復号化できるようにしていました。今度は反対のことを行います。秘密鍵を使用してデータを暗号化し、公開鍵でのみ復号化できるようにします。基本的に、公開鍵で復号化すると、データがサーバーからのものであることを人々が知ることができるように、データに署名します。これはどのように役立ちますか？
ブラウザーがインストールされると、比較的少数の公開鍵 (一般に証明書と呼ばれる) が事前にインストールされます。これらは、信頼できると見なされるエンティティ (通常は Verisign などの企業、政府、または一部の機関) である証明機関 (CA) に属します。認証局は、対応する秘密鍵を使用して、インターネットなどで利用可能な他の公開鍵に署名します。
そのため、ブラウザがサーバーに接続して公開鍵を受け取ると、その鍵は証明書ペアの秘密鍵で署名する必要があります。その証明書のペアは、ブラウザがプリインストールされたルート証明書の 1 つに対応する秘密鍵で署名された公開鍵に到達するまで、別の証明書などによって同様に署名されます。ルート証明書の詳細については、私の以前の回答を読むか、ウィキペディアの記事を読むことをお勧めします。
信頼できる鍵に到達するまで、各公開鍵は連続して署名されているため、クライアントは、接続の相手側のサーバーが実際に MyBank.com であり、次のカフェのテーブルにある犯罪者のラップトップではないことを確信できます。ワイヤレス接続をいじっています。
脆弱な SSL アルゴリズム (したがって、SSL プロトコル バージョンの連続) はありますが、最近の攻撃は一般的に実装を対象としています。
特別に細工された、または不正な形式の証明書を使用して、ブラウザー (およびその脆弱な実装) をだまして、公開鍵が実際には信頼できるエンティティによって署名されていると信じ込ませます。
クライアント ソフトウェア (ウイルスなど) の整合性を侵害して、生成時に対称キーを取得します。ただし、これらのほとんどの場合、たとえば、ユーザーがクレジット カード番号を入力するときにキーボード ストロークをキャプチャするなど、ブラウザに入力される興味深いデータをキャプチャする方が通常は簡単です。
サーバー自体を侵害し、秘密鍵を盗みます。疑いを持たないクライアントを標的にするほど簡単ではありませんが、それは実際に起こっており、非常に多くの暗号化されたセッションを危険にさらす可能性があります。現在の公開鍵インフラストラクチャ (PKI)には、侵害された鍵や無効な鍵を取り消して無効にするための完全なメカニズムがあります。
クライアントが対称キーの代わりに独自の一時的な公開キーを送信し、セッション全体で非対称アルゴリズムを使用すると、最後の攻撃を無効にすることができます。これにより、攻撃者がサーバーの秘密鍵を盗んで過去のセッションを侵害することは不可能になります。この手法はPerfect Forward Secrecyを保証するための基礎ですが、互換性やパフォーマンス上の理由から、残念ながらすべてのサーバーでまだ実装されているわけではありません。
thkalaはスポットです。MiTM があると仮定すると、一般的な状況下で、秘密鍵を持っている被害者に自己署名証明書を転送し、サーバーの実際の証明書を使用して、被害者による要求を宛先サーバーに転送できます。ただし、これには被害者が証明書の警告を受け入れる必要があります。
Ssl を無効にするもう 1 つの方法は、ssl セッション (lookup sslstrip) を削除することです。