攻撃者はSSLハンドシェイク中に証明書の公開鍵を変更できますか
通信は、SSLハンドシェイク中に暗号化されません。攻撃者がサーバーとクライアントの間の中間者攻撃を行って証明書を取得し、証明書の公開鍵を変更してクライアントに送信する場合、デジタル署名は同じであり、公開鍵を除くすべてのプロパティは同じです。
では、ブラウザはどのようにして違いを理解できるでしょうか？ブラウザが検証すると、攻撃者は自分のキーペアを使用でき、サーバーの秘密キーは必要ありません。
...証明書の公開鍵を変更して、クライアントに送信します。 デジタル署名は同じ、公開鍵を除くすべてのプロパティは同じです。では、ブラウザはどのように違いを理解できますか？
ブラウザは、証明書の署名が証明書に適合することを確認します。公開鍵が署名に含まれ、公開鍵が変更されるため、署名は証明書に適合しなくなります。したがって、検証は失敗します。
TLSネゴシエーション（「Finished」メッセージ）の最後に、クライアントとサーバーは、これまでに行った会話全体のハッシュを取得し、それらを比較します。それが異なる場合-誰かが証明書に対してMitM攻撃を行った場合のように-接続はドロップされます。
引用するには RFC 5246 ：
The Finished message is the first one protected with the just
negotiated algorithms, keys, and secrets. Recipients of Finished
messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
@Mooと@Damonによるコメントに対処するために、終了メッセージは完全なMitM（ " SSL Interception "）攻撃を防止しません。この場合、MitMは直接傍受してプロキシすることができますTCPターゲットの名前に有効な証明書があり、OPによって提案されたように、クライアントとサーバー間のストリームの個別の改ざんを防ぐだけです。
証明書は単独では存在しません。信頼できるためには、証明書は発行者によって署名されている必要があります。これらの発行者は認証局と呼ばれます。各ブラウザー（またはオペレーティングシステム）は、数百の信頼されたCA（ルートCAと呼ばれる）の独自のリストを保持しており、それらは既に認識および信頼しています。また、雇用主または学校が独自のプライベート発行ルートCAを持っている場合があります。証明書がクライアントに知られていない発行者によって署名されている場合、その証明書は信頼できません。
TLSハンドシェイクがプロトコルのFinished部分に到達するずっと前に、サーバーはサーバーHelloメッセージの証明書で公開鍵を送信しました。クライアントは、証明書を取得したらすぐに証明書全体を検証する必要があります。検証には、証明書の有効期限、署名、および発行者の署名と発行証明書の確認が含まれます。発行証明書が既知の信頼された発行者（信頼されたルートCAの内部リストにクライアントが持っている発行者）からのものでない場合、クライアントは接続を拒否する必要があります。
したがって、攻撃者が、クライアントがすでに信頼している機関によって署名されていない別の証明書を置き換えた場合、発行者が信頼できるCAのリストに見つからなかったため、拒否されます。攻撃者が適切な証明書を送信せずに独自のキーを使用しようとすると、クライアントは間違ったキーを使用し、完了メッセージの間に適切に通信しなくなります。
攻撃者がシステムの信頼できるCAのリストに偽のルートCAを追加できた場合、はい、攻撃者は中間者攻撃を実行し、通信を表示する可能性があります。これは多くの場合、すべてのWebトラフィックの検査、ウイルス対策スキャンの実行、マルウェアの防止、シークレットの漏洩の防止、または単に従業員のWebサーフィンの監視を目的とする企業によって意図的に行われます。