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