1. 驗(yàn)證通信安全的四大特性

1. 機(jī)密性：就是指對(duì)數(shù)據(jù)的保密性畔柔。簡(jiǎn)單來說捐腿，就是不能讓不相關(guān)的人看到不該看的東西。
2. 完整性：就是指數(shù)據(jù)在傳輸過程中沒有被篡改。
3. 身份認(rèn)證：確認(rèn)對(duì)方的真實(shí)身份士八。保證消息只能發(fā)送給可信的人。
4. 不可否認(rèn)：也叫不可抵賴性梁呈，意思是不能否認(rèn)已經(jīng)發(fā)生過的行為婚度，不能“說話不算數(shù)”。

2. 什么是 HTTPS

HTTPS 的端口號(hào)是：443官卡。HTTPS 除了是密文接收外蝗茁，其它特性與 HTTP 完全一樣。

HTTP 和 HTTPS 的區(qū)別

image

HTTP 和 HTTPS 的區(qū)別在于：HTTPS 在 HTTP 和 TCP 層中間增加了一層 SSL/TLS 層來處理數(shù)據(jù)傳輸過程中的加密和解密的工作寻咒。也就是從服務(wù)器響應(yīng)回來的數(shù)據(jù)是經(jīng)過 SSL/TLS 層解密后的明文數(shù)據(jù)哮翘。

3. 什么是 SSL/TLS

SSL：安全套接層，是由網(wǎng)景公司開發(fā)的毛秘，最新版本為 V3饭寺。被標(biāo)準(zhǔn)化為 TLS 后，就沒有再更新叫挟。

TLS：傳輸層安全艰匙，是 IETF 標(biāo)準(zhǔn)化組織基于 SSL 3.0 上進(jìn)行了標(biāo)準(zhǔn)化，并改名為 TLS抹恳，TLS 1.0 對(duì)應(yīng)的是 SSL 3.1（不存在员凝，改名后就是 TLS1.0）。最新版本為 v1.3（2018）奋献，目前應(yīng)用最廣泛的為 TLSv1.2绊序。

TLS 是一個(gè)協(xié)議集合，主要由記錄協(xié)議秽荞、握手協(xié)議骤公、警告協(xié)議、變更密碼規(guī)范協(xié)議和擴(kuò)展協(xié)議等幾個(gè)子協(xié)議組成扬跋。

密碼套件

客戶端和服務(wù)器在使用 TLS 建立連接時(shí)需要選擇一組恰當(dāng)?shù)募用芩惴▉韺?shí)現(xiàn)安全通信阶捆。被稱為“密碼套件”。密碼套件的基本格式為：密鑰交換算法 + 簽名算法 + 對(duì)稱加密算法 + 摘要算法钦听。

例子：

ECDHE-RSA-AES256-GCM-SHA384

密鑰交換算法（ECDHE）：用于握手時(shí)進(jìn)行密鑰交換洒试。
簽名算法（RSA）：用于簽名和身份認(rèn)證。
對(duì)稱加密算法 + 分組模式（AES256-GCM）：握手完成后朴上，對(duì)數(shù)據(jù)進(jìn)行加密傳輸用的垒棋。
摘要算法（SHA384）：用于消息認(rèn)證和產(chǎn)生隨機(jī)數(shù)。

對(duì)稱加密算法+分組模式

指的是將要加密的明文通過分組模式進(jìn)行分組成多個(gè)塊痪宰，然后再使用對(duì)稱加密算法將每個(gè)塊進(jìn)行分別加密叼架。接收端解密的時(shí)候畔裕，也是對(duì)整個(gè)密文分塊進(jìn)行解密。

上面的密碼套件使用的就是：AES256-GCM 對(duì)稱加密算法 + 分組模式乖订。

對(duì)稱加密在網(wǎng)絡(luò)通信中存在的問題

如何將密鑰安全地傳遞給對(duì)方扮饶，術(shù)語(yǔ)叫“密鑰交換”。

4. 非對(duì)稱加密

4.1 什么是非對(duì)稱加密

非對(duì)稱加密就是它有兩個(gè)密鑰乍构，一個(gè)公鑰甜无，一個(gè)私鑰。兩個(gè)密鑰是不同的哥遮，“不對(duì)稱”的岂丘，公鑰可以公開給任何人使用，而私鑰必須嚴(yán)格保密眠饮。

特點(diǎn)

公鑰和私鑰都可以用來加密元潘、解密，但具有單向性君仆。使用公鑰進(jìn)行加密后翩概，只能用私鑰進(jìn)行解密。同樣的返咱，使用私鑰進(jìn)行加密后钥庇，只能使用公鑰進(jìn)行解密。

常見的非對(duì)稱加密算法

• RSA1024咖摹、RSA2048
• ECC160评姨、ECC224

ECC 的子算法有：ECDHE（用于密鑰交換） 和 ECDSA（用于數(shù)字簽名）。

