HTTPS簡(jiǎn)介
由于 HTTP 協(xié)議通信的不安全性，所以人們?yōu)榱朔乐剐畔⒃趥鬏斶^程中遭到泄漏或者篡改乐尊，就想出來對(duì)傳輸通道進(jìn)行加密的方式 HTTPS深纲。
HTTPS是一種加密的超文本傳輸協(xié)議盔性，它與 HTTP 在協(xié)議差異在于對(duì)數(shù)據(jù)傳輸?shù)倪^程中霞丧，HTTPS 對(duì)數(shù)據(jù)做了完全加密。
由于 HTTP 協(xié)議或者 HTTPS 協(xié)議都是處于 TCP 傳輸層之上冕香，同時(shí)網(wǎng)絡(luò)協(xié)議又是一個(gè)分層的結(jié)構(gòu)蛹尝，所以在 tcp 協(xié)議層之上增加了一層 SSL(Secure Socket Layer后豫，安全層) 或者 TLS(Transport Layer Security) 安全層傳輸協(xié)議組合使用用于構(gòu)造加密通道;
HTTPS的安全通信演進(jìn)過程
1. 無加密的HTTP傳輸過程
因?yàn)镠TTP是明文的，在無加密的情況下突那，客戶端很容易就可以攔截竊取挫酿，并且更改客戶端傳給服務(wù)端的內(nèi)容
2. 對(duì)稱加密
解釋：
為了解決HTTP是明文的問題，我們可以對(duì)稱加密的方式來解決愕难。
對(duì)稱加密即客戶端和服務(wù)端同時(shí)持有不公開秘鑰早龟。
缺點(diǎn)：
因?yàn)槊恳粋€(gè)客戶端所帶的秘鑰都是一樣的，所以非常有可能被不法份子獲取到猫缭，獲取到后不法份子就可攔截破解更改傳輸?shù)膬?nèi)容葱弟。所以對(duì)稱加密也不是一種可取的手段。
進(jìn)一步優(yōu)化：
在對(duì)稱加密不可用的情況下猜丹，我們引入每個(gè)客戶端使用的秘鑰不一樣芝加。因?yàn)槊總€(gè)客戶端的秘鑰都不一致，所以直接通過客戶端拿到秘鑰并破解的可能性大大的降低射窒。
缺點(diǎn)：
但是也引起另一個(gè)問題藏杖，服務(wù)端如何告訴客戶端使用哪一種加密算法？轮洋，如果還是使用HTTP請(qǐng)求獲取制市，那也還是會(huì)被不法分子獲取到的。
因此單純使用每個(gè)客戶端使用的秘鑰不一樣也不是一種可取的手段弊予。
2. 非對(duì)稱加密（公鑰/私鑰）
解釋：
所謂的公鑰/私鑰就是，使用公鑰可以解密私鑰的內(nèi)容开财，使用私鑰也可以解密公鑰的內(nèi)容汉柒。
公鑰是所有客戶端都知道的，然而私鑰就只能服務(wù)器知道责鳍，不能被別人知道的碾褂。
客戶端使用公鑰對(duì)內(nèi)容加密，服務(wù)端使用私鑰對(duì)我們加密過的內(nèi)容進(jìn)行解密历葛，返回給客戶端信息也使用秘鑰進(jìn)行加密正塌，客戶端拿到數(shù)據(jù)后，使用公鑰進(jìn)行解密恤溶。
缺點(diǎn)：
非對(duì)稱加密 比 對(duì)稱加密優(yōu)化方法好的一點(diǎn)是不需要防止客戶端的公鑰被獲取到乓诽。
看起來完美無瑕，可是還有對(duì)稱加密中的優(yōu)化方法問題：客戶端如何拿到公鑰咒程？鸠天，我們獲取到的公鑰必須是安全的公鑰，沒有被不法分子篡改過的帐姻。
3. 引用第三方機(jī)構(gòu)（數(shù)字證書CA）
解釋：
對(duì)稱加密和非對(duì)稱加密稠集，存在的問題就是不可信任奶段。我們服務(wù)端不知道客戶端傳過來的數(shù)據(jù)是否被不法分子修改過“祝客戶端獲取服務(wù)端的數(shù)據(jù)也不知道是否被不法分子修改過痹籍。
所以我們引用第三方機(jī)構(gòu)去保證客戶端和服務(wù)端所獲取的數(shù)據(jù)都是原始的，沒有被修改過和篡改過的晦鞋。
原理：
我們通過第三方機(jī)構(gòu)使用非對(duì)稱加密方法蹲缠，加密公鑰，得到數(shù)字證書（用私鑰加密公鑰）返回給客戶端鳖宾。
這樣不法分子吼砂，截取到數(shù)字證書，可由于數(shù)字證書是經(jīng)過加密的鼎文，不法分子沒辦法解密我們的數(shù)字證書渔肩，從而保證了信息不會(huì)泄露和不會(huì)被篡改。
存在問題：
- 客戶端如何去解密第三方機(jī)構(gòu)使用私鑰加密的證書拇惋？
-
第三方機(jī)構(gòu)可以頒發(fā)證書給任何一個(gè)服務(wù)端周偎，如果機(jī)構(gòu)頒發(fā)給了不法分子，不法分子可以攔截請(qǐng)求撑帖，并且把數(shù)字證書給替換掉蓉坎，客戶端如何確認(rèn)數(shù)字證書的有效性？
簡(jiǎn)易版CA存在問題
解決問題思路
在我們?nèi)粘Ｉ钪幸彩怯懈魇礁鳂拥淖C書胡嘿，比如畢業(yè)證書蛉艾，買的數(shù)碼產(chǎn)品等等.....
這些證書上都會(huì)帶有條形碼或者編號(hào)，條形碼或編號(hào)是唯一能夠確認(rèn)證書有效性衷敌，和對(duì)應(yīng)信息的勿侯。
因此客戶端如果能驗(yàn)證服務(wù)器返回來的數(shù)字證書的編號(hào)，那么我們就能夠確定該數(shù)字證書是否安全有效的缴罗。
服務(wù)器向第三方機(jī)構(gòu)申請(qǐng)數(shù)字證書時(shí)助琐，第三方生成的數(shù)字證書會(huì)帶有證書編號(hào)。證書編號(hào)是由MD5生成面氓，只要文件發(fā)生更改兵钮，所產(chǎn)生的MD5值都會(huì)不同的。也因?yàn)槭羌用茏C書舌界，所以不法分子是無法查看和修改的掘譬。
驗(yàn)證證書機(jī)制
瀏覽器內(nèi)置第三方機(jī)構(gòu)的公鑰（如果沒有則需要安裝），對(duì)數(shù)字證書進(jìn)行解密禀横，解密之后獲取摘要信息屁药。
然后根據(jù)數(shù)字簽名的算法，進(jìn)行運(yùn)算得出來的結(jié)果和服務(wù)端返回的數(shù)字證書簽名一致，那么就可認(rèn)為沒有被篡改過酿箭。
總結(jié)
客戶端發(fā)起請(qǐng)求(Client Hello 包)
a) 三次握手复亏，建立 TCP 連接
b) 支持的協(xié)議版本(TLS/SSL)
c) 客戶端生成的隨機(jī)數(shù) client.random，后續(xù)用于生成“對(duì)話密鑰”
d) 客戶端支持的加密算法
e) sessionid缭嫡，用于保持同一個(gè)會(huì)話(如果客戶端與服務(wù)器費(fèi)盡周折 建立了一個(gè) HTTPS 鏈接缔御，剛建完就斷了，也太可惜)服務(wù)端收到請(qǐng)求妇蛀，然后響應(yīng)(Server Hello)
a) 確認(rèn)加密通道協(xié)議版本
b) 服務(wù)端生成的隨機(jī)數(shù) ser ver.random耕突，后續(xù)用于生成“對(duì)話密鑰”
c) 確認(rèn)使用的加密算法(用于后續(xù)的握手消息進(jìn)行簽名防止篡改)
d) 服務(wù)器證書(CA機(jī)構(gòu)頒發(fā)給服務(wù)端的證書)客戶端收到證書進(jìn)行驗(yàn)證
a) 驗(yàn)證證書是否是上級(jí) CA 簽發(fā)的, 在驗(yàn)證證書的時(shí)候，瀏覽器會(huì) 調(diào)用系統(tǒng)的證書管理器接口對(duì)證書路徑中的所有證書一級(jí)一級(jí) 的進(jìn)行驗(yàn)證评架，只有路徑中所有的證書都是受信的眷茁，整個(gè)驗(yàn)證的結(jié) 果才是受信
b) 服務(wù)端返回的證書中會(huì)包含證書的有效期，可以通過失效日期來 驗(yàn)證 證書是否過期
c) 驗(yàn)證證書是否被吊銷了
d) 前面我們知道CA機(jī)構(gòu)在簽發(fā)證書的時(shí)候纵诞，都會(huì)使用自己的私鑰
對(duì)證書進(jìn)行簽名
證書里的簽名算法字段 sha256RSA 表示 CA 機(jī)構(gòu)使用 sha256 對(duì)證書進(jìn)行摘要上祈，然后使用 RSA 算法對(duì)摘要進(jìn)行私鑰簽名，而 我們也知道 RSA 算法中浙芙，使用私鑰簽名之后登刺，只有公鑰才能進(jìn) 行驗(yàn)簽。
e) 瀏覽器使用內(nèi)置在操作系統(tǒng)上的 CA 機(jī)構(gòu)的公鑰對(duì)服務(wù)器的證書 進(jìn)行驗(yàn)簽嗡呼。確定這個(gè)證書是不是由正規(guī)的機(jī)構(gòu)頒發(fā)纸俭。驗(yàn)簽之后得 知 CA 機(jī)構(gòu)使用 sha256 進(jìn)行證書摘要，然后客戶端再使用 sha256 對(duì)證書內(nèi)容進(jìn)行一次摘要南窗，如果得到的值和服務(wù)端返回 的證書驗(yàn)簽之后的摘要相同揍很，表示證書沒有被修改過
f) 驗(yàn)證通過后，就會(huì)顯示綠色的安全字樣
g) 客戶端生成隨機(jī)數(shù)万伤，驗(yàn)證通過之后女轿，客戶端會(huì)生成一個(gè)隨機(jī)數(shù)pre-master secret，客戶端根據(jù)之前的:Client.random + sever.random + pre-master 生成對(duì)稱密鑰然后使用證書中的公 鑰進(jìn)行加密壕翩，同時(shí)利用前面協(xié)商好的加密算法，將握手消息取 HASH 值傅寡，然后用“隨機(jī)數(shù)加密“握手消息+握手消息 HASH 值(簽 名)”然后傳遞給服務(wù)器端;(在這里之所以要取握手消息的 HASH 值放妈，主要是把握手消息做一個(gè)簽名，用于驗(yàn)證握手消息在傳輸過 程中沒有被篡改過荐操。)服務(wù)端接收隨機(jī)數(shù)
a) 服務(wù)端收到客戶端的加密數(shù)據(jù)以后芜抒，用自己的私鑰對(duì)密文進(jìn)行解
密。然后得到 client.random/server.random/pre-master secret. , 再用隨機(jī)數(shù)密碼 解密 握手消息與 HASH 值托启，并與傳過來的 HASH 值做對(duì)比確認(rèn)是否一致宅倒。
b) 然后用隨機(jī)密碼加密一段握手消息(握手消息+握手消息的 HASH 值 )給客戶端客戶端接收消息
a) 客戶端用隨機(jī)數(shù)解密并計(jì)算握手消息的 HASH，如果與服務(wù)端發(fā)
來的 HASH 一致屯耸，此時(shí)握手過程結(jié)束拐迁，
b) 之后所有的通信數(shù)據(jù)將由之前交互過程中生成的 pre master
secret / client.random/server.random 通過算法得出 session Key蹭劈，作為后續(xù)交互過程中的對(duì)稱密鑰
