TLS 握手：伺服器身份驗證或僅伺服器的證書身份驗證？
我很難理解客戶端在 TLS 握手中真正驗證伺服器的方式（在使用 RSA 密鑰交換的情況下）。
當 Client 收到 Server 的 Certificate 並使用 CA root public key 進行驗證時，我完全理解此時，如果驗證通過，Client 可以認為收到的 Certificate 是有效且真實的
但是如果Client成功檢查了Server的證書，那麼怎麼可能認為Server已經被Client認證了，而此時沒有用Server的私鑰簽名的消息被發送給Client並被Client驗證呢？入侵者不能擁有並將真實伺服器的證書發送給客戶端嗎？
- 注意：我同意如果伺服器不是真實的，因此不擁有真正的伺服器私鑰，它將無法解密客戶端發送的預主密鑰，但這表現為間接/隱式身份驗證，而不是顯式認證
更一般地說（在 TLS 的情況下），談論“通過證書進行身份驗證”（假設基於通過 CA 根公鑰的證書驗證）而不是通過數字簽名進行身份驗證是否正確？
但是如果Client成功檢查了Server的證書，那麼怎麼可能認為Server已經被Client認證了，而此時沒有用Server的私鑰簽名的消息被發送給Client並被Client驗證呢？
如果僅將密鑰交換視為 RFC 所說的那樣，那麼是的，具有正確證書的攻擊者可以破壞此密鑰交換。
然而，這不是 TLS 在實踐中的工作方式。在實踐中，您永遠不會在
ClientKeyExchange消息之後停止，因為您已經建立了連接以實際做某事。這就是為什麼大多數形式分析都ChangeCipherSpec將Finished消息視為其證明的密鑰交換的一部分。重要的是伺服器在完成密鑰交換**後成功驗證，而不是在協議中的某個“隨機選擇”點。
通過驗證包含所有先前（握手）消息上的 MAC的
Finished消息，交換結果是安全的並且經過了正確的身份驗證。因為假伺服器無法解密pre-master secret，因此無法計算master secret，他無法計算必要的 MAC，客戶端將響應fatal_alert，從而終止連接。我不知道 TLS 的設計者為什麼選擇這種“通過後門”身份驗證方法，但我只能猜測他們想避免伺服器的另一個計算密集型基於私鑰的操作。
TL;DR：該
finished消息為您提供身份驗證，其 MAC 僅對私鑰持有者可用。談論“通過證書進行身份驗證”（假設基於通過 CA 根公鑰進行證書驗證）而不是通過數字簽名進行身份驗證是否正確？
您永遠不會僅通過出示證書進行身份驗證。您可以
這樣做 的唯一情況是使用包含密鑰文件的安全令牌來訪問某些物理上受限的設施，在這些設施中，令牌永遠不會真正插入真實的電腦（除了新的文件分配）。在基於 Internet 的場景中，您永遠不會這樣做，因為每個竊聽者都可以冒充證書的所有者，從而使其完全無用。
TLS 的作用（可能是您的問題的意思）是基於加密/基於證書的身份驗證。這基本上是某種挑戰-響應協議，您向某方發送一個隨機隨機數和一個非對稱加密密鑰，並期望隨機數上的 MAC 使用該密鑰作為響應。可以做到這一點，但這相當“濫用”加密來做它不打算做的事情，因為我們有專門的結構：數字簽名。
因此，通常設計師寧願使用數字簽名和加密（/解密）（甚至更好的 DH），因為今天執行這兩種操作非常便宜，而您可能需要使用基於加密的方法非常受限設備，其中只有一種此類操作是“允許的”/可行的，或者實際上無法執行簽名（通過填充，相當不尋常）。
TL;DR：僅基於證書的身份驗證是不好的，並且僅在物理訪問限制場景中可行，否則您可以使用加密進行質詢-響應，但應該更喜歡簽名。