其中萤晴，ECC 在安全性和性能上相比 RSA 都有明顯的優(yōu)勢(shì)吐句。ECC160 相當(dāng)于 RSA1024，ECC224 相當(dāng)于 RSA2048店读。

4.2 有了非對(duì)稱加密嗦枢，為什么還需要對(duì)稱加密

雖然非對(duì)稱加密沒有“密鑰交換”的問題，但是因?yàn)樗鼈兌际腔趶?fù)雜的數(shù)據(jù)難題屯断，運(yùn)算速度很慢文虏，即使使用 ECC 也要比 AES 差上好幾個(gè)數(shù)量級(jí)。如果僅僅是使用非對(duì)稱加密來傳輸數(shù)據(jù)殖演，雖然安全上有了保證氧秘，但是通信速度會(huì)變得非常慢。

image

4.3 混合加密

1. 在通信剛開始的時(shí)候趴久，使用非對(duì)稱算法丸相，如：RSA 或 ECDHE，解決密鑰交換的問題彼棍。
2. 使用隨機(jī)數(shù)產(chǎn)生對(duì)稱算法使用的“會(huì)話密鑰”（密鑰）灭忠，再用公鑰加密后膳算，傳遞給對(duì)方。
3. 對(duì)方收到密文后用私鑰解密更舞，取出會(huì)話密鑰，這樣雙方就完成了對(duì)稱密鑰的安全交換坎吻，后續(xù)全都使用對(duì)稱加密缆蝉。

好處

• 解決了對(duì)稱加密的密鑰交換問題
• 安全性和性能兼顧，實(shí)現(xiàn)了機(jī)密性

5. 數(shù)字簽名和證書

5.1 數(shù)據(jù)完整性問題和身份認(rèn)證問題

數(shù)據(jù)完整性問題：黑客可以通過竊聽收集足夠多的密文瘦真，再嘗試著修改刊头，重組后發(fā)送給網(wǎng)站，由于沒有完整性驗(yàn)證诸尽，服務(wù)器只會(huì)照單全收原杂。同時(shí)黑客可以通過服務(wù)器的響應(yīng)獲取進(jìn)一步的線索，最終可以破解出明文您机。（針對(duì)服務(wù)端的欺騙）

身份認(rèn)證問題：黑客也可以偽造公鑰穿肄，如果你拿到的是假的公鑰，其銀行卡號(hào)和密碼等敏感信息就在“安全”的通信過程中被竊取了际看。

5.2 摘要算法

作用：實(shí)現(xiàn)數(shù)據(jù)完整性效驗(yàn)咸产。也就是常說的散列函數(shù)、哈希函數(shù)仲闽。

摘要算法是將任意長(zhǎng)度的數(shù)據(jù)“壓縮”成固定長(zhǎng)度脑溢、而且獨(dú)一無二的“摘要”字符串，就好像給這段數(shù)據(jù)生成了一個(gè)數(shù)據(jù)“指紋”赖欣。

同時(shí)屑彻，也可以將它理解為特殊的“單向”加密算法，沒有密鑰顶吮，加密后的數(shù)據(jù)無法解密社牲，不能從摘要逆推出明文。

被 TLS 用來生成偽隨機(jī)數(shù)悴了。

常見的摘要算法

1. MD5（禁止使用）
2. SHA-1（禁止使用）
3. SHA-2（推薦使用）

其中 MD5 和 SHA-1 兩個(gè)算法的安全性比較低膳沽，不夠安全，已經(jīng)被 TLS 里已經(jīng)被禁止使用让禀。

如何保證數(shù)據(jù)的完整性

摘要算法保證數(shù)據(jù)摘要和原文是完全等價(jià)的挑社。我們只需要在原文后附上它的摘要，接收方收到后巡揍，將原文使用同樣的摘要算法生成新的摘要痛阻，然后與發(fā)送端發(fā)過來的摘要進(jìn)行比對(duì)，就能夠保證數(shù)據(jù)的完整性腮敌。

單獨(dú)使用摘要算法存在的問題

黑客竊取了摘要和原文后阱当，將其原文和摘要全部替換成黑客偽造的摘要和原文俏扩，這樣接收方收到后，還是認(rèn)為數(shù)據(jù)是完整的弊添，也就是單獨(dú)使用摘要算法不具有機(jī)密性录淡。

所以，真正的完整性要建立在機(jī)密性之上油坝。

解決機(jī)密性的問題

使用混合加密里用的會(huì)話密鑰嫉戚，將消息和消息摘要進(jìn)行加密，這樣黑客無法得到明文澈圈，就無法動(dòng)手腳了彬檀。

5.3 數(shù)字簽名

數(shù)字簽名的原理：發(fā)送端使用私鑰對(duì)原文通過摘要算法所生成的消息摘要信息和原文進(jìn)行加密，接收端通過公鑰解密來驗(yàn)證發(fā)送端的身份瞬女。

數(shù)字簽名解決的問題

數(shù)字簽名解決通信雙方的身份認(rèn)證問題和不可否認(rèn)問題窍帝。

