SSL/TLS握手过程
1、握手與密鑰協(xié)商過(guò)程
基于RSA握手和密鑰交換的客戶端驗(yàn)證服務(wù)器為示例詳解TLS/SSL握手過(guò)程
?
再看一張手繪時(shí)序圖
(1).client_hello
? ? 客戶端發(fā)起請(qǐng)求,以明文傳輸請(qǐng)求信息,包含版本信息,加密套件候選列表,壓縮算法候選列表,隨機(jī)數(shù),擴(kuò)展字段等信息,相關(guān)信息如下:
? ????支持的最高TSL協(xié)議版本version,從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2,當(dāng)前基本不再使用低于 TLSv1 的版本;
? ????客戶端支持的加密套件 cipher suites 列表, 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合:認(rèn)證算法 Au (身份驗(yàn)證)、密鑰交換算法 KeyExchange(密鑰協(xié)商)、對(duì)稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗(yàn));
? ????支持的壓縮算法 compression methods 列表,用于后續(xù)的信息壓縮傳輸;
? ????隨機(jī)數(shù) random_C,用于后續(xù)的密鑰的生成;
? ????擴(kuò)展字段 extensions,支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等,常見(jiàn)的 SNI 就屬于擴(kuò)展字段,后續(xù)單獨(dú)討論該字段作用。
(2).server_hello+server_certificate+sever_hello_done
? ? ??server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果,包括選擇使用的協(xié)議版本 version,選擇的加密套件 cipher suite,選擇的壓縮算法 compression method、隨機(jī)數(shù) random_S 等,其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商;
? ????server_certificates, 服務(wù)器端配置對(duì)應(yīng)的證書(shū)鏈,用于身份驗(yàn)證與密鑰交換;
? ????server_hello_done,通知客戶端 server_hello 信息發(fā)送結(jié)束;
(3).證書(shū)校驗(yàn)
? ??客戶端驗(yàn)證證書(shū)的合法性,如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信,否則根據(jù)錯(cuò)誤情況不同做出提示和操作,合法性驗(yàn)證包括如下:
? ????[證書(shū)鏈]的可信性 trusted certificate path,方法如前文所述;
? ????證書(shū)是否吊銷 revocation,有兩類方式離線 CRL 與在線 OCSP,不同的客戶端行為會(huì)不同;
? ????有效期 expiry date,證書(shū)是否在有效時(shí)間范圍;
? ????域名 domain,核查證書(shū)域名是否與當(dāng)前的訪問(wèn)域名匹配,匹配規(guī)則后續(xù)分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
? ??(a) client_key_exchange,合法性驗(yàn)證通過(guò)之后,客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master,并用證書(shū)公鑰加密,發(fā)送給服務(wù)器;
? ??(b) 此時(shí)客戶端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息:兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S 與自己計(jì)算產(chǎn)生的 Pre-master,計(jì)算得到協(xié)商密鑰;
? ??enc_key=Fuc(random_C, random_S, Pre-Master)
? ??(c) change_cipher_spec,客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;
? ??(d) encrypted_handshake_message,結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù),采用協(xié)商密鑰 session secret 與算法進(jìn)行加密,然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗(yàn)證;
(5).change_cipher_spec+encrypted_handshake_message
? ??(a) 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù),基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S,計(jì)算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
? ??(b) 計(jì)算之前所有接收信息的 hash 值,然后解密客戶端發(fā)送的 encrypted_handshake_message,驗(yàn)證數(shù)據(jù)和密鑰正確性;
? ??(c) change_cipher_spec, 驗(yàn)證通過(guò)之后,服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;
? ??(d) encrypted_handshake_message, 服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶端;
(6).握手結(jié)束
? ??客戶端計(jì)算所有接收信息的 hash 值,并采用協(xié)商密鑰解密 encrypted_handshake_message,驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰,驗(yàn)證通過(guò)則握手完成;
(7).加密通信
? ??開(kāi)始使用協(xié)商密鑰與算法進(jìn)行加密通信。
注意:
? ??(a) 服務(wù)器也可以要求驗(yàn)證客戶端,即雙向認(rèn)證,可以在過(guò)程2要發(fā)送 client_certificate_request 信息,客戶端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息,證書(shū)的驗(yàn)證方式基本相同,certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù),服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證;
? ??(b) 根據(jù)使用的密鑰交換算法的不同,如 ECC 等,協(xié)商細(xì)節(jié)略有不同,總體相似;
? ??(c) sever key exchange 的作用是 server certificate 沒(méi)有攜帶足夠的信息時(shí),發(fā)送給客戶端以計(jì)算 pre-master,如基于 DH 的證書(shū),公鑰不被證書(shū)中包含,需要單獨(dú)發(fā)送;
? ??(d) change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式,當(dāng)前沒(méi)有深入解析;
? ??(e) alter message 用于指明在握手或通信過(guò)程中的狀態(tài)改變或錯(cuò)誤信息,一般告警信息觸發(fā)條件是連接關(guān)閉,收到不合法的信息,信息解密失敗,用戶取消操作等,收到告警信息之后,通信會(huì)被斷開(kāi)或者由接收方?jīng)Q定是否斷開(kāi)連接。
?
2、會(huì)話緩存握手過(guò)程
? ??為了加快建立握手的速度,減少協(xié)議帶來(lái)的性能降低和資源消耗(具體分析在后文),TLS 協(xié)議有兩類會(huì)話緩存機(jī)制:會(huì)話標(biāo)識(shí) session ID 與會(huì)話記錄 session ticket。
? ??session ID 由服務(wù)器端支持,協(xié)議中的標(biāo)準(zhǔn)字段,因此基本所有服務(wù)器都支持,服務(wù)器端保存會(huì)話ID以及協(xié)商的通信信息,Nginx 中1M 內(nèi)存約可以保存4000個(gè) session ID 機(jī)器相關(guān)信息,占用服務(wù)器資源較多;
? ??session ticket 需要服務(wù)器和客戶端都支持,屬于一個(gè)擴(kuò)展字段,支持范圍約60%(無(wú)可靠統(tǒng)計(jì)與來(lái)源),將協(xié)商的通信信息加密之后發(fā)送給客戶端保存,密鑰只有服務(wù)器知道,占用服務(wù)器資源很少。
? ??二者對(duì)比,主要是保存協(xié)商信息的位置與方式不同,類似與 http 中的 session 與 cookie。
? ??二者都存在的情況下,(nginx 實(shí)現(xiàn))優(yōu)先使用 session_ticket。
? ??握手過(guò)程如下圖:
?
注意:雖然握手過(guò)程有1.5個(gè)來(lái)回,但是最后客戶端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息,因此握手延時(shí)是1*RTT。
(1).會(huì)話標(biāo)識(shí) session ID
? ??(a) 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接,服務(wù)器會(huì)在握手成功后返回 session ID,并保存對(duì)應(yīng)的通信參數(shù)在服務(wù)器中;
? ??(b) 如果客戶端再次需要和該服務(wù)器建立連接,則在 client_hello 中 session ID 中攜帶記錄的信息,發(fā)送給服務(wù)器;
? ??(c) 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄,如果沒(méi)有檢索到貨緩存過(guò)期,則按照正常的握手過(guò)程進(jìn)行;
? ??(d) 如果檢索到對(duì)應(yīng)的緩存記錄,則返回 change_cipher_spec 與 encrypted_handshake_message 信息,兩個(gè)信息作用類似,encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master_secret的hash 值;
? ??(f) 如果客戶端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù),則客戶端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息;
? ??(g) 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò),則握手建立成功,開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。
(2).會(huì)話記錄 session ticket
? ??(a) 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接,服務(wù)器會(huì)在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息,客戶端保存;
? ??(b) 如果客戶端再次需要和該服務(wù)器建立連接,則在 client_hello 中擴(kuò)展字段 session_ticket 中攜帶加密信息,一起發(fā)送給服務(wù)器;
? ??(c) 服務(wù)器解密 sesssion_ticket 數(shù)據(jù),如果能夠解密失敗,則按照正常的握手過(guò)程進(jìn)行;
? ??(d) 如果解密成功,則返回 change_cipher_spec 與 encrypted_handshake_message 信息,兩個(gè)信息作用與 session ID 中類似;
? ??(f)如果客戶端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù),則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息;
? ??(g) 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò),則握手建立成功,開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。
?
3、重建連接
? ??重建連接 renegotiation 即放棄正在使用的 TLS 連接,從新進(jìn)行身份認(rèn)證和密鑰協(xié)商的過(guò)程,特點(diǎn)是不需要斷開(kāi)當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證、更新密鑰或算法,因此服務(wù)器端存儲(chǔ)和緩存的信息都可以保持??蛻舳撕头?wù)器都能夠發(fā)起重建連接的過(guò)程,當(dāng)前 windows 2000 & XP 與 SSL 2.0不支持。
(1).服務(wù)器重建連接
?
? ??服務(wù)器端重建連接一般情況是客戶端訪問(wèn)受保護(hù)的數(shù)據(jù)時(shí)發(fā)生?;具^(guò)程如下:
? ??(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
? ??(b) 客戶端訪問(wèn)受保護(hù)的信息;
? ??(c) 服務(wù)器端返回 hello_request 信息;
? ??(d) 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息,開(kāi)始重新建立連接。
(2).客戶端重建連接
客戶端重建連接一般是為了更新通信密鑰。
? ??(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
? ??(b) 客戶端需要更新密鑰,主動(dòng)發(fā)出 client_hello 信息;
? ??(c) 服務(wù)器端收到 client_hello 信息之后無(wú)法立即識(shí)別出該信息非應(yīng)用數(shù)據(jù),因此會(huì)提交給下一步處理,處理完之后會(huì)返回通知該信息為要求重建連接;
? ??(d) 在確定重建連接之前,服務(wù)器不會(huì)立即停止向客戶端發(fā)送數(shù)據(jù),可能恰好同時(shí)或有緩存數(shù)據(jù)需要發(fā)送給客戶端,但是客戶端不會(huì)再發(fā)送任何信息給服務(wù)器;
? ??(e) 服務(wù)器識(shí)別出重建連接請(qǐng)求之后,發(fā)送 server_hello 信息至客戶端;
? ??(f) 客戶端也同樣無(wú)法立即判斷出該信息非應(yīng)用數(shù)據(jù),同樣提交給下一步處理,處理之后會(huì)返回通知該信息為要求重建連接;
? ??(g) 客戶端和服務(wù)器開(kāi)始新的重建連接的過(guò)程。
4、密鑰計(jì)算
上節(jié)提到了兩個(gè)明文傳輸?shù)碾S機(jī)數(shù) random_C 和 random_S 與通過(guò)加密在服務(wù)器和客戶端之間交換的 Pre-master,三個(gè)參數(shù)作為密鑰協(xié)商的基礎(chǔ)。本節(jié)討論說(shuō)明密鑰協(xié)商的基本計(jì)算過(guò)程以及通信過(guò)程中的密鑰使用。
(1).計(jì)算 Key
涉及參數(shù) random client 和 random server, Pre-master, Master secret, key material, 計(jì)算密鑰時(shí),服務(wù)器和客戶端都具有這些基本信息,交換方式在上節(jié)中有說(shuō)明,計(jì)算流程如下:
?
? ??(a) 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master;
? ??(b) Pre-master 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò) PseudoRandomFunction(PRF)計(jì)算得到 Master secret;
? ??(c) Master secret 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò)迭代計(jì)算得到 Key material;
以下為一些重要的記錄,可以解決部分愛(ài)深入研究朋友的疑惑,copy的材料,分享給大家:
? ??(a) PreMaster secret 前兩個(gè)字節(jié)是 TLS 的版本號(hào),這是一個(gè)比較重要的用來(lái)核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào),因?yàn)樵?Client Hello 階段,客戶端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的 SSL/TLS 的版本號(hào)給服務(wù)端,而且是使用明文傳送的,如果握手的數(shù)據(jù)包被破解之后,攻擊者很有可能串改數(shù)據(jù)包,選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端,從而對(duì)數(shù)據(jù)進(jìn)行破解。所以,服務(wù)端需要對(duì)密文中解密出來(lái)對(duì)的 PreMaster 版本號(hào)跟之前 Client Hello 階段的版本號(hào)進(jìn)行對(duì)比,如果版本號(hào)變低,則說(shuō)明被串改,則立即停止發(fā)送任何消息。(copy)
? ??(b) 不管是客戶端還是服務(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ī)性增加的可不是一。
(2).密鑰使用
? ??Key 經(jīng)過(guò)12輪迭代計(jì)算會(huì)獲取到12個(gè) hash 值,分組成為6個(gè)元素,列表如下:
? ??(a) mac key、encryption key 和 IV 是一組加密元素,分別被客戶端和服務(wù)器使用,但是這兩組元素都被兩邊同時(shí)獲取;
? ??(b) 客戶端使用 client 組元素加密數(shù)據(jù),服務(wù)器使用 client 元素解密;服務(wù)器使用 server 元素加密,client 使用 server 元素解密;
? ??(c) 雙向通信的不同方向使用的密鑰不同,破解通信至少需要破解兩次;
? ??(d) encryption key 用于對(duì)稱加密數(shù)據(jù);
? ??(e) IV 作為很多加密算法的初始化向量使用,具體可以研究對(duì)稱加密算法;
? ??(f) Mac key 用于數(shù)據(jù)的完整性校驗(yàn);
(3).數(shù)據(jù)加密通信過(guò)程
? ? (a) 對(duì)應(yīng)用層數(shù)據(jù)進(jìn)行分片成合適的 block;
? ??(b) 為分片數(shù)據(jù)編號(hào),防止重放攻擊;
? ??(c) 使用協(xié)商的壓縮算法壓縮數(shù)據(jù);
? ??(d) 計(jì)算 MAC 值和壓縮數(shù)據(jù)組成傳輸數(shù)據(jù);
? ??(e) 使用 client encryption key 加密數(shù)據(jù),發(fā)送給服務(wù)器 server;
? ??(f) server 收到數(shù)據(jù)之后使用 client encrytion key 解密,校驗(yàn)數(shù)據(jù),解壓縮數(shù)據(jù),重新組裝。
注:MAC值的計(jì)算包括兩個(gè) Hash 值:client Mac key 和 Hash (編號(hào)、包類型、長(zhǎng)度、壓縮數(shù)據(jù))。
?
5、抓包分析
關(guān)于抓包不再詳細(xì)分析,按照前面的分析,基本的情況都能夠匹配,根據(jù)平常定位問(wèn)題的過(guò)程,個(gè)人提些認(rèn)為需要注意的地方:
? ??(1).抓包 HTTP 通信,能夠清晰的看到通信的頭部和信息的明文,但是 HTTPS 是加密通信,無(wú)法看到 HTTP 協(xié)議的相關(guān)頭部和數(shù)據(jù)的明文信息,
? ??(2).抓包 HTTPS 通信主要包括三個(gè)過(guò)程:TCP 建立連接、TLS 握手、TLS 加密通信,主要分析 HTTPS 通信的握手建立和狀態(tài)等信息。
? ??(3).client_hello
根據(jù) version 信息能夠知道客戶端支持的最高的協(xié)議版本號(hào),如果是 SSL 3.0 或 TLS 1.0 等低版本協(xié)議,非常注意可能因?yàn)榘姹镜鸵鹨恍┪帐质〉那闆r;
根據(jù) extension 字段中的 server_name 字段判斷是否支持SNI,存在則支持,否則不支持,對(duì)于定位握手失敗或證書(shū)返回錯(cuò)誤非常有用;
會(huì)話標(biāo)識(shí) session ID 是標(biāo)準(zhǔn)協(xié)議部分,如果沒(méi)有建立過(guò)連接則對(duì)應(yīng)值為空,不為空則說(shuō)明之前建立過(guò)對(duì)應(yīng)的連接并緩存;
會(huì)話記錄 session ticke t是擴(kuò)展協(xié)議部分,存在該字段說(shuō)明協(xié)議支持 sesssion ticket,否則不支持,存在且值為空,說(shuō)明之前未建立并緩存連接,存在且值不為空,說(shuō)明有緩存連接。
? ? (4).server_hello
? ??根據(jù) TLS version 字段能夠推測(cè)出服務(wù)器支持的協(xié)議的最高版本,版本不同可能造成握手失敗;
? ??基于 cipher_suite 信息判斷出服務(wù)器優(yōu)先支持的加密協(xié)議;
? ? (5).ceritficate
? ??服務(wù)器配置并返回的證書(shū)鏈,根據(jù)證書(shū)信息并于服務(wù)器配置文件對(duì)比,判斷請(qǐng)求與期望是否一致,如果不一致,是否返回的默認(rèn)證書(shū)。
? ? (6).alert
? ??告警信息 alert 會(huì)說(shuō)明建立連接失敗的原因即告警類型
總結(jié)
以上是生活随笔為你收集整理的SSL/TLS握手过程的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 如何根据CSD寄存器计算SD卡容量(cs
- 下一篇: ssl服务器测试网站