有了前面加密和哈希以及數(shù)字證書和數(shù)字簽名兩篇文章的鋪墊姻蚓，終于可以來認識HTTPS的核心所在了磷醋，SSL/TLS協(xié)議冕臭。本篇從SSL/TLS發(fā)展歷史到握手以及傳輸?shù)脑敿氝^程來講解余蟹。
此篇文章的邏輯圖
SSL/TLS協(xié)議概覽
SSL/TLS協(xié)議是什么
計算機網(wǎng)絡的OSI七層模型和TCP/IP四層模型想必大家都知道。其中SSL/TLS是一種介與于傳輸層（比如TCP/IP）和應用層（比如HTTP）的協(xié)議子刮。它通過"握手協(xié)議(Handshake Protocol)"和"傳輸協(xié)議(Record Protocol)"來解決傳輸安全的問題威酒。SSL/TLS是一個可選層，沒有它挺峡，使用HTTP也可以通信葵孤，它存在的目的就是為了解決安全問題，這也就是HTTPS相對于HTTP的精髓所在橱赠。
SSL/TLS協(xié)議發(fā)展歷史
SSL/TLS協(xié)議發(fā)展歷史參看下表尤仍，更詳細的發(fā)展歷史參看維基百科的SSL/TLS協(xié)議發(fā)展歷史。
| Protocol | Year | RFC | Description |
|---|---|---|---|
| SSL 1.0 | 1994 | NetScape公司設計1.0版 但是未發(fā)布 | |
| SSL 2.0 | 1995.02 | NetScape公司發(fā)布SSL 2.0版 | |
| SSL 3.0 | 1996 | RFC 6101 | NetScape公司發(fā)布SSL 3.0版 |
| TLS 1.0 | 1999 | RFC 2246 | IETF將SSL標準化 改名為TLS 發(fā)布1.0版 |
| TLS 1.1 | 2006.04 | RFC 4346 | 發(fā)布TLS1.1版 |
| TLS 1.2 | 2008.08 | RFC 5246 | 發(fā)布TLS1.2版 |
| TLS 1.3 | TLS 1.3還是一個互聯(lián)網(wǎng)草案 待發(fā)布 |
目前狭姨，應用最廣泛的是TLS 1.0宰啦，接下來是SSL 3.0。但是饼拍，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持赡模。值得一提的是iOS9的App，需將HTTP連接升級到HTTPS师抄，并且TLS版本不得低于1.2(當然升級為HTTPS并非必須的)漓柑。
SSL/TLS運行過程
SSL/TLS運行過程概述
上面提到SSL/TLS有兩個階段握手協(xié)議和傳輸協(xié)議，握手協(xié)議就是建立起連接的過程，這個階段采用非對稱加密辆布，這個過程完畢后會生成一個對話秘鑰瞬矩，從而傳輸協(xié)議過程，就是用這個對話秘鑰使用對稱加密進行傳輸锋玲。之所以這樣做景用，是因為，非對稱加密是很耗性能的嫩絮。而握手協(xié)議過程中丛肢，使用數(shù)字證書保證了公鑰的安全性。當然這個過程既可以雙向證書驗證剿干，也可以只驗證服務端的證書單向證書驗證蜂怎。這也是前兩節(jié)所作的鋪墊，不至于這兒看的太迷糊置尔。
SSL/TLS運行過程詳解
結合上圖(圖2-0)杠步，我來說明上圖中一步步的都發(fā)生了什么？
客戶端發(fā)出請求(Client Hello)
對應上圖第一步榜轿，客戶端發(fā)出請求幽歼，這一步客戶端主要向服務端提供以下信息：
- 支持的
SSL/TLS協(xié)議版本 - 支持的加密套件列表
(cipher suite) - 支持的壓縮算法列表
(compression methods)，用于后續(xù)的壓縮傳輸 - 產(chǎn)生的一個隨機數(shù)
random_C(random number)谬盐，客戶端有存留甸私，稍后用于生成"對話密鑰(session key)"
服務端回應(Server Hello)
收到客服端的請求之后，服務端向客戶端回應以下信息：
- 根據(jù)客戶端支持的
SSL/TLS協(xié)議版本飞傀，和自己的比較確定使用的SSL/TLS協(xié)議版本皇型，如果沒有合適的，對話關閉 - 回應加密套件砸烦，壓縮算法
- 產(chǎn)生的一個隨機數(shù)
random_S(random number)弃鸦，服務端有存留，稍后用于生成"對話密鑰(session key)" - 服務端數(shù)字證書(證明自己的身份幢痘，傳遞公鑰)
- 如果需要驗證客戶端唬格，發(fā)出請求，要求客戶端提供證書
客戶端回應
客戶端收到服務端的回應后颜说，首先驗證服務端的數(shù)字證書购岗，如果證書沒有問題繼續(xù)下去，如果證書有問題门粪，則會有相應提示藕畔，或者對話直接關閉。然后客戶端在向服務端發(fā)送以下信息：
- 如果服務端有請求證書庄拇，發(fā)送自己的數(shù)字證書
- 在產(chǎn)生一個隨機數(shù)
pre-master key(random number)注服，并且用服務端數(shù)字證書中的公鑰加密 - 編碼改變通知韭邓，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送
服務端最后的回應
如果有客戶端的證書，就先驗證客戶端的證書
- 使用自己的私鑰溶弟，對隨機數(shù)
pre-master key解密女淑，這時客戶端和服務端各自有了三個隨機數(shù)，然后用原來協(xié)商的加密方式生成本次通話使用的會話密鑰(session key) - 編碼改變通知辜御，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送
這時客戶端和服務端都有了session key鸭你，然后握手協(xié)議階段就結束了。下面開始使用session key對稱加密數(shù)據(jù)擒权，進行傳輸袱巨，就進入了下一個階段，傳輸協(xié)議過程碳抄。
總結
這塊的重點在與SSL/TSL協(xié)議的握手協(xié)議過程愉老。在第三步，客戶端驗證證書的時候剖效，如果服務端的證書在系統(tǒng)默認信任證書列表中(系統(tǒng)會默認信任一些CA認證中心的根證書)則會直接通過嫉入，如果沒有在系統(tǒng)默認信任證書列表中，瀏覽器可能會彈窗讓用戶選擇是否信任該證書璧尸，也有可能會直接關閉連接咒林，提示用戶，證書不可信爷光。而在App內(nèi)垫竞，如果想要信任未在系統(tǒng)信任列表中的證書，則需要在App內(nèi)提前置入服務端證書蛀序，關于這一點有講欢瞪。而關于認證方式，大多數(shù)也都是采用的單向認證哼拔，也就是說僅僅認證服務端的證書引有，而像銀行等機構則多使用雙向認證的方式瓣颅。