身份認(rèn)證問題：主要是雙方通過使用公鑰來對(duì)私鑰所加密的原文的摘要信息進(jìn)行解密來完成身份認(rèn)證問題，說明雙方都是最初建立連接時(shí)的兩端诽偷。

不可否認(rèn)問題：同樣的坤学，私鑰只有兩端各自持有，是不會(huì)發(fā)送到網(wǎng)絡(luò)中去的报慕，所以拥峦，具有不可否認(rèn)性。

image

5.4 數(shù)字證書 和 CA

數(shù)字證書

由 CA 機(jī)構(gòu)頒發(fā)的卖子，具有一個(gè)格式的略号，將包含公鑰、序列號(hào)洋闽、用途玄柠、頒發(fā)者、有效時(shí)間 等等信息打成一個(gè)包并通過 CA 機(jī)構(gòu)簽名形成的诫舅。用來證明某寶就是某寶羽利。

數(shù)字證書作用

解決“公鑰信任”問題。也就是如何判斷這個(gè)公鑰是某寶或某東的呢刊懈？也就是在剛建立 SSL 連接時(shí)这弧，如果黑客就冒充了某寶，那你的銀行卡號(hào)和密碼等信息都會(huì)被黑客竊取虚汛。

CA

CA：專門用來頒發(fā)數(shù)字證書的機(jī)構(gòu)匾浪。就好像是網(wǎng)絡(luò)世界里的公安局，教育部和公證中心卷哩。

CA 如何證明自己

小一點(diǎn)的 CA 可以讓大 CA 簽名認(rèn)證蛋辈，但鏈條的最后，也就是 ROOT CA 子就只能自己證明自己了。這個(gè)就叫“自簽名證書” 或者 “根證書”冷溶。

image

操作系統(tǒng)和瀏覽器都內(nèi)置了各大 CA 的根證書渐白，上網(wǎng)的時(shí)候，只要服務(wù)器發(fā)送過來證書逞频，它就可以驗(yàn)證證書里的簽名纯衍，順著證書鏈一層層地驗(yàn)證，直到找到根證書苗胀，再與瀏覽器中內(nèi)置的證書比對(duì)襟诸，就能確認(rèn)證書是否可信了。

瀏覽器為什么會(huì)標(biāo)紅

image

圖上的情況主要是由于網(wǎng)站的數(shù)字證書沒有通過根證書的效驗(yàn)柒巫。如果想讓自簽名的證書也顯示“安全”励堡，可以將片簽名證書放到瀏覽器的根證書存儲(chǔ)區(qū)里谷丸，就不會(huì)再顯示警告了堡掏。

證書體系存在的問題

1. 如果 CA 證書機(jī)構(gòu)被欺騙，簽發(fā)了錯(cuò)誤的證書刨疼，雖然證書是真的泉唁，但是代表的網(wǎng)站卻是假冒的。這種情況一般在發(fā)現(xiàn)問題后揩慕，直接將錯(cuò)誤的證書予以吊銷亭畜。
2. 如果 CA 證書機(jī)構(gòu)被黑，或者 CA 本來就有惡意迎卤，以該 CA 根證書為終點(diǎn)的整條鏈上的證書也都是不可信的了拴鸵。一般是直接在操作系統(tǒng)或者瀏覽器中撤銷對(duì) CA 的信任，列入“黑名單”蜗搔。

6. HTTPS 通信過程

6.1 TLS 協(xié)議組成

TLS 包含幾個(gè)子協(xié)議：

1. 記錄協(xié)議：規(guī)定了 TLS 收發(fā)數(shù)據(jù)的基本單位：記錄（record）劲藐。所有其它的子協(xié)議都是被記錄協(xié)議包裹后發(fā)出，但多個(gè)記錄數(shù)據(jù)可以被打包到一個(gè) TCP segment 報(bào)文里通過 TCP 發(fā)出樟凄。
2. 警報(bào)協(xié)議：向?qū)Ψ桨l(fā)出警報(bào)信息聘芜，有點(diǎn)像是 HTTP 協(xié)議里的狀態(tài)碼。
3. 握手協(xié)議：瀏覽器和服務(wù)器會(huì)在握手過程中協(xié)商 TLS 版本號(hào)缝龄、隨機(jī)數(shù)汰现、密碼套件等信息，然后交換證書和密鑰參數(shù)叔壤，最終雙方協(xié)商得到會(huì)話密鑰瞎饲，用于后續(xù)混合加密系統(tǒng)。
4. 變更密碼規(guī)范協(xié)議：就一個(gè)通知炼绘，告訴對(duì)方企软，后續(xù)的數(shù)據(jù)都將使用加密保護(hù)。在該通知發(fā)送之前饭望，數(shù)據(jù)都是通過明文傳輸?shù)摹?/li>

6.2 使用 wireshark 抓取 HTTPS 包并明文顯示的方法

WINDOWS：

1. 新增一個(gè)系統(tǒng)變量 SSLLOGFILE仗哨，值為設(shè)置瀏覽器日志路徑形庭。如：D:\http\log。

image

