CA署名付き証明書のスプーフィングは可能ですか？
私はこれまでこの状況について考えたことがありませんでした、私は完全に間違っているかもしれませんが、とにかくそれを明確にする必要があります。サーバーとの通信が開始されると、クライアントハンドシェイク中に、クライアントは公開鍵（CA署名済み）のコピーを受け取ります。これで、クライアントはCAによって署名されたこの公開鍵に完全にアクセスできます。
攻撃者が自分のサーバーをセットアップし、この公開キーを使用して、被害者に自分が実際のサーバーであると本質的に信じ込ませることができないのはなぜですか。もちろん、攻撃者は通信を解読するための秘密鍵を持っていませんが、ハンドシェイクの発生を止めることはできません。証明書が署名されているので、この証明書が被害者のブラウザに到達すると、証明書は本当に問題ないと言っています。
ここで何が欠けていますか？
ハンドシェイクには、次の（大まかな）手順が含まれます。
- サーバーは公開鍵を送信します。
- クライアントはその公開鍵を使用してセットアップ情報を暗号化し、それをサーバーに送り返します。
- サーバーはクライアントの送信を復号化し、それを使用して共有秘密を導き出します。
- 以降の手順では、その共有シークレットを使用して、使用する実際の暗号化を設定します。
したがって、あなたの質問に対する答えは、詐欺師はステップ3を実行できないためです（秘密鍵がないため）、ステップ4に進むことはできません。共有シークレットがないため、それはできます。 tハンドシェイクを完了します。
Asudhak、これが少し紛らわしいとしても気にしないでください。 非対称暗号 の発明は数学の大きな進歩でした。最初に遭遇したとき、それは不可能ではないにしても、直感に反するようです。
クライアント（多くの場合、Webブラウザー）とサーバー（多くの場合、Webブラウザー）が安全な通信チャネルを確立したい場合、いわゆる「鍵交換」を実行します。
サーバーがクライアントプログラムに提供する公開キーには、秘密は何も含まれていません。唯一の機能は情報を暗号化することです。
クライアントは、Webブラウザーだけが知っているワンタイムシークレットパスワードを生成します。次に、クライアントはサーバーの公開鍵を使用してencryptに秘密のパスワードを使用します。公開鍵は暗号化のみ可能で、公開鍵は復号化できません！
クライアントはこの暗号化された秘密のパスワードをサーバーに安全に送信できます。この鍵交換を傍受する可能性がある中間者は、クライアントによって生成され、サーバーの公開鍵で暗号化された一度限りの秘密を解読できないため、有用な情報を得ることができません。
サーバーおよびサーバーのみが対応する秘密鍵を持っています。サーバーの秘密鍵はdecryptにのみ使用できます。 サーバーの秘密鍵は誰にも送信されません！
サーバーは秘密鍵を使用して、クライアント（Webブラウザー）によって生成されたワンタイムシークレットパスワードを復号化します。
クライアントとサーバーは今誰も知らない秘密を知っています！
この秘密を使用すると、従来の対称暗号化アルゴリズムを使用してその後の会話を暗号化でき、チャネルが安全であるという確信度が高くなります。
さらに、クライアントには、信頼する組織の公開鍵を含む「 certificates 」のストアがあります。サーバーが、信頼された組織の秘密鍵で暗号化されたハッシュ値を含む証明書と呼ばれるデジタルドキュメントを提示しない場合、実際のTLS鍵交換は失敗します。クライアントはこのハッシュと信頼できる公開鍵を使用して、このサーバーが信頼できると見なされることを知ることができます。
クライアントがサーバーのパブリック証明書を取得し、マスターシークレットの生成に使用されるPreMasterSecretを暗号化するために使用するため、 TLSハンドシェイク を完了できません。
クライアントはClientKeyExchangeメッセージで応答します。このメッセージには、PreMasterSecret、公開鍵、または何も含まれていない場合があります。 （これも、選択した暗号に依存します。）このPreMasterSecretは、サーバー証明書の公開鍵を使用して暗号化されます。
次に、クライアントとサーバーは、乱数とPreMasterSecretを使用して、「マスターシークレット」と呼ばれる共通のシークレットを計算します。この接続の他のすべてのキーデータは、このマスターシークレット（およびクライアントとサーバーが生成したランダムな値）から導出され、慎重に設計された疑似ランダム関数を介して渡されます。
非対称暗号化では、公開鍵は決して秘密ではなく、一般に（他の欠陥がないと仮定して）攻撃者にとって役に立たないことに注意してください。
既存の回答は、証明書の公開鍵による暗号化について語っています。これは、常に実際に使用されるとは限りません（特にDSAまたはDHE暗号スイートで）。 （より詳細な回答があります ここ など）。
SSL/TLSハンドシェイクの直接の目的は、クライアントとサーバー間で共有プリマスターシークレットを確立することです。このプレマスターシークレットは、マスターシークレットに、次に暗号化キー（およびMAC）に導出されます。この手順は、より広く鍵交換と呼ばれます（ RFC 4346付録F.1.1 を参照）。
適切な相手と通信していることを確認するには、認証された鍵交換をサポートする暗号スイートを使用する必要があります。 （匿名暗号スイートは、賢明な構成ではデフォルトで無効になっています。）
この認証済みの鍵交換は、次の2つのカテゴリに分類されます。
RSA鍵交換（例：
TLS_RSA_WITH_AES_128_CBC_SHA）：クライアントは、サーバーの公開鍵（証明書に含まれる）を使用してプレマスターシークレットを暗号化します。正当なサーバーだけがその秘密鍵でこれを解読できます。DHE鍵交換（例：
TLS_DHE_RSA_WITH_AES_256_CBC_SHAまたはDSS証明書）を含む暗号スイート：Diffie-Hellman鍵交換が行われます。通常はエフェメラルDHですが、パラメーターが固定されているバリアント（DH、DHEではない）は非常にまれです。 （RSAベースの証明書があることは、RSA鍵交換を意味するものではありません。）サーバーはDHパラメーターに署名し、クライアントはサーバー証明書の公開鍵に対して署名を検証します。正当なサーバーだけがその秘密鍵で署名できたので、交換は認証されます。
1つの方法では暗号化を使用し、もう1つの方法ではデジタル署名を使用します。どちらも証明書の公開鍵を使用します。どちらも最終結果は同じです。クライアントが証明書の秘密鍵を持つサーバーとのみ共有できるプリマスターシークレット。
（もちろん、もう1つのポイントは、クライアントが証明書が有効であり、通信先のサーバーに発行されることを信頼していることを確認する必要があることですが、これらはわずかに別のポイントです。）
これは、公開鍵認証の基本と、Webブラウザーがドメイン名を介してWebサーバーと通信する方法を知っていることを前提としています。対話は、ユーザーのWebブラウザーと会社のWebサーバーの間で行われます。
公開鍵と秘密鍵
Webサーバーには公開鍵と秘密鍵があります。秘密鍵は、公開鍵で暗号化されたメッセージを復号化できます。公開鍵は、秘密鍵で暗号化されたメッセージを復号化できます。認証局には独自の公開鍵と秘密鍵があります。
Webサーバーは、その会社情報、公開鍵、およびドメイン名（SSL証明書に関連付ける）を認証局に送信します。認証局は、この要求がドメイン名の本物の所有者によって行われたことを証明するために、ドメイン名に関連付けられた電子メールアドレスに確認メッセージを送信します。この時点で、認証局はドメイン名の所有者が電子メールで要求を検証するまで待機します。
証明書の署名
認証局は、独自の秘密鍵を使用して、Webサーバーのドメイン名、会社情報、および公開鍵を暗号化します。認証局は暗号化された結果をWebサーバーに送信します。この結果はSSL証明書であり、Webサーバーのドメイン名、会社情報、公開鍵を含むテキストメッセージであり、すべて認証局の秘密鍵で暗号化されています。 Webサーバーはこの証明書をユーザーのブラウザーに送信します。
信頼できる認証局
Webブラウザーには、信頼できる認証局とその公開鍵のリストがプリロードされています。 Webブラウザーは、対応する認証局の公開鍵を使用して証明書を復号化します。この時点で、Webブラウザーは証明書とその内容が信頼できることを認識しています。これは、認証局の秘密鍵で暗号化されたメッセージのみが、その認証局の公開鍵によって首尾一貫して復号化できたためです。
これでWebブラウザーは、Webサーバーに関連付けられているはずの信頼できる会社情報、公開鍵、およびドメイン名を認識します。 Webブラウザーは、証明書のドメイン名がWebサーバーの実際のドメイン名と一致することを確認します。
この時点で、ドメイン名が一致する場合、WebブラウザーはWebサーバーが暗号化されたデータを送信するのに十分信頼できると判断します。また、この時点で、Webブラウザは、証明書の信頼できる公開鍵を使用してメッセージを暗号化できると判断します。これは、正規のWebサーバーの秘密鍵だけがメッセージを復号化できるためです。
信頼されていない公開鍵が使用された場合（認証局の検証を通過しない場合）、Webブラウザーは、悪意のあるサーバーの秘密鍵によってのみ復号化される機密情報を暗号化して送信した可能性があります！つまり、メッセージを暗号化することは、Webブラウザーが送信する情報を盗聴する唯一の防御策であるため、公開鍵を信頼することが不可欠です。
次に進むと、Webブラウザーは信頼できる公開鍵を使用してメッセージを暗号化し、暗号化されたメッセージをWebサーバーに送信します。 Webサーバーは、正規の秘密鍵を使用してメッセージを復号化します（秘密鍵がある場合）、復号化されたメッセージを正常に読み取ります。
共有秘密鍵
WebサーバーがWebブラウザーに応答する場合、そのメッセージも安全に送信する必要があります。 Webブラウザーは、公開鍵と秘密鍵を生成し、その公開鍵をWebサーバーに送信することにより、Webサーバーが行ったこと（認証局プロセスを除く）をコピーできます。これにより、双方向非対称暗号化と呼ばれる安全な接続が確立されます。ただし、そのような通信は、計算上（比較的）負担になります。
したがって、標準的なアプローチは、メッセージを暗号化して復号化できる共有秘密鍵を使用することです。 Webブラウザーは秘密鍵を生成し、信頼できる公開鍵を使用してそれを暗号化してから、それをWebサーバーに送信します。 Webサーバーが本物である場合、秘密鍵を正常に復号化できます。
この時点で、WebブラウザーとWebサーバーの両方に共有秘密鍵があり、以降の通信を暗号化および復号化するために使用できます。
さらに読むために：
メッセージの変更を検出するためのハッシュ関数を使用したメッセージの整合性の検証
認証局間の信頼の連鎖
署名された公開鍵を単純に取得してそれを使用して中間者スタイルの攻撃でトラフィックを傍受できない理由は、あなた（または攻撃者）が公開鍵に対応する対応する秘密鍵を持っていないということです。 。
そのため、ブラウザはWebサーバーまたはCAが署名した公開鍵を受け取り、それを使用して独自のシークレットを暗号化し、Webサーバーに送り返します。
Webサーバーには、公開キーで暗号化されたブラウザーから送り返されたデータを復号化するために必要な対応する秘密キーがありますが、攻撃者はそれを行わないため、トラフィックを復号化できません。
結局のところ、2012年にこの質問をしましたが、2015年には実際にこれを可能にする攻撃があります。実装によっては、クライアントがこの攻撃に対して脆弱になる可能性があり、攻撃者、MiTMが必要な署名付き証明書を偽装できる可能性があります。
https://www.smacktls.com/ は、クライアントでのSSLステートマシンの実装が不適切なために、これがどのように機能するかを詳しく説明しています。
検証済み証明書のCA証明書（公開鍵）がすでにブラウザーに含まれており、シナリオでSSL警告が生成されること。
SSHに沿って何かについて話している場合でも、公開鍵を受け入れる必要があります。別の安全なチャネルを介してそのキーが正しいことを確認しない場合、MITMを取得するのはあなた自身の責任です。