本文內(nèi)容主要講解Https協(xié)議，其他網(wǎng)絡(luò)知識點作為理解Https協(xié)議的輔助蓬推。
首先妆棒，需要簡單知道網(wǎng)絡(luò)協(xié)議的四個層次，即：網(wǎng)絡(luò)接口層沸伏，網(wǎng)絡(luò)層糕珊，傳輸層，應(yīng)用層毅糟。
Http協(xié)議
Http協(xié)議是一種超文本傳輸協(xié)議放接，是客戶端瀏覽器與服務(wù)器之前的 應(yīng)用層 通信協(xié)議。
Http協(xié)議不提供數(shù)據(jù)加密留特，以明文的方式發(fā)送內(nèi)容纠脾，容易被攻擊截取信息，不適合用于傳輸一些敏感信息蜕青。
Https協(xié)議
Https協(xié)議是以安全為目標(biāo)的Http通道苟蹈，在Http的基礎(chǔ)上加入SSL層，簡單來說就是Http協(xié)議的安全版右核。
Https協(xié)議的主要作用可以分為兩種：一種是建立一個信息安全通道慧脱，來保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認(rèn)網(wǎng)站的真實性贺喝。
在進行詳細(xì)解釋Https之前菱鸥，我們需要先簡單了解一些Https協(xié)議使用到的關(guān)鍵技術(shù)。
關(guān)鍵技術(shù)
對稱加密
對稱加密使用加密和解密使用相同密鑰的加密算法進行加密躏鱼，也叫私鑰加密氮采。常見的對稱加密有：DES, AES 等。
非對稱加密
非對稱加密與對稱加密不同染苛，使用非對稱加密算法進行加密鹊漠，需要兩個密鑰，即公鑰和私鑰。公鑰和私鑰是成對出現(xiàn)的躯概，在加密和解密的過程中使用不同的密鑰登钥，所以也稱為公鑰加密。
數(shù)字摘要
數(shù)字摘要采用單項Hash函數(shù)將需要加密的明文 摘要 成一串固定長度（128位）的密文娶靡，這個密文又稱為數(shù)字指紋牧牢。不同的明文摘生成的數(shù)字指紋總是不同的，而同樣的明文摘要生成的數(shù)字指紋必定一致姿锭。
數(shù)字摘要 是Https能確保數(shù)據(jù)完整性和防篡改的根本原因结执。
數(shù)字簽名
數(shù)字簽名是對 非對稱加密 和 數(shù)字摘要 兩項技術(shù)的應(yīng)用。
它將 摘要信息 用發(fā)送者的私鑰加密艾凯，與原文一起傳送給接收者献幔。
接收者只有使用發(fā)送者的公鑰才能解密出被加密的 摘要信息；接著對接收到的原文用 數(shù)字摘要 生成 摘要信息趾诗；然后將兩個 摘要信息 進行對比蜡感。若相同，說明收到的原文是完整的恃泪，在傳輸過程中沒有被修改郑兴。因此，數(shù)字簽名能夠驗證數(shù)據(jù)的完整性贝乎。
SSL
SSL是安全套接層情连，用以保障數(shù)據(jù)傳輸?shù)陌踩脭?shù)據(jù)加密技術(shù)確保數(shù)據(jù)在傳輸過程中不會被截取览效。
SSL又可分為兩層：
- SSL記錄協(xié)議建立在可靠的傳輸協(xié)議（如TCP）之上却舀，為高層協(xié)議提供數(shù)據(jù)封裝，壓縮锤灿，加密等基本功能的支持挽拔。
- SSL握手協(xié)議建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)開始傳輸前但校，通訊雙方進行身份認(rèn)證螃诅，協(xié)商加密算法，交換加密密鑰等状囱。
SSL/TLS握手流程
SSL/TLS握手過程流程圖：
-
客戶端發(fā)起請求：在SSL/TLS協(xié)議傳輸過程中术裸，客戶端和服務(wù)端必須使用同一套加解密算法才能保證數(shù)據(jù)正常的加解密。由于客戶端對一些加解密算法的支持程度不一樣亭枷，所以客戶端需要告知服務(wù)端自己支持的加密套件的列表傳給服務(wù)端袭艺。此外，客戶端還要生成一個隨機數(shù)（第一個隨機數(shù)）奶栖，用于傳送給服務(wù)端匹表，在后面的步驟中與服務(wù)端生成的隨機數(shù)結(jié)合起來產(chǎn)生 對話密鑰。
那么客戶端需要提供的信息：
- 支持的協(xié)議版本
- 支持的加密算法
- 支持的壓縮方法
- 隨機數(shù)
-
服務(wù)端響應(yīng)：服務(wù)端確定加密協(xié)議的版本和加密算法后宣鄙，也生成一個隨機數(shù)（第二個隨機數(shù)）袍镀，并將自己的證書一并發(fā)送給客戶端。
服務(wù)端需要提供的信息：
- 確定支持的版本
- 確定加密的算法
- 隨機數(shù)
- 服務(wù)器證書冻晤，包含公鑰
注意：一些場景下苇羡，服務(wù)器需要確認(rèn)客戶端的身份，會要求客戶端提供 客戶端證書
-
客戶端驗證證書：客戶端先對服務(wù)器下發(fā)的證書進行驗證鼻弧，驗證通過后客戶端再生成一個隨機數(shù)（第三個隨機數(shù)设江，也是最關(guān)鍵的隨機數(shù)），并使用證書中的公鑰對隨機數(shù)進行加密攘轩，再加入一個 ChangeCipherSpec 即編碼改變的消息和前面所有消息的Hash值叉存，最后將所有的這些信息發(fā)送到服務(wù)器，確保在正式通信前無誤度帮。
此時歼捏，客戶端得到全部的三個隨機數(shù)，客戶端會用協(xié)商的加密方法笨篷，生成本次會話所用的同一把 會話密鑰瞳秽。
ChangeCipherSpec是一個獨立的協(xié)議，在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù)率翅，用于告知服務(wù)端：客戶端已經(jīng)切換到了協(xié)商好的加密套件练俐，準(zhǔn)備好加密數(shù)據(jù)并進行傳輸了。
客戶端提供的信息：
- 使用服務(wù)器證書中的公鑰加密后的隨機數(shù)（第三個）
- ChangeCipherSpec 編碼改變的通知
- 握手結(jié)束的通知
注意：如果服務(wù)端需要客戶端證書冕臭，客戶端會在這一步發(fā)送證書信息腺晾。
-
服務(wù)端生成秘鑰：使用私鑰對隨機數(shù)（第三個）的加密數(shù)據(jù)進行解密，此時服務(wù)端得到全部的三個隨機數(shù)辜贵，同樣使用協(xié)商的加密方法丘喻，生成和客戶端使用的同一把 會話密鑰。準(zhǔn)備好后念颈，服務(wù)端也會給客戶端一個 ChangeCipherSpec 即編碼改變的消息泉粉，告知客戶端已經(jīng)切換到了協(xié)商好的加密套件，準(zhǔn)備好加密數(shù)據(jù)并進行傳輸了榴芳。
之后嗡靡，服務(wù)端會使用 會話密鑰 加密一段finish消息發(fā)送給客戶端，以驗證通過握手建立的加密通道是否成功窟感。
客戶端發(fā)送數(shù)據(jù)：確定 會話密鑰 后讨彼，客戶端與服務(wù)器之間就會使用對稱加密加密數(shù)據(jù)后傳輸了。整個握手的過程也就基本完成了柿祈。
注意：SSL協(xié)議在握手階段使用的是非對稱加密哈误，在傳輸階段使用的是對稱加密哩至。
因為非對稱加密的速度緩慢，比較耗費資源蜜自，所以在使用非對稱加密建立連接后菩貌，客戶端和服務(wù)器之間傳輸數(shù)據(jù)使用的是協(xié)商好的對稱加密算法和對稱加密密鑰（即會話密鑰）。這個數(shù)據(jù)傳輸過程本身是安全可靠的重荠，也就是說對稱加密密鑰是不可能被竊取盜用的箭阶。
如果有人竊聽通訊，他可以知道雙方選擇的加密方法戈鲁，以及三個隨機數(shù)中的兩個仇参，也就是說整個通話的安全，只取決于第三個隨機數(shù)（客戶端生成并加密）能不能被破解婆殿。
Session的恢復(fù)
兩種恢復(fù)Session對話的方式：Session ID诈乒，Session ticket。
Session ID
客戶端和服務(wù)器的每次對話都有一個編號婆芦。若對話中斷抓谴，重連時只要客戶端給出編號，并且服務(wù)器有該編號的記錄寞缝，雙方就可以使用已有的 對話密鑰 重新建立連接癌压，而不用重新走握手流程重新連接。
Session ID是目前所有瀏覽器都支持的方法荆陆，缺點是Session ID往往只保留在一臺服務(wù)器上滩届，如果客戶端重連時請求發(fā)到另一臺服務(wù)器上，就無法恢復(fù)對話被啼。
Session ticket
客戶端發(fā)送一個服務(wù)器在上次對話中發(fā)送過來的Session ticket帜消，其中包括對話的主要信息，如：對話密鑰和加密方法等浓体。這個Session ticket是加密的泡挺，只有服務(wù)器才能解密，服務(wù)器在解密Session ticket后就不用重新生成對話密鑰了命浴。
目前只有部分瀏覽器支持娄猫，如：Chrome和Firefox
參考資料：
- 風(fēng)化成石：Https協(xié)議詳解 推薦一看，文章主要精華都吸取自該博客生闲。
- 施小喵：HTTPS原理解析
- K__M：https協(xié)議原理