2. 在 Wireshark 里設(shè)置 TLS厌漂，并將 1 中設(shè)置的日志路徑導(dǎo)入到 (Pre)-Master-Secret log filename 中去萨醒。
3. 訪問 HTTPS 站點(diǎn)并通過跟蹤 HTTPS 流來進(jìn)行分析。

MAC:

1. 先使用 sudo find / -iname "Google Chrome" 找到 chrome 地址苇倡。

image

2. 設(shè)置 chrome 的 log 目錄富纸。sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ssl-key-log-file=/Users/`whoami`/sslkeylog.log，此時(shí)會(huì)先打開一個(gè)瀏覽器旨椒，直接使用這個(gè)瀏覽器測(cè)試就好晓褪。

3. 在菜單欄 -> Wireshark -> Preferences -> Protocols -> SSL（TLS）
   在(Pre)-Master-Secret log filename 填入剛才啟動(dòng)時(shí)指定的文件路徑。

4. 3. 訪問 HTTPS 站點(diǎn)并通過跟蹤 HTTPS 流來進(jìn)行分析综慎。

6.3 TLS 通信過程

image

上圖中涣仿，每個(gè)框都是一個(gè)記錄，多個(gè)記錄組成一個(gè) TCP 報(bào)文示惊。從圖中可以看到垄提，通過兩次的消息往返（4 個(gè)消息）就可以完成握手罩扇。然后在安全的通信鏈路上發(fā)送 HTTP 報(bào)文，實(shí)現(xiàn) HTTPS 協(xié)議。

通過握手協(xié)議建立連接后锅知，接下來通過會(huì)話密鑰來進(jìn)行 HTTP 報(bào)文加密傳輸阴幌。

================26-1 實(shí)驗(yàn)

未解密之前的 TLS 通信過程

image

解密后的 TLS 通信過程

image

數(shù)據(jù)來源：使用 wireshark 打開 26-1寄纵，并打開首先項(xiàng)并在 PROTOCOLS 里找到 TLS立美，將 26-1.log 日志導(dǎo)入。

image

詳細(xì)通信過程

image

整個(gè)通信過程如下：

1. 客戶端和服務(wù)器通過 TCP 三次握手建立連接隘竭。
2. 瀏覽器首先發(fā)起 Client Hello 消息塘秦，里面包含客戶端 TLS 版本號(hào)、支持的密碼套件和隨機(jī)數(shù) C（用于后續(xù)生成主密鑰）货裹。
3. 服務(wù)器收到 Client Hello 后嗤形，會(huì)返回一個(gè) Server Hello 消息。確認(rèn)一下 TLS 版本號(hào)弧圆，同時(shí)也會(huì)生成一個(gè)新的隨機(jī)數(shù) S赋兵，并從客戶端可用密碼套件里選擇一個(gè)，一起發(fā)送給客戶端搔预。
4. 由于服務(wù)器選擇的是 ECDHE霹期，在證書記錄后面緊跟了一個(gè) Server Key Exchange 消息，里面是 ECC 橢圓曲線 的公鑰拯田，用于實(shí)現(xiàn)“主密鑰”的交換历造。在該記錄的結(jié)尾加上了自己的私鑰簽名認(rèn)證。同時(shí)，在該次 TCP 包的尾部添加了一個(gè) Server Hello Done 的記錄吭产，表示我的信息已經(jīng)發(fā)送完畢侣监。
5. 到此，Client Hello 和 Server Hello 這一來一回（2 個(gè) TCP 包）的通信就完成了臣淤，客戶端和服務(wù)器也共享了 Client Random橄霉、Server Random、Server Params 三個(gè)信息邑蒋。
6. 客戶端在收到了服務(wù)器發(fā)送過來的 Server Hello 包后姓蜂，會(huì)先對(duì)服務(wù)器證書進(jìn)行驗(yàn)證，也就是通過走證書鏈來確認(rèn)證書的真實(shí)性医吊，再用證書公鑰驗(yàn)證簽名來完成對(duì) 服務(wù)器身份的確認(rèn)钱慢。同時(shí)，客戶端按照服務(wù)器選擇的密碼套件的要求卿堂，也生成了一個(gè) ECC 橢圓曲線公鑰束莫，并使用 Client Key Exchange 記錄發(fā)送給服務(wù)器。

image

