互聯網的通信安全，建立在SSL/TLS協議之上。
本文簡要介紹SSL/TLS協議的運行機制。文章的重點是設計思想和運行過程，不涉及具體的實現細節。如果想了解這方面的內容，請參閱RFC文檔。
一、作用
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文傳播，帶來了三大風險。
（1）竊聽風險（eavesdropping）：第三方可以獲知通信內容。
（2）篡改風險（tampering）：第三方可以修改通信內容。
（3）冒充風險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協議是為了解決這三大風險而設計的，希望達到：
（1） 所有信息都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
互聯網是開放環境，通信雙方都是未知身份，這為協議的設計帶來了很大的難度。而且，協議還必須能夠經受所有匪夷所思的攻擊，這使得SSL/TLS協議變得異常復雜。
二、歷史
互聯網加密通信協議的歷史，幾乎與互聯網一樣長。
1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布。
1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規模應用。
1999年，互聯網標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS1.0版。
2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經實現了TLS 1.2的支持。
TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
三、基本的運行過程
SSL/TLS協議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。
但是，這里有兩個問題。
（1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
（2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
因此，SSL/TLS協議的基本過程是這樣的：
（1） 客戶端向服務器端索要并驗證公鑰。
（2） 雙方協商生成"對話密鑰"。
（3） 雙方采用"對話密鑰"進行加密通信。
上面過程的前兩步，又稱為"握手階段"（handshake）。
四、握手階段的詳細過程
"握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。
4.1 客戶端發出請求（ClientHello）
首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求。
在這一步，客戶端主要向服務器提供以下信息。
（1） 支持的協議版本，比如TLS 1.0版。
（2） 一個客戶端生成的隨機數，稍后用于生成"對話密鑰"。
（3） 支持的加密方法，比如RSA公鑰加密。
（4） 支持的壓縮方法。
這里需要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什么通常一臺服務器只能有一張數字證書的原因。
對于虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
4.2 服務器回應（SeverHello）
服務器收到客戶端請求后，向客戶端發出回應，這叫做SeverHello。服務器的回應包含以下內容。
（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
（2） 一個服務器生成的隨機數，稍后用于生成"對話密鑰"。
（3） 確認使用的加密方法，比如RSA公鑰加密。
（4） 服務器證書。
除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
4.3 客戶端回應
客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。
如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發送下面三項信息。
（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。
至于為什么一定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master
secret就有可能被猜出來，那么僅適用pre master
secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master
secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"
此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
4.4 服務器的最后回應
服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發送下面信息。
（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。
至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。
五、參考鏈接
MicroSoft TechNet,SSL/TLS in Detail
Jeff Moser,The First Few Milliseconds of an HTTPS Connection
Wikipedia,Transport Layer Security
StackExchange,How does SSL work?
（完）
留言（81條）
west說：
好文。全面而易懂
李狗蛋說：
壞蛋總不放過任何一絲做惡的機會,太多不要臉的運營商在鏈路劫持強插廣告,直接修改用戶的HTTP數據包,再就是NSA之流肆無忌憚的竊聽
發現一個HTTPS有意思的地方,只要53端口數據被轉發,不管域名對應的DNS解析IP是不是域名真實IP,只要最后都是53端口轉發到真實IP之上,就不會彈HTTPS證書錯誤
比如https://a.com對應 ipa 不通
那么劫持DNS解析https://a.com到 ipb上 (ipb是通的)
只要在ipb上設置 ipb:53轉發到 ipa:53
這樣訪問https://a.com就通了,而且沒證書錯誤
Niclau說：
啟用Server Name Indication擴展后，第一步客戶端發送請求，同時明文發送域名到server?
古明地戀說：
您好，我有一個疑問。
第一步是用服務器公鑰加密的。而服務器公鑰包含在證書中。但是如果入侵者獲取到服務器證書，并用于解密之后的key，再用key來解密通信內容，這樣怎么防范？
阮老師寫的文章都是鞭辟入里啊，一般是站在那些角度去闡述一個觀點或者描述一個事物呢？
harchiko說：
Smart !智慧的發明!!
魂魄妖夢說：
引用古明地戀的發言：
您好，我有一個疑問。
第一步是用服務器公鑰加密的。而服務器公鑰包含在證書中。但是如果入侵者獲取到服務器證書，并用于解密之后的key，再用key來解密通信內容，這樣怎么防范？
服務器證書只包含公鑰，無法解密key。解密需要用私鑰。
私鑰一般放在server端。
如果能拿到私鑰，基本上可以肯定被入侵了。
這時候獲取私鑰都不算個事了你說是不。
lucas說：
阮兄的文章非常值得一讀，簡潔又能把事情的來龍去脈講的清清楚楚的，不簡單。
CJey說：
引用Niclau的發言：
啟用Server Name Indication擴展后，第一步客戶端發送請求，同時明文發送域名到server?
對的, 確實是明文, 否則服務端無法確定向客戶端推送哪張證書
而且, 也沒法使用密文, 因為密鑰尚未協商好
再者, 使用密文也沒有意義, 篡改域名只能影響服務端返回的證書, 而所有的證書本來就都是公開的
CJey說：
@李狗蛋：
不太能理解你想表達的意思
不過, SSL/TLS協議并不關心雙方的IP, DNS劫持是無法攻擊SSL/TLS的
所以, 我覺得你的這個測試結果另有原因
onion說：
其實，看阮兄的博客主要目的就是學習阮兄的總結與再表達能力，對于這篇來說，真的不懂，但是感覺看得很舒服，層次清晰，用語準確，贊！
masstensor說：
文章寫的淺顯易懂，看了很有收獲。不過，需要說明的是，使用PKI機制進行密鑰交換只是TLS規范的一種實現形式，還有其他的形式可以用于密鑰交換，比如SRP和PSK協議。
twd2說：
引用CJey的發言：
對的, 確實是明文, 否則服務端無法確定向客戶端推送哪張證書
而且, 也沒法使用密文, 因為密鑰尚未協商好
再者, 使用密文也沒有意義, 篡改域名只能影響服務端返回的證書, 而所有的證書本來就都是公開的
如果有中間人通過判斷域名，來決定是否阻斷連接怎么辦呢
nuooo說：
請考慮介紹下常用于SPDY的HTTPS falst start握手，它比標準的握手少一個“server finished"的步驟
sunny說：
好文章。
點虎說：
感謝！
沒有微信公眾號？
hyh說：
文中的 SeverHello 是不是應該是 ServerHello?
GlacJAY說：
只有第一次的握手過程是明文的，之后的自動重協商通信是用上一次的密鑰來加密的。
yd說：
您好，我有一個疑問。
第一步，服務器端的響應內容包含證明服務器自身的證書，客戶端得到證書后進行有效性驗證，
請問客戶端是如何進行驗證的？根據哪些信息驗證的？
dcb110說：
查了好多文章，終于在這里把整個握手流程以及中間一些疑問搞清楚了，現在再去看那些代碼，清楚了很多，感謝博主。
Bravluna說：
引用yd的發言：
您好，我有一個疑問。
第一步，服務器端的響應內容包含證明服務器自身的證書，客戶端得到證書后進行有效性驗證，
請問客戶端是如何進行驗證的？根據哪些信息驗證的？
證書里是服務器的公鑰和身份信息，這些是經過證書頒發機構即CA公證過的，客戶端拿到后去CA驗證，看這個公鑰是不是服務器的，若不是說明證書是偽造的，當然如果證書經過數字簽名證書就不可能被偽造了
ZeroLing說：
來支持一下阮老師寫的東西
Charles說：
看來說清楚這個東西，還是太過難了一點，這個文章也太過概述了，感覺很多關鍵點沒有說清楚啊，看得我好累。不過還是感謝阮老師，已經讓我省了不少時間了。
heliar說：
引用yd的發言：
您好，我有一個疑問。
第一步，服務器端的響應內容包含證明服務器自身的證書，客戶端得到證書后進行有效性驗證，
請問客戶端是如何進行驗證的？根據哪些信息驗證的？
這里還有一個信任鏈的問題，一般都是有一家第三方的根證書簽名機構辦法證書，我們相信這個第三方機構，從而相信它頒發的證書，當然也有根證書授權下一層的證書頒發機構，然后由這個機構給網站服務器做驗證的情況
Pingia說：
我感覺4。3部分 的（1）步和（2）(3)兩步中間還有些步驟可以注明清楚點。
事實上服務端和客戶端在擁有pms后計算出來的密鑰并不是會話密鑰，而是一個中間密鑰，最終的會話密鑰是通過這個中間密鑰計算出來的。至于這個計算方法，我也不清楚是什么？有知道的朋友望告知。
還有這一部分最后一句：
此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。
我感覺客戶端發送證書應該是在這一步驟之前。
王正一說：
通俗易懂，太贊了
freenet說：
講得非常好！學習了...
ikong說：
需要注意的是，"握手階段"的所有通信都是明文的。
這句話不對吧？pre master key應該是客戶端用服務端公鑰加密之后再發送給服務端的，這不能算明文吧？
興杰說：
提問一下，
握手的第3步，pre-master key 如果被攔截，是否可以被偽造或篡改？
因為只使用服務器的公鑰加密。
feix說：
關于 至于為什么一定要用三個隨機數，來生成"會話密鑰" 這個地方，其實還有一點：pre-master key
用服務器的公鑰加密，可以防止第三方冒充服務器，因為任何人都可以獲取已經公開的服務器公鑰與客戶段進行通信。想要獲得 pre-master key
明文只有利用服務器的私鑰進行解密，所以這里進行了服務器的身份驗證，也防止了中間人攻擊。
另外，當服務器需要驗證客戶端時，客戶端在發送 pre-master key 之前需要發送客戶端公鑰到服務器，可以選擇對 pre-master key 用客戶端的私鑰簽名然后再用服務器公鑰加密，則服務器收到 pre-master key 同時對客戶端進行了身份驗證。
好文章，通俗易懂的介紹SSL，本文將引用的中國證書CHINASSL博客，謝謝
lp說：
有個問題，握手時是明文通信，那就會被截獲到公鑰、三個隨機數，這樣對話密鑰不久可以知道了？那后面的對話加密不就會被解密？
goodboy1983說：
如果有個proxy, 先和客戶端建立連接（不下發服務器證書，也不要求客戶端上報證書），再和SP建立連接。
對服務器下發的證書默認接受。 相當于 CLIENT-PROXY之間是互相不認證證書，PROXY-WEB SERVER之間是驗證服務器證書。
是否有安全隱患？
nowlater說：
@goodboy1983: 應該不會有安全隱患吧，pre-master
key是用服務器端公鑰加密的，client-proxy無法解密，不能獲取到pre-master
key。在安全要求更高的金融領域，服務器端會認證客戶端，比如銀行會給客戶發u盾。這就更安全了。
哈哈說：
服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的"會話密鑰"。? 這個會話密鑰怎么計算的呢？
youyingyang說：
阮一峰同志是一座寶庫
4年之前就開始看您的博客，但是基本只看人文社科類和科普性質的，視野很開闊，寫的很棒。
最近隨著自己的興趣變化，開始學習編程，沒想到搜“RESTful架構”，第一篇文章就是您的，寫的太好了，明白如水！
高手有很多，但是樂意長時間堅持分享，而且做科普做的這么好的高手太少了！
感謝！
hilojack說：
引用CJey的發言：
對的, 確實是明文, 否則服務端無法確定向客戶端推送哪張證書
而且, 也沒法使用密文, 因為密鑰尚未協商好
再者, 使用密文也沒有意義, 篡改域名只能影響服務端返回的證書, 而所有的證書本來就都是公開的
將域名加密還是有意義的，比如GFW 或者 Hacker 等想知道你請求了哪些網站，醬紫
hilojack說：
關于TLS/SSL 四次握手的一個疑問。
在協商會話密鑰的階段：
客戶端的請求是用服務端的公鑰加密的，第三方截獲后是沒有辦法解密的；
服務端返回的請求是用服務端的私鑰加密的，第三方截獲后可以通過公鑰解密的。
這引發我的疑問，在最后第4步，服務端返回的會話密鑰(Session Key) 是用服務端的私鑰加密的，那第三方不就可以解密出這個Session Key 嗎？有了這個Session Key 后不就可以破譯出通信數據嗎？
Zhaodawei說：
引用hilojack的發言：
關于TLS/SSL 四次握手的一個疑問。
在協商會話密鑰的階段：
客戶端的請求是用服務端的公鑰加密的，第三方截獲后是沒有辦法解密的；
服務端返回的請求是用服務端的私鑰加密的，第三方截獲后可以通過公鑰解密的。
這引發我的疑問，在最后第4步，服務端返回的會話密鑰(Session Key) 是用服務端的私鑰加密的，那第三方不就可以解密出這個Session Key 嗎？有了這個Session Key 后不就可以破譯出通信數據嗎？
第四步服務器不會返回會話密鑰！！！會話密鑰是客戶端和服務端各自通過三個隨機數和一個密鑰導出器最終導出的
zhaodawei說：
文中說“三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰”，密鑰導出器是什么？服務的公鑰嗎？
zhaodawei說：
引用lp的發言：
有個問題，握手時是明文通信，那就會被截獲到公鑰、三個隨機數，這樣對話密鑰不久可以知道了？那后面的對話加密不就會被解密？
第三個隨機數是公鑰加密的，只有服務的私鑰才能解密。
shun.aaron說：
請教一個問題：
如果網絡中有一臺設備，這個設備具有了https服務器的證書和私鑰，是不是意味著：這個設備能夠通過服務器的私鑰來計算出第三個隨機數，然后根據相關算法來計算出服務器和client之間的通信秘鑰？
這樣就代表了服務器和client之間的通信內容不在是私密性的了？
passerbywhu說：
引用shun.aaron的發言：
請教一個問題：
如果網絡中有一臺設備，這個設備具有了https服務器的證書和私鑰，是不是意味著：這個設備能夠通過服務器的私鑰來計算出第三個隨機數，然后根據相關算法來計算出服務器和client之間的通信秘鑰？
這樣就代表了服務器和client之間的通信內容不在是私密性的了？
HTTPS服務器的私鑰你都有了還想怎樣。。。-_-
danieldong說：
如果key exchange算法是ECDH，那么就不是索要公鑰了，也就是說，不采用非對稱加密來產生master-key
撒啊說：
請教一下，為什么在session ticket生效的情況下，依然需要交互隨機數？? session ticket生效有，已經不用重新生成對稱密鑰了。
jedihy說：
阮老師這篇博客說的不好。前后都有矛盾，有些地方不明確，容易誤導。
如果認定握手是完全明文，按阮老師的說法，那中間人直接就可以攻擊了，因為他知道所有信息。關鍵在于隨機數的傳遞這里，會不會用Server的公鑰加密。這一點沒有強調的話，這篇博客有什么意義，通信安全性的關鍵在這里。正是用了中間人解不出的信息（需要私鑰），所以安全才得到的保障，而并不是因為你用了多少個隨機數。不加密的話，你來回發一萬次隨機數中間人也能夠看到。后面的對稱密鑰通信過程就是扯淡了。
大山說：
個人覺得隨機數應該最后是這樣的結果:3個隨機數以某種組合并結合加密算法，客戶端和服務器端各自都算出來了動態的私鑰和公鑰了，這個時候的通信不再是以服務器最早的公鑰和私鑰為準，而是在兩方都知道公鑰私鑰的情況下通信，服務器端以私鑰加密，客戶端以公鑰解密，客戶端以公鑰加密，服務器端以私鑰解密，至于服務器最原始的公鑰和私鑰，就是為了保證隨機數的安全，不知道這樣對不對
少時誦詩書說：
引用大山的發言：
個人覺得隨機數應該最后是這樣的結果:3個隨機數以某種組合并結合加密算法，客戶端和服務器端各自都算出來了動態的私鑰和公鑰了，這個時候的通信不再是以服務器最早的公鑰和私鑰為準，而是在兩方都知道公鑰私鑰的情況下通信，服務器端以私鑰加密，客戶端以公鑰解密，客戶端以公鑰加密，服務器端以私鑰解密，至于服務器最原始的公鑰和私鑰，就是為了保證隨機數的安全，不知道這樣對不對
不對，握手完成后就是對稱加密，怎么還會有公鑰私鑰這種非對稱加密方法
小白說：
大致是看明白了，誰能提供一個pcap包 詳細分析下就更加好了。我自己抓了包，都是加密的，看不明白呢
YorkYang說：
一個證書可不可以供兩個（不同IP）服務器使用？ 文中講的 "真實IP" 的校驗依據是否為發包的IP？
gaodi說：
求助各位大神，現在已知Server端私鑰，用wireshark截取握手階段client和server的random和加密了的pre_master_secret,如何具體解析出https中，http報文內容，最好能有C語言實現的函數和代碼，多謝。
王松說：
引用onion的發言：
其實，看阮兄的博客主要目的就是學習阮兄的總結與再表達能力，對于這篇來說，真的不懂，但是感覺看得很舒服，層次清晰，用語準確，贊！
贊，突然發現，寫技術博客，排版很重要！
Pingia說：
引用masstensor的發言：
文章寫的淺顯易懂，看了很有收獲。不過，需要說明的是，使用PKI機制進行密鑰交換只是TLS規范的一種實現形式，還有其他的形式可以用于密鑰交換，比如SRP和PSK協議。
是這樣的，我也想這么一問。
Pingia說：
引用興杰的發言：
提問一下，
握手的第3步，pre-master key 如果被攔截，是否可以被偽造或篡改？
因為只使用服務器的公鑰加密。
后面的步驟需要解密這個key，如果被篡改，將不能解密，之后的步驟都不能繼續下去了，然后就沒有然后了。
Pingia說：
引用lp的發言：
有個問題，握手時是明文通信，那就會被截獲到公鑰、三個隨機數，這樣對話密鑰不久可以知道了？那后面的對話加密不就會被解密？
公鑰是公開的，本身就無所謂截獲不截獲，但是公鑰加密的需要配套私鑰來解密的。而私鑰確是保密的。第一個隨機數是通過公鑰加密傳輸，需要私鑰才能解密的，第二個客戶端產生的隨機數的確是明文傳遞的，第三個隨機數是在服務端本身產生的，并不傳輸。有兩個隨機數參數你無法截獲，你怎么計算得到正確的對話密鑰？
Pingia說：
引用hilojack的發言：
將域名加密還是有意義的，比如GFW 或者 Hacker 等想知道你請求了哪些網站，醬紫
個人覺得這個 不在ssl協議要解決的范疇之內。
Pingia說：
引用Pingia的發言：
公鑰是公開的，本身就無所謂截獲不截獲，但是公鑰加密的需要配套私鑰來解密的。而私鑰確是保密的。
第一個隨機數是通過公鑰加密傳輸，需要私鑰才能解密的，第二個客戶端產生的隨機數的確是明文傳遞的，第三個隨機數是在服務端本身產生的，并不傳輸。
有兩個隨機數參數你無法截獲，你怎么計算得到正確的對話密鑰？
說錯了，第三個也傳輸給客戶端的，只是第一個隨機數需要私鑰解開，這可以進行防范。
Pingia說：
引用zhaodawei的發言：
文中說“三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰”，密鑰導出器是什么？服務的公鑰嗎？
我也想問這個，說也沒說清楚。
Pingia說：
引用YorkYang的發言：
一個證書可不可以供兩個（不同IP）服務器使用？ 文中講的 "真實IP" 的校驗依據是否為發包的IP？
可以的，證書只和域名綁定。只要你把這些Ip的服務器綁定到一個域名下就可以。但配置的時候你必須使用同一個服務端根證書。
bencanber說：
引用古明地戀的發言：
您好，我有一個疑問。
第一步是用服務器公鑰加密的。而服務器公鑰包含在證書中。但是如果入侵者獲取到服務器證書，并用于解密之后的key，再用key來解密通信內容，這樣怎么防范？
解密只能使用服務器的私鑰解密，而證書中只包含服務器的公鑰，所以不會被破解
pengfei說：
我有個疑問，比如我控制著代理服務器
我知道? 協商協議版本都是1.0? 我也知道三次隨機數第一次客戶給服務器的 10，第二次服務器給客戶端的 1050 第三次客戶端給服務器的119，然后還知道他們協商的加密算法 RSA.? 那我就可以自己按照加密算法RSA，用我看到的三個隨機數生成一個秘鑰了，這樣我不是還是可以解開你的通信內容嗎？
"握手階段"的所有通信都是明文的。
對于這個，不知我的理解可否正確？
1.客戶端->服務器：隨機數，支持的加密方法
2.服務器->客戶端：隨機數，確定加密方法
3.客戶端->服務器：隨機數（公鑰加密）
這樣，第一第二的隨機數雖然可能被其他人截取，但是由于第三個隨機數是通過公鑰加密的，所以，只有對應的私鑰可以解密，是安全的。
所以通過這三個隨機數以及第二步確定的對稱加密的方法，客戶端以及服務端各自生成對話密鑰。之后就通過這個對話密鑰來進行通信
@pengfei：
第三個隨機數是通過公鑰加密的。
strangerC說：
除了“如何保證公鑰不被篡改？”和“公鑰加密計算量太大，如何減少耗用的時間？”這兩個問題，還有一個問題：如果都采用公鑰加密，那么客戶端勢必也要知道私鑰，才能對服務器端返回的信息。
gitjoke說：
服務器的證書如果被中途運營商替換了，怎么辦？
我猜的說：
引用gitjoke的發言：
服務器的證書如果被中途運營商替換了，怎么辦？
電腦中需要一張可信任的第三方機構的根證書，
來驗證服務器發來的證書。
當然，服務器自己得去第三方機構驗證，把驗證信息放入自己的證書中。
xcw說：
看不大懂，想哪個大神給我講解下，跪求！
zhq說：
會話密鑰是每次會話隨機產生的嗎，怎么存儲的
mll說：
客戶端驗證證書這個環節，沒有理解是怎么保證安全的。
如果有個中間人，把自己的證書代替了服務器的證書，返回給客戶端。
然后在客戶端去認證證書的時候，攔截并直接返回證書OK，那么客戶端就被攻擊了啊。
客戶端驗證證書的通信，本質上又需要一個加密通信，這就遞歸了。
cmuscler說：
總體上看明白了，不過有一個疑問請教大家。
使用三個隨機數是為了避免客戶端生成的一致的偽隨機數。那么問題就出現了，假設這個客戶端生成的隨機數都是一個，那么第一次和第三次的客戶端向服務端發送的隨機數就能被掌握，而服務端向客戶端發送的隨機數是明文傳輸，那么三個隨機數不久都被掌握了么？
避免這個情況實際上客戶端不也可以給服務端一個公鑰用于加密，然后客戶端使用自己的私鑰解密，這樣就能保證第二個隨機數的安全么？可是事實上并沒有這么做，這個是為什么呢？
引用nuooo的發言：
請考慮介紹下常用于SPDY的HTTPS falst start握手，它比標準的握手少一個“server finished"的步驟
經過debug測試，發現SPDY+HTTPS false start握手確實比標準的SSL/TLS少一次握手，最后一次服務器到客戶端的握手是沒有的，第一次Finished后就可以傳輸數據了。
zskm說：
看了阮老師的博文和底下的評論，基本八九不離十了，3q all！
二手玫瑰說：
http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
這篇文章中有解釋，第三個隨機數客戶端是用公鑰加密的然后在發送給服務端，服務端用私鑰解密獲取隨機數。客戶端和服務端用約定加密方法使用三個隨機數生成對話密鑰
學習一個說：
引用pengfei的發言：
我有個疑問，比如我控制著代理服務器
我知道協商協議版本都是1.0 我也知道三次隨機數第一次客戶給服務器的 10，第二次服務器給客戶端的 1050 第三次客戶端給服務器的119，然后還知道他們協商的加密算法 RSA.那我就可以自己按照加密算法RSA，用我看到的三個隨機數生成一個秘鑰了，這樣我不是還是可以解開你的通信內容嗎？
如果真的知道三個隨機值,的確是這樣.但是作為代理服務器,你只能看到明文的第一,第二個隨機數,第三個隨機數是用服務器的公鑰加密的.只有服務器用私鑰解密后才能看到,你一個代理服務器是看不到的.
理論上說：
引用cmuscler的發言：
總體上看明白了，不過有一個疑問請教大家。
使用三個隨機數是為了避免客戶端生成的一致的偽隨機數。那么問題就出現了，假設這個客戶端生成的隨機數都是一個，那么第一次和第三次的客戶端向服務端發送的隨機數就能被掌握，而服務端向客戶端發送的隨機數是明文傳輸，那么三個隨機數不久都被掌握了么？
避免這個情況實際上客戶端不也可以給服務端一個公鑰用于加密，然后客戶端使用自己的私鑰解密，這樣就能保證第二個隨機數的安全么？可是事實上并沒有這么做，這個是為什么呢？
沒必要.
因為即使第一個和第三個都是一樣的,別人也不知道啊.因為第三個值是加密后的.明文來看,肯定是不一樣的.
振宇說：
引用cmuscler的發言：
總體上看明白了，不過有一個疑問請教大家。
使用三個隨機數是為了避免客戶端生成的一致的偽隨機數。那么問題就出現了，假設這個客戶端生成的隨機數都是一個，那么第一次和第三次的客戶端向服務端發送的隨機數就能被掌握，而服務端向客戶端發送的隨機數是明文傳輸，那么三個隨機數不久都被掌握了么？
避免這個情況實際上客戶端不也可以給服務端一個公鑰用于加密，然后客戶端使用自己的私鑰解密，這樣就能保證第二個隨機數的安全么？可是事實上并沒有這么做，這個是為什么呢？
個人看法不一定對哈：
1，姑且不論重復的概率，第一個數和第三個數一不一樣沒有太大的影響，因為撞庫的人，不會采用我門直白的人工方式去撞，從算法的角度來說能不能撞出來的概率是差不多的。
2，客戶端的私匙太容易獲取了，所以沒有什么大的影響。。
zhangdong說：
引用hyh的發言：
文中的 SeverHello 是不是應該是 ServerHello?
谷歌了一下，應該是ServerHello。不過搜SeverHello搜到好多博客，極有可能就是轉載這里的……
xiaolinzi說：
我有個疑問 ：
第一次握手和第二次握手是明文的 ，? 如果我把第一次傳的隨機數，第二次傳的隨機數、證書等都截獲了? 。? 這時我只需要模擬后面的操作就可以獲取相關的信息不是么?
雪山飛狐說：
最后協商出來一個對稱加密的密鑰S，雙方都用這個密鑰S通信，既然是對稱加密，那些壞人要是直接破解這個密鑰S怎么辦呢？
善良超哥哥說：
引用雪山飛狐的發言：
最后協商出來一個對稱加密的密鑰S，雙方都用這個密鑰S通信，既然是對稱加密，那些壞人要是直接破解這個密鑰S怎么辦呢？
這個秘鑰雖然是對此加密，但是臨時的，每次會話都重新生成。不容易破解，等你破解出來，人家早結束通信了。而且一般的破解方法都要基于之前大量通信內容的統計規律，每次臨時生成，就沒有大量數據給你統計了。
Scott說：
阮老師，我在百度上搜索到了您這篇文章，受益匪淺，現在我手頭遇到了點問題。我們有臺郵件系統開啟了TLS，最近發現來自某個域的郵件不能接收，而其他域發來的郵件是可以正常接收的，于是我進行抓包查看，信息如下：
Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
這是第三次握手的報錯，clienthello和serverhello都沒有報錯，卻卡在了這里出現了致命錯誤，我排查了很長時間一直沒有找到問題出在哪里，能不能幫忙判斷一下，出現這種故障，一般是哪里出了問題？謝謝。
