隨著互聯(lián)網(wǎng)的快速發(fā)展冠句，安全性的問題越來越重要寂屏，加之人類是“貪婪”的，遠(yuǎn)遠(yuǎn)不滿足對于 HTTP 的安全性八秃，于是有了 HTTPS。而 HTTPS 在安全性上是怎樣遠(yuǎn)遠(yuǎn)勝于 HTTP 的呢肉盹？
HTTP 存在的問題
- 數(shù)據(jù)沒有加密：HTTP 的傳遞是明文昔驱，不會加密這些信息，只要攻擊者能夠獲取到這些明文上忍，用戶的隱私就完全暴露了骤肛。解決的方法就是信息加密。
- 無法驗(yàn)證身份：在 HTTP 應(yīng)用中窍蓝，客戶端和服務(wù)端并不能確認(rèn)對方的身份腋颠，因?yàn)樵?HTTP 標(biāo)準(zhǔn)中，沒有校驗(yàn)對端身份的標(biāo)準(zhǔn)吓笙。解決的方法就是用證書來驗(yàn)證對方的身份淑玫。
- 數(shù)據(jù)容易被篡改：HTTP 數(shù)據(jù)在傳輸過程中，會經(jīng)過很多節(jié)點(diǎn)观蓄，這些節(jié)點(diǎn)都可以修改原始數(shù)據(jù)混移，而對于客戶端和服務(wù)端來說，沒有任何技術(shù)來確保接受的數(shù)據(jù)就是發(fā)送者發(fā)送的原始數(shù)據(jù)侮穿。解決方法就是利用一些算法來檢驗(yàn)數(shù)據(jù)歌径。
HTTP 存在的這些問題，導(dǎo)致了很大的安全性問題亲茅。所以便有了 HTTPS 的誕生回铛。
HTTPS
HTTPS 并不是一個(gè)新的協(xié)議狗准，本質(zhì)上還是 HTTP，只是 HTTPS 在 HTTP 的基礎(chǔ)上 增加了一些網(wǎng)絡(luò)安全的東西茵肃。HTTPS 是建立在安全 socket 層次上的超文本傳輸協(xié)議腔长，可以認(rèn)為 HTTPS = HTTP + SSL/TLS
SSL/TLS 是安全協(xié)議。SSL(Secure Sockets Layer)：安全套接字層協(xié)議验残；TLS(Transport Layer Security)：安全傳輸層協(xié)議捞附。TLS 是 從 SSL 發(fā)展而來的，SSL 是最早期的安全層協(xié)議您没，后來發(fā)現(xiàn)了一些漏洞后鸟召，便有了 TLS。現(xiàn)階段使用最多的版本是 TLS1.2氨鹏、TLS1.3版本欧募。
安全協(xié)議版本需要雙方通信協(xié)商之后，確定雙方使用相同版本的協(xié)議仆抵，才能建立安全連接跟继。
在講瀏覽器使用 HTTPS 傳輸數(shù)據(jù)的流程之前，我們先來了解幾個(gè)知識镣丑。
加密算法
在上面說 HTTP 存在「數(shù)據(jù)沒有加密」這個(gè)問題的時(shí)候說到舔糖，要解決的方法就是信息加密。然而加密算法也有很多種传轰。
密鑰：一種參數(shù)剩盒，在明文轉(zhuǎn)換為密文谷婆，或者密文轉(zhuǎn)換為明文時(shí)使用的
1慨蛙、對稱算法
對稱算法顧名思義，就是加密和解密數(shù)據(jù)時(shí)纪挎，使用相同的密鑰期贫。
優(yōu)點(diǎn)：就是效率很高，可以對長數(shù)據(jù)進(jìn)行加密异袄。
缺點(diǎn)：最大的問題就是通砍，通信雙方難以確保拿到安全的密鑰。因?yàn)榈谝徊娇偸切枰ㄟ^通信來協(xié)商密鑰的烤蜕，那么在這個(gè)協(xié)商的過程封孙，也有可能被黑客監(jiān)聽、篡改讽营。如果使用一個(gè)固定的密鑰虎忌，那這個(gè)算法也失去了意義。
2橱鹏、非對稱算法
與對稱算法不一樣的是膜蠢，非對稱算法使用的是不用的密鑰堪藐。
- 非對稱算法有兩把密鑰：公鑰與私鑰。
- 公鑰是公開給所有人的挑围，私鑰是自己保密的礁竞，不能給別人知道。
- 使用公鑰加密杉辙，只有私鑰才能解開模捂。同樣，使用私鑰加密蜘矢，只有公鑰才能解開
優(yōu)點(diǎn)：完美解決了對稱算法存在“無法安全交換密鑰”的問題
缺點(diǎn)：性能很差枫绅，效率遠(yuǎn)遠(yuǎn)不及對稱算法。
3硼端、對稱 + 非對稱算法
對稱算法的效率高并淋，但是無法安全交換密鑰；而非對稱算法可以安全交換密鑰珍昨，但是效率非常低县耽。所以我們可以：第一次通信協(xié)商的時(shí)候使用非對稱算法來交換密鑰，后面就使用對稱算法來繼續(xù)通話镣典，那這樣是不是取其優(yōu)點(diǎn)整合呢兔毙？如下圖所示：
- 1、客戶端發(fā)起請求的時(shí)候兄春，服務(wù)端首先明文返回一個(gè)公鑰給客戶端
- 2澎剥、客戶端拿到了服務(wù)端的公鑰后，利用服務(wù)端的公鑰來加密客戶端自己的密鑰赶舆，然后發(fā)給服務(wù)端哑姚。
- 3、服務(wù)端拿到了客戶端用自己公鑰加密的數(shù)據(jù)后芜茵，用私鑰進(jìn)行解密叙量，拿到了客戶端的密鑰
- 4、服務(wù)端用剛剛拿到的客戶端密鑰進(jìn)行加密自己的密鑰九串，然后發(fā)給客戶端绞佩。
- 5、客戶端拿到來服務(wù)端的密鑰
這就是對稱算法 + 非對稱算法的通信過程猪钮。
數(shù)字證書
在上面說 HTTP 存在「無法驗(yàn)證對方身份」這個(gè)問題的時(shí)候說到品山，要解決的方法就是用證書來驗(yàn)證。那么什么是證書呢烤低？ 又是如何利用證書來驗(yàn)證身份的呢肘交？
1、什么是數(shù)字證書拂玻？
數(shù)字證書是指在互聯(lián)網(wǎng)通訊中標(biāo)志通訊各方身份信息的一個(gè)數(shù)字認(rèn)證酸些，人們可以在網(wǎng)上用它來識別對方的身份宰译，是由電子商務(wù)認(rèn)證中心（簡稱CA中心）所頒發(fā)的一種較為權(quán)威與公正的證書。
數(shù)字證書好比我們的身份證魄懂，用來驗(yàn)證信息的一個(gè)認(rèn)證
數(shù)字證書里面包括服務(wù)器信息：公鑰沿侈、證書簽名、證書機(jī)構(gòu)信息等等市栗∽菏茫客戶端拿到服務(wù)端的證書，進(jìn)行證書驗(yàn)證后填帽，可以準(zhǔn)備拿到服務(wù)器的公鑰蛛淋，利用這個(gè)公鑰，就可以實(shí)現(xiàn) 對稱 + 非對稱算法加密了篡腌。
數(shù)字證書的作用就是：驗(yàn)證數(shù)據(jù)來源褐荷，安全獲取服務(wù)器的公鑰進(jìn)行加密通信。
2嘹悼、證書的生成
數(shù)字證書是由認(rèn)證中心（CA）或者認(rèn)證中心的下級認(rèn)證中心頒發(fā)的叛甫。根證書是認(rèn)證中心與用戶建立信任關(guān)系的基礎(chǔ)。在用戶使用數(shù)字證書之前必須先下載和安裝杨伙。
證書的產(chǎn)生：認(rèn)證中心把用戶證書的基本信息做哈希算法其监，然后用自己的私鑰對哈希值進(jìn)行加密。如下圖所示：
- 服務(wù)端產(chǎn)生了自己的密鑰對限匣，并將公共密鑰及部分服務(wù)器身份信息傳送給一家認(rèn)證中心（CA機(jī)構(gòu)認(rèn)證）抖苦。
- 證書機(jī)構(gòu)對服務(wù)器的信息使用 hash 算法得出一份128位的摘要，并對這份摘要使用自己的私鑰進(jìn)行非對稱加密得到證書數(shù)字簽名米死。
- 證書機(jī)構(gòu)把服務(wù)器信息（明文）+數(shù)字簽名+證書機(jī)構(gòu)信息（包含證書機(jī)構(gòu)公鑰）發(fā)送給服務(wù)器
- 客戶端請求服務(wù)器時(shí)锌历，服務(wù)器把證書返回給客戶端。
3哲身、證書的分發(fā)
CA 將證書分發(fā)給用戶的途徑有多種辩涝。
- 帶外分發(fā)(Out-of-band Distribution)贸伐，即離線方式勘天。例如，密鑰對是由軟件運(yùn)營商代替客戶生成捉邢，證書也是由運(yùn)營商代替客戶從 CA 下載脯丝，然后把私鑰和下載的證書一起儲存在軟盤里，再交給用戶的伏伐。這樣做的好處是免去了用戶上網(wǎng)下載證書的麻煩宠进。
- 帶內(nèi)分發(fā)(In-band distribution)，即用戶從網(wǎng)上下載數(shù)字證書到自己的電腦中藐翎。下載時(shí)材蹬，用戶要向CA出示“參考號”和“授權(quán)碼”实幕，以向CA證明自己的身份。這樣做成本較低堤器。
- 查詢公共數(shù)據(jù)庫昆庇。CA 還把證書集中放置在公共的數(shù)據(jù)庫中公布，用戶可以隨用隨查詢隨調(diào)用闸溃。
4整吆、如何驗(yàn)證數(shù)字證書？辉川？表蝙？
舉個(gè)例子：
A 同學(xué)驗(yàn)證 B 同學(xué)的證書
- A 同學(xué)拿到了 B 同學(xué)的證書（B 同學(xué)的證書、CA 簽發(fā) B 同學(xué)的證書乓旗、證書機(jī)構(gòu)信息）
- A 同學(xué)用 CA 的公鑰解密對 CA 簽發(fā) B 同學(xué)的證書進(jìn)行解密府蛇，得到一份摘要 S1
- A 同學(xué)對 B 同學(xué)的信息用 hash 算法得到一份摘要S2
- 對比S1、S2屿愚，看看信息是否被篡改過
- 校驗(yàn) B 同學(xué)證書的有效期欲诺、證書作廢列表（CRL,OCSP）以及簽發(fā)者簽名（證書鏈）
證書有效期：證書頒發(fā)的時(shí)候，就已經(jīng)確定了過期時(shí)間渺鹦，個(gè)人一般是一年時(shí)間扰法，企業(yè)是三年。這樣定期更新產(chǎn)生新的密鑰對毅厚，對安全性上是有好處的
證書作廢列表：當(dāng)我們申請證書注銷的時(shí)候塞颁，因?yàn)樽C書一旦頒發(fā)，就不能收回吸耿，所以 CA 只能出一張告示祠锣，宣布這張證書已作廢。這個(gè)“告示”稱為證書作廢列表咽安。
5伴网、證書鏈
剛剛在驗(yàn)證數(shù)字證書的時(shí)候，我們提到了證書鏈妆棒，那么什么是證書鏈呢澡腾？ 證書鏈又有什么作用呢？
回憶一下剛剛數(shù)字簽名的生成與驗(yàn)證過程：CA 利用自己的私鑰加密生產(chǎn)證書糕珊，然后用戶用 CA 公鑰去解密驗(yàn)證动分。過程中是拿不到 CA 的密鑰的。如果中途被劫持了（黑客使用自己的私鑰加密红选，同時(shí)把證書機(jī)構(gòu)的公鑰修改成自己的公鑰）澜公，我們怎么得知呢？ 這時(shí)候就需要證書鏈了＠摺坟乾！
隨便打開一個(gè) HTTPS 的網(wǎng)站迹辐，在地址欄的左側(cè)有一個(gè)小鎖，點(diǎn)開可以看到里面的證書信息甚侣。
可以看到證書的層次是 GlobalSign Root CA --> GlobalSign Organization Validation CA --> baidu.com
- end-user：即 baidu.com右核，該證書包含百度的公鑰，訪問者就是使用該公鑰將數(shù)據(jù)加密后再傳輸給百度渺绒，即在 HTTPS 中使用的證書
- intermediates：即上文提到的 簽發(fā)人 Issuer贺喝，用來認(rèn)證公鑰持有者身份的證書，負(fù)責(zé)確認(rèn) HTTPS 使用的 - - end-user 證書確實(shí)是來源于百度宗兼。這類 intermediates 證書可以有很多級躏鱼，也就是說 簽發(fā)人 Issuer 可能會有很多級
- root：可以理解為 最高級別的簽發(fā)人 Issuer，負(fù)責(zé)認(rèn)證 intermediates 身份的合法性
這其實(shí)代表了一個(gè)信任鏈條殷绍，最終的目的就是為了保證 end-user 證書是可信的染苛，該證書的公鑰也就是可信的。證書鏈如下圖所示：
前面說了證書的驗(yàn)證過程主到，那么證書鏈又是怎么個(gè)驗(yàn)證流程呢茶行？
- 獲取 end-user 的公鑰，需要獲取 end-user 的證書登钥，因?yàn)楣€就保存在該證書中
- 為了證明獲取到的 end-user 證書是可信的畔师，就要看該證書是否被 intermediate 權(quán)威機(jī)構(gòu)認(rèn)證，等價(jià)于是否有權(quán)威機(jī)構(gòu)的數(shù)字簽名
- 有了權(quán)威機(jī)構(gòu)的數(shù)字簽名牧牢，而權(quán)威機(jī)構(gòu)就是可信的嗎看锉？需要繼續(xù)往上驗(yàn)證，即查看是否存在上一級權(quán)威認(rèn)證機(jī)構(gòu)的數(shù)字簽名
- 信任鏈條的最終是Root CA塔鳍，他采用自簽名伯铣，對他的簽名只能無條件的信任
以上就是關(guān)于證書鏈的基本知識了，這里有一篇外文是關(guān)于證書鏈的轮纫，有興趣的可以觀看一下 點(diǎn)一點(diǎn)
6腔寡、散列算法
散列算法，也稱之為摘要算法或哈希算法掌唾，可以將任一數(shù)據(jù)對象壓縮成數(shù)據(jù)摘要放前，對于同一散列算法，壓縮后的數(shù)據(jù)摘要具有特定的長度和格式郑兴，以此形成數(shù)據(jù)的"指紋"犀斋。原始數(shù)據(jù)對象的任一細(xì)小的改動，都可能使得新的"數(shù)字指紋"有著很大不同情连。
往往通過散列算法，可以判斷兩個(gè)數(shù)據(jù)對象是否相同览效，因?yàn)橄嗤臄?shù)據(jù)對象却舀，通過散列算法形成的"數(shù)字指紋"必定是相同的虫几，但是相同的"數(shù)字指紋"，對應(yīng)的原始數(shù)據(jù)對象不一定是相同挽拔，因?yàn)榭赡艽嬖谏⒘袥_突問題辆脸。在現(xiàn)實(shí)中就有廣泛的使用場景，例如最常用的對兩個(gè)文件對象進(jìn)行MD5螃诅，判斷其內(nèi)容是否相同啡氢。
散列算法與加密算法區(qū)別：
- 加密算法：對應(yīng)的是可以解密的，目的是進(jìn)行數(shù)據(jù)加密后的安全存儲或傳輸术裸，是可以通過密鑰得到原文的倘是，是可逆的過程。
- 散列算法：本質(zhì)上"數(shù)字指紋"的范疇袭艺，通過散列算法形成的"數(shù)字簽名"搀崭，直接在算法層面是不能得到原文的，是不可逆的猾编。當(dāng)然瘤睹，通過彩虹表和數(shù)據(jù)字典這種形式的所謂解密，本質(zhì)上只是暴力破解的過程答倡。
HTTPS 連接過程
有了上面的知識了解后轰传，我們來看看 HTTPS 連接的過程。
由上圖的可知流程：
- 1瘪撇、首先客戶端（client）發(fā)起請求绸吸，并帶上本地的 TLS 版本，客戶端支持的加密算法套件设江，并生成一個(gè)客戶端的隨機(jī)數(shù) R1 也一同發(fā)送過去
- 2锦茁、服務(wù)端（server）收到請求后，確認(rèn)了 TLS 版本叉存，并從客戶端支持的算法套件中選擇一個(gè)码俩，并生成一個(gè)服務(wù)端的隨機(jī)數(shù) R2，然后返回給客戶端選擇的加密套件歼捏，隨機(jī)數(shù) R2稿存，還有 CA 證書（包括公鑰）以及證書簽名。
- 3瞳秽、客戶端（client）收到了服務(wù)端的證書后瓣履，驗(yàn)證證書的合法性（具體可以往上看如何驗(yàn)證證書的合法性）。利用兩個(gè)隨機(jī)數(shù)R1练俐、R2袖迎，生成pre-master secret，并使用服務(wù)器的公鑰加密發(fā)送給服務(wù)器。并且客戶端生成會話密鑰和p1-p6
- 4燕锥、服務(wù)端（server）利用私鑰解密得到pre-master secret辜贵。并生成會話密鑰和p1-p6
- 5、客戶端（client）利用第三步生成的 p1 對握手信息的 hash 加密生成 Encrypted handshake message归形，然后發(fā)送給服務(wù)端托慨，并發(fā)送FIN報(bào)文，表示結(jié)束暇榴。
- 6厚棵、服務(wù)端（server）利用第四步生成的 p1 驗(yàn)證客戶端的 Encrypted handshake message。
- 7蔼紧、驗(yàn)證通過后婆硬，利用 p2 對握手信息的 hash 加密生成 Encrypted handshake message，然后發(fā)送給服務(wù)端歉井，并發(fā)送FIN報(bào)文柿祈，表示結(jié)束。
- 8哩至、客戶端（client）利用 p2 驗(yàn)證完服務(wù)端的 Encrypted handshake message后躏嚎，HTTPS 的連接流程結(jié)束
至此、雙方可以安全進(jìn)行通信了菩貌。
疑惑點(diǎn)：
1卢佣、客戶端的隨機(jī)數(shù) R1、服務(wù)端的隨機(jī)數(shù) R2 的作用是什么箭阶？
答：雙方通過交互各自的隨機(jī)數(shù)后虚茶，雙方都擁有了 R1、R2仇参∴诮校客戶端（client）利用 R1、R2 生成一個(gè) pre-master secret诈乒，然后利用這三個(gè)數(shù)罩扇，生成會話密鑰。
同樣的服務(wù)端（server）也是利用這三個(gè)數(shù)生成會話密鑰怕磨。
2喂饥、p1-p6 的作用是什么？
答：6個(gè)密鑰 p1-p6 是用作后續(xù)的身份認(rèn)證
3肠鲫、Encrypted handshake message 是什么员帮？ 有什么用？
答：Encrypted handshake message 把當(dāng)前自己收到的數(shù)據(jù)和發(fā)送的數(shù)據(jù)進(jìn)行一次簡單運(yùn)算（hash+加密）导饲。
這個(gè)報(bào)文的目的就是告訴對端自己在整個(gè)握手過程中收到了什么數(shù)據(jù)捞高，發(fā)送了什么數(shù)據(jù)氯材。來保證中間沒人篡改報(bào)文。
其次棠枉，這個(gè)報(bào)文作用就是確認(rèn)秘鑰的正確性浓体。因?yàn)镋ncrypted handshake message是使用對稱秘鑰進(jìn)行加密的第一個(gè)報(bào)文泡挺，如果這個(gè)報(bào)文加解密校驗(yàn)成功辈讶，那么就說明對稱秘鑰是正確的。
Charles 抓取 HTTPS 原理
做個(gè)小拓展娄猫，說一下 Charles 抓包工具抓 HTTPS 的原理
Charles 相當(dāng)于一個(gè)中間人贱除，對于客戶端（client）來說，服務(wù)端是 Charles媳溺。而對于服務(wù)端（server）來說月幌，客戶端是 Charles。如下圖所示：
簡單來說悬蔽，就是 Charles 作為“中間人代理”扯躺，拿到了 服務(wù)器證書公鑰 和HTTPS 連接的對稱密鑰，前提是客戶端選擇信任并安裝 Charles 的 CA 證書蝎困，否則客戶端就會“報(bào)警”并中止連接录语。這樣看來，HTTPS 還是很安全的禾乘。
參考連接