7. 此時(shí)御吞，客戶端和服務(wù)器就都拿到了密鑰交換算法（EDCHE）的兩個(gè)參數(shù)（Client Params麦箍，Srever Params）漓藕。兩端分別使用 ECDHE 算法進(jìn)行計(jì)算陶珠，并生成了 Pre-Master，其實(shí)就是一個(gè)隨機(jī)數(shù)享钞。生成完成后揍诽，客戶端和服務(wù)端分別有三個(gè)隨機(jī)數(shù)：Client Random、Server Random 和 Pre-Master栗竖。并使用這三個(gè)隨機(jī)數(shù)生成用于加密會(huì)話（HTTP）的主密鑰（會(huì)話密鑰通過主密鑰派生）暑脆，叫做 Master Secret。
8. 有了主密鑰和派生的會(huì)話密鑰后狐肢，客戶端發(fā)一個(gè) Change Cipher Spec 消息添吗，告訴服務(wù)端，后面的數(shù)據(jù)都使用加密傳輸份名。然后再發(fā)送一個(gè) Finish 消息碟联。由于使用的是 ECDHE 密鑰交換協(xié)議，客戶端不需要等待服務(wù)端發(fā)送 Finish 消息就可以直接發(fā)送 HTTP 請(qǐng)求了僵腺。節(jié)省了一個(gè)消息往返帶來的時(shí)間浪費(fèi)鲤孵。
9. 服務(wù)端也是同樣的操作，發(fā)送一個(gè) Change Cipher Spec 消息和一個(gè) Finish 消息辰如。握手結(jié)束普监，后面就收發(fā)加密后的 HTTP 請(qǐng)求和響應(yīng)了。

在 TLS 通信過程中，為什么要 Server Parmas凯正、Client Params 和 Pre-Master 這三個(gè)隨機(jī)數(shù)

這是 TLS 的設(shè)計(jì)者在設(shè)計(jì)過程中毙玻，并不信任客戶端或者服務(wù)端偽隨機(jī)的可靠性，為了保證真正的完全隨機(jī) 而把三個(gè)不可靠的隨機(jī)數(shù)混合起來廊散，進(jìn)一步提升隨機(jī)程度淆珊。下面是 RFC 中的生成會(huì)話密鑰的公式。

master_secret = PRF(pre_master_secret, "master secret",ClientHello.random + ServerHello.random)

雙向認(rèn)證

在上面的交互中奸汇，實(shí)際上只是客戶端對(duì)服務(wù)器的身份進(jìn)行了驗(yàn)證施符，也就是單向驗(yàn)證。如果要實(shí)際雙向認(rèn)證擂找，通過是通過賬號(hào)戳吝、密碼等方式來地客戶端進(jìn)行身份認(rèn)證。

但為了防止賬號(hào)贯涎、密碼被盜听哭、對(duì)安全要求比較高的機(jī)構(gòu)如：銀行，還會(huì)使用 U 盾給客戶頒發(fā)客戶端證書塘雳，實(shí)現(xiàn)雙向認(rèn)證陆盘。

雙向認(rèn)證的執(zhí)行時(shí)機(jī)：只是在 Server Hello Done 之后，客戶端發(fā)送 Client Key Exchange 之前败明，客戶端要發(fā)送 Client Certificate 消息隘马，服務(wù)器通過證書鏈流程來對(duì)客戶端身份進(jìn)行認(rèn)證。

6.4 RSA 握手過程

上面是使用主流的 TLS 1.2 的握手過程妻顶，還有一種相對(duì)傳統(tǒng)一點(diǎn)的握手過程酸员，就是 RSA 握手過程。與 TLS 握手過程相比讳嘱，RSA 有兩點(diǎn)不同：

1. 使用 RSA 實(shí)現(xiàn)密鑰交換幔嗦，而不是 ECDHE，所以沥潭，不會(huì)在服務(wù)端發(fā)出 Server Key Exchange 消息邀泉。
2. 因?yàn)闆]有使用 ECDHE，所以 RSA 在握手過程中钝鸽，需要等待服務(wù)端發(fā)送確認(rèn)握手完畢汇恤，才能發(fā)出 HTTP 報(bào)文。

=========== RSA 握手實(shí)驗(yàn) 26-1 端口：440

image

image

使用 RSA 密鑰交換協(xié)議和 ECDHE 密鑰交換協(xié)議的流程大致沒有變化寞埠，區(qū)別在于：Pre-Master 不再需要算法生成屁置，而是使用客戶端直接生成的隨機(jī)數(shù)。然后仁连，客戶端通過公鑰加密后蓝角，通過 Client Key Exchange 消息發(fā)送給服務(wù)器阱穗。服務(wù)器再用私鑰解密，這樣雙方也實(shí)現(xiàn)了共享三個(gè)隨機(jī)數(shù)使鹅，就可以用來生成主密鑰了揪阶。

7. TLS 1.3

7.1 TLS 1.3 介紹

TLS 1.3 是 2018 年 推出的 HTTPS 通信的安全標(biāo)準(zhǔn)。

TLS 1.3 特點(diǎn)：

1. 兼容 TLS 1.1 和 1.2 版本患朱。通過擴(kuò)展協(xié)議中定義的一系列的 擴(kuò)展字段 來增加新的功能鲁僚，老版本的 TLS 不認(rèn)識(shí)它可以直接忽略。

如何區(qū)分 TLS 1.3 和 TLS 1.2

TLS 1.3 在 Hello 消息后面添加了 supported_versions 擴(kuò)展裁厅，它標(biāo)記了 TLS 的版本號(hào)冰沙，使用它來區(qū)分新老協(xié)議。

image

