一、 簡(jiǎn)介
- SSL（Secure Socket Layer 安全套接層），由網(wǎng)景在20世紀(jì)90年代開(kāi)發(fā)的安全協(xié)議；
- 1995年Netscape發(fā)布SSL v2.0
- 1996年Netscape發(fā)布SSL v3.0
- 1999年 IETF(Internet工程任務(wù)組)發(fā)布TLS v1.0，用于替代SSL v3.0
- 2006年 發(fā)布TLS v1.1
- 2008年 發(fā)布TLS v1.2
- 2018年 發(fā)布TLS v1.3
至2020年3月，微軟、蘋(píng)果、谷歌等多家企業(yè)已棄用TLS v1.0 和 TLS v1.1。
目前，應(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。
二 、通信模式演化
- 正常通訊，無(wú)加密通信過(guò)程很不安全，黑客可以監(jiān)聽(tīng)雙方的通信、攔截通信、偽造數(shù)據(jù)進(jìn)行攻擊。
- 使用密鑰加密為了應(yīng)對(duì)攻擊，對(duì)通信數(shù)據(jù)使用對(duì)稱加密算法進(jìn)行加密。通信雙方需要共享密鑰。1981年，出現(xiàn)對(duì)稱加密算法DES。DES使用56bit的密鑰。但由于雙方需要共享密鑰，這個(gè)密鑰在傳輸過(guò)程中有可能被攔截。
- 更高強(qiáng)度的密鑰DES可能被暴力破解。為了更高的安全性，出現(xiàn)了triple-DES(最長(zhǎng)168bit密鑰)、AES (最高 256bit密鑰 )。這仍沒(méi)解決雙方傳遞共享密鑰的問(wèn)題。
- 非對(duì)稱加密最著名的非對(duì)稱加密算法RSA算法，其加密與解密使用不同密鑰，加密的密鑰可以公開(kāi)。這樣可以有效解決雙方共享密鑰的問(wèn)題。在使用中，通訊雙方都有一個(gè)公鑰和私鑰。
A要給B發(fā)網(wǎng)絡(luò)數(shù)據(jù)流程：
- A使用私鑰加密數(shù)據(jù)的hash值
- A再用B的公鑰加密數(shù)據(jù)。
- A將加密的hash值和加密的數(shù)據(jù)加上一些其它信息（如時(shí)間戳）發(fā)給B
- B 先用私鑰解密數(shù)據(jù)
- B本地運(yùn)行一個(gè)hash值
- B用A的公鑰解密hash值，與自己運(yùn)行的比較，檢驗(yàn)數(shù)據(jù)完整性。但最初通訊交換公鑰的過(guò)程，仍存在被中間人攻擊的可能。
- 使用可信任機(jī)構(gòu)頒布數(shù)字證書(shū)
三 、HTTPS
HTTP Over SSL，就是通過(guò)SSL/TLS加密HTTP數(shù)據(jù)。證書(shū)鏈檢測(cè)工具： myssl.com
四、SSL/TLS 基本運(yùn)行過(guò)程
1. 整體通訊流程
- 客戶端向服務(wù)器端索要并驗(yàn)證公鑰
- 雙方協(xié)商生成“對(duì)話密鑰”
- 雙方采用“對(duì)話密鑰”進(jìn)行加密通信。
SSL/TLS 使用非對(duì)稱加密 。
- 保證公鑰不被篡改：將公鑰放在數(shù)字證書(shū)中，只要證書(shū)是可信的，公鑰就是可信的。
- 每一次對(duì)話，雙方生成一個(gè)對(duì)稱密鑰，用來(lái)加密信息，采用對(duì)稱加密。 非對(duì)稱加密只用來(lái)加密對(duì)稱加密的密鑰。
流程示意圖：
通訊抓包示意圖：
2. 握手階段詳細(xì)過(guò)程
握手階段涉及4次通信。
4.1 客戶端發(fā)出請(qǐng)求(Client Hello)
客戶端數(shù)據(jù)主要包含：
- 支持的協(xié)議版本，如TLS 1.2版
- 一個(gè)客戶端生成的隨機(jī)數(shù)，稍后用于生成公鑰
- 支持的加密方法 ，如RSA
- 支持的壓縮方法。
客戶端發(fā)送的信息中不包括服務(wù)器的域名。2006年，TLS協(xié)議加入了一個(gè)Service Name Indication擴(kuò)展，允許客戶端向服務(wù)器提供它所請(qǐng)求的域名。
支持的加密算法示例：
4.2 服務(wù)器回應(yīng)(Server Hello)
服務(wù)器收到客戶端請(qǐng)求后，向客戶端發(fā)出回應(yīng)，包含：
- 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.2版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
- 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話密鑰"。
- 確認(rèn)使用的加密方法，比如RSA公鑰加密。
- 服務(wù)器證書(shū)。
如果是雙向認(rèn)證，服務(wù)器需要確認(rèn)客戶端的身份，就會(huì)再包含一項(xiàng)請(qǐng)求，要求客戶端提供客戶端證書(shū)。即金融機(jī)構(gòu)服務(wù)器端只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書(shū)。下面是單向認(rèn)證抓包示意，Server Hello分成兩個(gè)包發(fā)送。
4.3 客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書(shū)。如果有以下問(wèn)題：
- 證書(shū)不是可信機(jī)構(gòu)頒布
- 或者證書(shū)中的域名與實(shí)際域名不一致
- 或證書(shū)已經(jīng)過(guò)期
這時(shí)就會(huì)向訪問(wèn)者顯示一個(gè)警告，由用戶選擇是否還要繼續(xù)通信。
如果證書(shū)沒(méi)有問(wèn)題，客戶端就會(huì)從證書(shū)中取出服務(wù)器的公鑰，然后，向服務(wù)器發(fā)送以下信息：
- 一個(gè)隨機(jī)數(shù)，用服務(wù)器公鑰加密，稱為pre-master key。
- 編碼改變通知，表示隨后的信息將用雙方商定的加密方法 和密鑰發(fā)送
- 客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。 這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供服務(wù)器檢驗(yàn)。
客戶端與服務(wù)器同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會(huì)話所用的同一把”會(huì)話密鑰“。
使用三次隨機(jī)數(shù)，防止有的主機(jī)生成的只是偽隨機(jī)數(shù)。
4.4 服務(wù)器回應(yīng)
服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話所用的”會(huì)話密鑰“，然后給客戶端發(fā)送下面信息：
- 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法 和密鑰發(fā)送。
- 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供客戶端檢驗(yàn)。