2. 強(qiáng)化安全执虹。廢除了 DES 對(duì)稱加密算法拓挥；廢除了 CBC 等分組模式；廢除了 MD5袋励，SHA-1 等摘要算法侥啤；廢除了 RSA 等密鑰交換算法。TLS 只保留了 AES茬故，ChaCha20 對(duì)稱加密算法盖灸；分組模式只保留了 GCM、CCM 和 Poly 1305磺芭；摘要算法只能用 SHA256赁炎、SHA384；密鑰交換算法只保留了 ECHDE 和 DHE徘跪。

TLS 中的密碼套件

image

前向安全

就算某一次的請(qǐng)求被黑客破解了甘邀，之前發(fā)生的請(qǐng)求也不會(huì)被黑客破解琅攘。滿足這種條件就被稱為前身安全垮庐。

黑客常常通過 今日截獲，明日破解 的方式來對(duì)那些不滿足 前向安全 的數(shù)據(jù)進(jìn)行全部解密坞琴。

RSA 就是不滿足 前向安全 的密鑰交換算法哨查。而 EDCHE 滿足前向安全。因?yàn)?EDCHE 在每次握手時(shí)都會(huì)生成一對(duì)臨時(shí)的公鑰和私鑰剧辐，每次通信的密鑰都是不同的寒亥，也就是 一次一密。即使黑客花了很大的力氣破解了一次會(huì)話的密鑰荧关，也只是這次通信被攻破溉奕，之前的歷史消息還是安全的。

3. 提升性能忍啤。TLS 1.3 在 1.2 的基礎(chǔ)上刪除了 Key Exchange 消息加勤，在 TLS 1.2 中客戶端和服務(wù)端都需要發(fā)送此消息仙辟，所以，減少了 2RTT 時(shí)間鳄梅。

image

TLS 1.3 是如何實(shí)現(xiàn)減少 2RTT 時(shí)間的

其實(shí)就是利用的擴(kuò)展叠国。客戶端在 Client Hello 消息里直接用 supported_groups 帶上支持的曲線戴尸；使用 ket-share 帶上對(duì)應(yīng)的 客戶端公鑰參數(shù)粟焊，用 signature_algorithms 帶上簽名算法。

服務(wù)器收到后孙蒙，選定一個(gè)曲線和參數(shù)项棠，再用 key-share 擴(kuò)展返回服務(wù)器這邊的公鑰參數(shù)，就實(shí)現(xiàn)了雙方的密鑰交換挎峦，后面的流程就和 1.2 一樣了沾乘。

image

7.2 TLS 1.3 握手過程

image

image

1. 在 TCP 建立連接后，瀏覽器發(fā)送 Client Hello浑测。1.3 為了兼容 1.2 的協(xié)議翅阵，1.2 中使用的版本號(hào)、支持的密碼套件和隨機(jī)數(shù)結(jié)構(gòu)都是一樣的迁央。1.3 的新功能都是通過擴(kuò)展字段實(shí)現(xiàn)的掷匠。如：supported_versions 表示這是 TLS 1.3，supported_groups 表示支持的曲線岖圈，key_share 表示曲線所對(duì)應(yīng)的參數(shù)等讹语。 如果服務(wù)器支持 1.3 的情況下，會(huì)讀取并使用這些擴(kuò)展字段蜂科。如果不支持的話顽决，也可以讀取 1.2 中的協(xié)議字段來進(jìn)行 TLS 1.2 的握手操作。

image

2. 服務(wù)器收到 Client Hello 后导匣，同樣返回 Server Hello 消息才菠，里面包含隨機(jī)數(shù)和密碼套件。

image

3. 到此贡定，瀏覽器和服務(wù)器之間共享了四個(gè)信息：Client Random赋访、 Server Random、Client Params 和 Server Params缓待。服務(wù)器端使用 ECDHE 算出 Pre-Master蚓耽，再用 HKDF 生成主密鑰 Master Secret。
4. 在算出主密鑰后旋炒，服務(wù)器立刻發(fā)出 Change Cipher Spec 消息步悠，比 1.2 提早進(jìn)入了加密通信，后面發(fā)送的證書相關(guān)消息都是加密后發(fā)送的瘫镇。在發(fā)送了證書之后鼎兽，還多了一個(gè) Certificate Verify 消息芹壕，用服務(wù)器的私鑰把前面的曲線、套件接奈、參數(shù)等握手?jǐn)?shù)據(jù)加了簽名踢涌，強(qiáng)化了身份認(rèn)證和防竄改。
5. 瀏覽器在接收到服務(wù)器端證書之后序宦，驗(yàn)證證書和簽名睁壁，驗(yàn)證通過后，同樣的互捌，使用 ECDHE 生成 Pre-Master潘明，然后，使用 隨機(jī)數(shù) C/S 加 Pre-Master 生成主密鑰秕噪。并向服務(wù)器發(fā)送 Change Cipher Spec 消息钳降，表示后面的通信客戶端都會(huì)通過加密后傳輸。最后腌巾，發(fā)送 Finish 消息遂填，到此，整個(gè)握手過程就完成了澈蝙。
6. 客戶端和服務(wù)器開始傳輸加密后的 HTTP 協(xié)議進(jìn)行通信了吓坚。

7.3 TLS 1.2 和 TLS 1.3 的區(qū)別

1. 握手過程中所傳輸包的數(shù)量不同。TLS 1.2 通過四次握手灯荧，四個(gè) TCP 包才完成整個(gè)握手過程礁击，而 TLS 1.3 使用三次握手，也就是三個(gè) TCP 包就完成了整個(gè)握手過程逗载。
2. 加密傳輸數(shù)據(jù)的時(shí)機(jī)不同哆窿。TLS 1.2 服務(wù)端是在收到了客戶端發(fā)送過來的 Client Key Exchange 消息和 Finish 消息后，才發(fā)送 Change Cipher Spec 消息并進(jìn)入加密通信階段厉斟。而 TLS 1.3 是服務(wù)器在發(fā)送 Server Hello 后就立即進(jìn)入了加密通信階段挚躯。
3. 密碼套件中的算法數(shù)量不同。在 TLS 1.2 中的密碼套件達(dá)到 18 種之多捏膨，而在 TLS 1.3 中將一些不安全的密碼套件進(jìn)行了清理秧均，并對(duì)其做了大量的精簡(jiǎn)后，只剩下 5 種号涯。
4. 服務(wù)器 CA 證書被傳遞的方式不同。在 1.2 中使用的是明文傳輸锯七，第一個(gè)被加密傳輸?shù)南⑹?Finished 消息链快。而在 1.3 中 CA 證書是緊隨 Change Cipher Spec 之后的，是第二個(gè)被加密傳輸?shù)南ⅰ?/li>

8. HTTPS 優(yōu)化

8.1 HTTPS 慢的原因是什么眉尸？

HTTPS 通信包括兩個(gè)部分域蜗，第一部分是建立連接時(shí)的非對(duì)稱加密握手巨双，另一部分是連接建立完成后的對(duì)稱加密報(bào)文傳輸。

由于在對(duì)稱加密報(bào)文傳輸過程中霉祸，使用的 AES 加密方式已經(jīng)非持郏快了，報(bào)文傳輸過程中所帶來的性能損耗幾乎可以忽略不計(jì)丝蹭。所以慢宗，通過說 HTTPS 慢主要是在非對(duì)稱加密握手這部分。

在 TCP 連接建立后奔穿，正式通信之前镜沽，HTTPS 相比 HTTP 增加了一個(gè) TLS 握手的步驟，這個(gè)過程通常要花費(fèi)兩個(gè)消息往返贱田，也就是 2-RTT缅茉。而且除了網(wǎng)絡(luò)超時(shí)的耗時(shí)之外，還有些其它的損耗男摧，如：

1. 產(chǎn)生用于密鑰交換的臨時(shí)密鑰對(duì)蔬墩。
2. 驗(yàn)證證書時(shí)訪問 CA 獲取 CRL 或者 OCSP。
3. 非對(duì)稱加密解密處理 Pre-Master耗拓。

總的來說筹我，HTTP 建立連接相比 HTTP 會(huì)慢上幾百毫秒到幾秒，就會(huì)讓人產(chǎn)生“打開一個(gè) HTTPS 網(wǎng)絡(luò)很慢”的感覺帆离。

8.2 HTTPS 會(huì)導(dǎo)致慢的點(diǎn)

image

8.3 HTTPS 優(yōu)化

硬件優(yōu)化

1. 選擇更快的 CPU蔬蕊，最好是內(nèi)建 AES 優(yōu)化的。
2. 使用 SSL 加速卡哥谷，通過硬件來對(duì)做非對(duì)稱加解密岸夯。
3. 選擇 SSL 加速服務(wù)器。

軟件優(yōu)化

1. 及時(shí)進(jìn)行軟件升級(jí)们妥，比如：Nginx 的升級(jí)或 OpenSSL 的升級(jí)猜扮。因?yàn)檫@些軟件在通常的升級(jí)過程中，都會(huì)進(jìn)行性能優(yōu)化方面的工作监婶。

協(xié)議優(yōu)化

1. 盡量使用 TLS 1.3 協(xié)議旅赢，因?yàn)?TLS 1.3 大幅簡(jiǎn)化了握手過程，完成握手只需要 1-RTT 時(shí)間惑惶。
2. 如果只能使用 TLS 1.2 的情況下煮盼，盡量選用橢圓曲線的 ECDHE 算法。運(yùn)算速度更快且安全性更高带污。
3. 橢圓曲線選擇高性能的曲線僵控，最好是 X25519 或者 P-256。對(duì)稱加密算法方面鱼冀，選擇 AES-128-GCM 或者 AES-128-GCM报破。

證書優(yōu)化

1. 服務(wù)器的證書類型選擇橢圓曲線證書而不是 RSA 證書悠就。因?yàn)?224 的 ECC 相當(dāng)于 2048 位的 RSA。

客戶端的證書驗(yàn)證過程：除了要使用公鑰驗(yàn)證多個(gè)證書的簽名外充易，因?yàn)檫€有可能會(huì)被撤銷失效梗脾，客戶端有時(shí)還需要去訪問 CA，下載 CRL 或者 OCSP 數(shù)據(jù)盹靴，這又會(huì)增加幾個(gè) RTT 通信時(shí)間炸茧。

CRL（證書吊銷列表）：由 CA 定期發(fā)布，里面包含所有被撤銷信任的證書序號(hào)鹉究∮盍ⅲ客戶端需要定期去下載這個(gè)列表，而一般 CRL 會(huì)達(dá)到 MB自赔，所以妈嘹，每次下載 CRL 會(huì)浪費(fèi)客戶端大量的時(shí)間。現(xiàn)在這種方式基本被淘汰了绍妨。

OCSP（在線證書驗(yàn)證協(xié)議）：向 CA 直接發(fā)送請(qǐng)求润脸，進(jìn)行驗(yàn)證。

OCSP Staping（OCSP 裝訂）：讓服務(wù)器先預(yù)先訪問 CA 獲取 OCSP 響應(yīng)他去，然后在握手的時(shí)候毙驯，直接將響應(yīng)結(jié)果發(fā)給客戶端。

會(huì)話復(fù)用

1. Session ID 復(fù)用灾测。就是客戶端和服務(wù)器首次連接后各自保存一個(gè)會(huì)話的 ID 號(hào)爆价，內(nèi)存里存儲(chǔ)主密鑰和相關(guān)信息。當(dāng)客戶端請(qǐng)求時(shí)發(fā)送一個(gè) ID 過來媳搪，服務(wù)器在內(nèi)存中通過 ID 進(jìn)行查找铭段，如果找到，則直接通過主密鑰恢復(fù)會(huì)話秦爆，而跳過了證書驗(yàn)證和密鑰交換序愚，只用一個(gè)消息往返就可以建立安全通信。

存在問題：服務(wù)器必須保存每一個(gè)客戶端的會(huì)話數(shù)據(jù)等限，對(duì)于擁有百萬(wàn)爸吮、千萬(wàn)級(jí)別用戶的網(wǎng)站來說，對(duì)資源的消耗就成為了一個(gè)問題望门。

2. Session Ticket形娇。類似于 HTTP Cookie 技術(shù)，由客戶端來存儲(chǔ)會(huì)話信息怒允。服務(wù)器將加密后的會(huì)話信息埂软，用 New Session Ticket 消息發(fā)送給客戶端，讓客戶端來保存纫事。重連的時(shí)候勘畔，客戶端會(huì)通過 session_ticket 擴(kuò)展字段發(fā)送 Ticket，服務(wù)器在收到 Ticket丽惶，驗(yàn)證有效期后炫七，就可以恢復(fù)會(huì)話，開始加密通信钾唬。

False Start万哪、Session ID、Session Ticket 等方式只能實(shí)現(xiàn) 1-RTT抡秆，而 TLS 1.3 可以通過預(yù)共享密鑰的方式實(shí)現(xiàn) 0-RTT奕巍。

Pre-shared Key 預(yù)共享密鑰

本質(zhì)上和 Ticket 差不多，只是在發(fā)送 Ticket 的同時(shí)攜帶了應(yīng)用數(shù)據(jù)儒士，免去了需要等待服務(wù)器驗(yàn)證通過了再發(fā)送數(shù)據(jù)的步驟的止。

9. HTTPS 遷移

9.1 遷移 HTTPS 的必要性

1. 移動(dòng)平臺(tái)如： Apple、Android着撩、微信等開發(fā)平臺(tái)在 2017 年就要求所有應(yīng)用必須使用 HTTPS 連接诅福。
2. 主流瀏覽器如：Chrome、Firefox拖叙，很早就將 HTTP 站點(diǎn)標(biāo)記為不安全的站點(diǎn)氓润。
3. Google 還降低了 HTTP 站點(diǎn)的排名，力圖讓網(wǎng)民只訪問到 HTTPS 的站點(diǎn)薯鳍。

9.2 申請(qǐng)證書

1. 大型公司通常會(huì)向傳統(tǒng)的 CA 申請(qǐng)證書咖气，如：Digicert，GlobalSign挖滤。
2. 中小型企業(yè)可以通過 Let's Encrypt 平臺(tái)來申請(qǐng)免費(fèi)的證書崩溪。

申請(qǐng)證書注意事項(xiàng)

1. 申請(qǐng)證書應(yīng)該同時(shí)使用 RSA 和 ECDSA 兩種證書。并在 Ngnix 里配置雙證書驗(yàn)證壶辜，讓服務(wù)器可以根據(jù)客戶端的需求靈活選擇哪種證書作為認(rèn)證的方式悯舟。
2. 為了保證安全，如果申請(qǐng) RSA 證書時(shí)砸民，私鑰至少是 2048 位抵怎，而且摘要算法應(yīng)該選用 SHA-2。