【4】ShutdownHTTP系列-HTTPS篇
Shutdown HTTP系列介紹
之前，有一位大佬和我說過這么一句話："網(wǎng)絡(luò)知識在一定程度上決定了你的上限"。
對HTTP一知半解的我，上限真的這么低嗎...就不能花點時間好好整理整理嗎 ??？
這次請給霖呆呆一個機(jī)會，跟著我的腳步?從1開始學(xué)習(xí)它。另外我整理的HTTP系列基本都會附有一個面試時的淺答與深答的配套答案，淺答是為了讓你們更好的記住，深答保證你確實理解了淺答中的知識點。
整個系列下來，讓我們徹底 Shutdown HTTP ?。?！?
系列思維導(dǎo)圖：
系列目錄：
《?【1】Shutdown HTTP系列-基礎(chǔ)篇》 《?【2】Shutdown HTTP系列-HTTP報文篇》 《?【3】Shutdown HTTP系列-Cookie篇》 《?【4】Shutdown HTTP系列-HTTPS篇》「本文」 《?【5】Shutdown HTTP系列-CCPG篇》 《?【6】Shutdown HTTP面試系列》
所有文章內(nèi)容都已整理至 LinDaiDai/niubility-coding-js 快來給我Star呀?~
https://github.com/LinDaiDai/niubility-coding-js
本篇目錄
通過閱讀本篇文章你可以學(xué)習(xí)到：
HTTPS概念 相比于HTTP的優(yōu)勢/為什么需要HTTPS HTTP與HTTPS的區(qū)別 具體解決方式 SSL/TLS 為何不是所有網(wǎng)站都用HTTPS
1. HTTPS概念
HTTPS它并非是一種新的協(xié)議，只是通信接口部分用SSL或者TLS協(xié)議替代(在HTTP和TCP之間建立中間層)。
換句話說HTTPS其實就是身披SSL協(xié)議這層外殼的HTTP。
可以理解為：
HTTPS?=?HTTP?+?SSL/TLS
2. 相比于HTTP的優(yōu)勢/為什么需要HTTPS
其實也就是彌補(bǔ)了HTTP的缺點：
數(shù)據(jù)隱私性，內(nèi)容經(jīng)過對稱加密； 數(shù)據(jù)完整性，內(nèi)容經(jīng)過完整性校驗； 身份認(rèn)證，第三方無法偽裝客戶端/服務(wù)器的身份
3. HTTP與HTTPS的區(qū)別
可以從這幾個方面來看：
HTTPS標(biāo)準(zhǔn)端口443，HTTP是80 HTTPS基于傳輸層，HTTP基于應(yīng)用層 HTTPS在瀏覽器上會顯示綠色的安全鎖，而HTTP沒有 彌補(bǔ)了HTTP的缺點，數(shù)據(jù)的隱私性、完整性、身份驗證。也就是更加安全。
4. 具體解決方式
對于HTTPS具體的解決方式，我認(rèn)為還是得圍繞它的功能來看：
解決內(nèi)容被竊聽（加解密） 解決內(nèi)容被篡改（數(shù)字簽名） 解決通信方身份遭偽裝（數(shù)字證書）
這塊的內(nèi)容還是很多的，讓我們來分別看看。
4.1 解決內(nèi)容被竊聽(加解密)
4.1.1 對稱密鑰加密(共享密鑰加密)
概念：是最簡單的加密方式，指加密解密用的都是相同的密鑰。
過程：
發(fā)送秘文的一方把通過密鑰加密的內(nèi)容(也就是秘文)和這個密鑰一起發(fā)送給接收方；
接收方接到之后用這個密鑰把秘文解密得到里面的內(nèi)容
優(yōu)點：
加解密效率很快
缺點：
并不安全，只要拿到密鑰任何人都能解密
4.1.2 非對稱密鑰加密(公開密鑰加密)
概念：使用一對非對稱的密鑰，也就是會有兩把密鑰，一把是私鑰(只有自己才能有)，一把是公鑰(可以發(fā)布給任何人)，用私鑰加密的數(shù)包只有公鑰能解，用公鑰加密的數(shù)據(jù)包只有私鑰能解。
過程：發(fā)送秘文的一方用"對方的公鑰"對信息進(jìn)行加密，對方收到被加密的信息后再用自己的私鑰進(jìn)行解密。
特點：信息傳輸一對多，服務(wù)器只需要維持好一個私鑰就能和多個客戶端進(jìn)行加密通信。
優(yōu)點：
使得傳輸內(nèi)容不能被破解。例如如果是公鑰加密的數(shù)據(jù)，就算第三方截獲了這個數(shù)據(jù)但是沒有對應(yīng)的私鑰也破解不了。
缺點：
公鑰是公開的，誰都可以獲取，那么如果發(fā)送的加密信息是通過私鑰加密的話，有公鑰的黑客就可以用這個公鑰來解密拿到里面的信息。 公鑰并不包含服務(wù)器的信息，使用非對稱加密算法并不能確保服務(wù)器身份的合法性?？赡艽嬖谥虚g人攻擊，也就是服務(wù)器發(fā)送給客戶端的公鑰可能在途中被人截獲篡改。 在數(shù)據(jù)加解密的時候需要消耗一定的時間 降低了數(shù)據(jù)傳輸?shù)男省?/section>
4.1.3 混合加密機(jī)制(HTTPS采用的方式)
概念：結(jié)合兩種加密方式的優(yōu)點，在交換密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段使用對稱加密方式。
流程：發(fā)送密文的一方使用"對方的公鑰"進(jìn)行加密處理"對稱的密鑰"，然后對方接收到之后使用自己的私鑰進(jìn)行解密得到"對稱的密鑰"，這就達(dá)到了確保交換的密鑰是安全的前提下使用對稱加密方式進(jìn)行通信。
「Q1：那混合加密機(jī)制的好處是什么呢？」
難度：??
剛剛已經(jīng)說到了對稱密鑰加密和非對稱密鑰加密都有它們各種的優(yōu)缺點，而混合加密機(jī)制就是將兩者結(jié)合利用它們各自的優(yōu)點來進(jìn)行加密傳輸。
比如既然對稱密鑰的優(yōu)點是加解密效率快，那么在客戶端與服務(wù)端確定了連接之后就可以用它來進(jìn)行加密傳輸。不過前提是得解決雙方都能安全的拿到這把對稱密鑰。這時候就可以利用非對稱密鑰加密來傳輸這把對稱密鑰，因為我們知道非對稱密鑰加密的優(yōu)點就是能保證傳輸?shù)膬?nèi)容是安全的。
所以它的好處是即保證了對稱密鑰能在雙方之間安全的傳輸，又能使用對稱加密方式進(jìn)行通信，這比單純的使用非對稱加密通信快了很多。以此來解決了HTTP中內(nèi)容可能被竊聽的問題。
「Q2：那混合加密的缺點呢？」
難度：??
混合加密主要是為了解決HTTP中內(nèi)容可能被竊聽的問題。但是它并不能保證數(shù)據(jù)的完整性，也就是說在傳輸?shù)臅r候數(shù)據(jù)是有可能被第三方篡改的，比如完全替換掉，所以說它并不能校驗數(shù)據(jù)的完整性。如果需要做到這一點就需要使用到數(shù)字簽名。
4.1.4 HTTPS的工作流程
（簡單的敘述，如果面試官要聽具體的過程可以看文章后續(xù)部分的 4.2 幾種版本的握手）
難度：???
HTTPS主要是采用對稱密鑰加密和非對稱密鑰加密組合而成的混合加密機(jī)制進(jìn)行傳輸。
也就是發(fā)送密文的一方用"對方的公鑰"進(jìn)行加密處理"對稱的密鑰"，然后對方在收到之后使用自己的私鑰進(jìn)行解密得到"對稱的密鑰"，這在確保雙發(fā)交換的密鑰是安全的前提下使用對稱密鑰方式進(jìn)行通信。
這個過程簡單來說就是：
客戶端首先向服務(wù)端發(fā)送一個HTTPS請求 服務(wù)端會把事先配置好的公鑰證書隨著其它的信息返回給客戶端 客戶端在收到服務(wù)端發(fā)來的證書之后進(jìn)行驗證，驗證的過程參考數(shù)字證書驗證，會得到服務(wù)端的信息以及它的公鑰 驗證成功之后生成一個叫做 client_params 的參數(shù)發(fā)送給服務(wù)器；同時自己會用偽隨機(jī)函數(shù)生成一個 secret，這個secret就是它們后續(xù)進(jìn)行通信的對稱密鑰。 服務(wù)器在收到剛剛的 client_params之后，也會根據(jù)偽隨機(jī)函數(shù)生成一個secret。這時候雙方都有了相同的對稱密鑰。 后面的傳輸都會用這個 secret 進(jìn)行對稱密鑰加解密傳輸
4.1.5 對稱密鑰加密和非對稱密鑰加密的區(qū)別
難度：??
對稱密鑰加密是最簡單的一種加密方式，它的加解密用的都是相同的密鑰，這樣帶來的好處就是加解密效率很快，但是并不安全，如果有人拿到了這把密鑰那誰都可以進(jìn)行解密了。
而非對稱密鑰會有兩把密鑰，一把是私鑰，只有自己才有；一把是公鑰，可以發(fā)布給任何人。并且加密的內(nèi)容只有相匹配的密鑰才能解。這樣帶來的一個好處就是能保證傳輸?shù)膬?nèi)容是安全的，因為例如如果是公鑰加密的數(shù)據(jù)，就算是第三方截取了這個數(shù)據(jù)但是沒有對應(yīng)的私鑰也破解不了。不過它也有缺點，一是公鑰因為是公開的，誰都可以過去，如果內(nèi)容是通過私鑰加密的話，那擁有對應(yīng)公鑰的黑客就可以用這個公鑰來進(jìn)行解密得到里面的信息；二來公鑰里并沒有包含服務(wù)器的信息，也就是并不能確保服務(wù)器身份的合法性；并且非對稱加密的時候要消耗一定的時間，減低了數(shù)據(jù)的傳輸效率。
4.2 解決內(nèi)容被篡改(數(shù)字簽名)
4.2.1 一些基本概念
數(shù)字簽名的產(chǎn)生原因：雖然有了混合加密機(jī)制保證了內(nèi)容不被監(jiān)聽，但是傳輸?shù)臄?shù)據(jù)可能會被篡改(比如完全替換掉)，即不能校驗數(shù)據(jù)的完整性。而數(shù)字簽名就是為了校驗數(shù)據(jù)的完整性。
功能特點：
能確定消息確實是發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。 能確定內(nèi)容的完整性，證明數(shù)據(jù)沒有被篡改過。
Hash函數(shù)：
也就是哈希函數(shù)，哈希摘要函數(shù)，散列函數(shù)。 簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數(shù)。
4.2.2 數(shù)字簽名的具體過程
（數(shù)字簽名的概念以及驗證流程）
難度：???
數(shù)字簽名的產(chǎn)生主要就是為了解決HTTP中內(nèi)容可能被篡改的問題，即校驗數(shù)據(jù)的完整性。它能確定消息是發(fā)送方發(fā)送過來的，因為這里會有一個驗證數(shù)字簽名的過程，別人是假冒不了發(fā)送方的簽名的。
數(shù)字簽名它是什么呢？它的產(chǎn)生過程其實就是兩步，第一步將原文用Hash函數(shù)生成一個叫消息摘要的東西，第二步就是用發(fā)送方的私鑰對這個消息摘要進(jìn)行進(jìn)行加密。這個產(chǎn)生的東西就叫做數(shù)字簽名，它一般會與原文一起發(fā)送給接收者。
而驗證它的過程其實也并不復(fù)雜。
首先發(fā)送方會將原文與數(shù)字簽名(也就是加密后的摘要)一起發(fā)送給接收方 接收方會接收到這兩樣?xùn)|西，即原文和數(shù)字簽名 接收方用Hash函數(shù)處理原文會得到一份消息摘要 同時用發(fā)送方的公鑰解密數(shù)字簽名也會得到一份消息摘要 只要比較這兩份消息摘要是否相等就可以驗證出數(shù)據(jù)有沒有被篡改了
當(dāng)然這里關(guān)鍵的一步就是要保證發(fā)送方傳遞過來的公鑰是可信賴的，這時候就得用到數(shù)字證書了。
讓我們來看看數(shù)據(jù)簽名的流程圖：
4.3 解決通信方身份遭偽裝(數(shù)字證書)
4.3.1 數(shù)字證書的概念
難度：???
數(shù)字證書也叫公鑰證書，或者簡稱證書。它主要是為了解決通信方身份遭偽裝的問題，也就是驗證通信方的身份。
因為我們知道在HTTPS中雖然有了混合加密機(jī)制保證數(shù)據(jù)不被監(jiān)聽，有了數(shù)字簽名校驗數(shù)據(jù)的完整性，但是數(shù)字簽名校驗的前提是能拿到發(fā)送方的公鑰，并且保證這個公鑰是可信賴的，所以就需要數(shù)字證書。
它簡單來說其實是由一些權(quán)威的數(shù)字認(rèn)證機(jī)構(gòu)頒發(fā)給服務(wù)器的一個文件。數(shù)字認(rèn)證機(jī)構(gòu)簡稱CA，它是客戶端和服務(wù)端都信任的第三方機(jī)構(gòu)，我知道比較有名的一個就是威瑞信(VeriSign)。
4.3.2 數(shù)字證書的頒發(fā)流程
服務(wù)器的運營人員會向認(rèn)證機(jī)構(gòu)提交自己的公鑰、組織信息、個人信息等并申請認(rèn)證 而認(rèn)證機(jī)構(gòu)在拿到這些信息后會通過線上、線下各種途徑驗證申請者提交信息的真實性 在確認(rèn)其真實性后，認(rèn)證機(jī)構(gòu)給這些信息(申請者的公鑰，組織信息，個人信息以及認(rèn)證機(jī)構(gòu)自己的信息等)，我們簡稱為明文信息，進(jìn)行數(shù)字簽名，過程也就是簽名提到的數(shù)字簽名的步驟： 1.通過Hash函數(shù)處理明文信息生成一個信息摘要； 2.再用認(rèn)證機(jī)構(gòu)自己的私鑰對信息摘要進(jìn)行加密處理。 通過這兩個步驟生成的文件就叫數(shù)字簽名。 之后會將明文信息和數(shù)字簽名組合而成的證書頒發(fā)給申請者，也就是服務(wù)器。
我畫了證書的頒發(fā)流程：
（如果上面的圖片加載不出來，可以看這里：https://hexo-blog-1256114407.cos.ap-shenzhen-fsi.myqcloud.com/%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6.png）
4.3.3 證書的組成
主要由兩部分組成：
明文信息 申請者的公鑰 申請者的組織信息、個人信息 簽發(fā)機(jī)構(gòu)CA的信息 有效時間、證書序列號等明文信息 簽名 它的產(chǎn)生過程其實就是上面介紹到的數(shù)字簽名的產(chǎn)生 產(chǎn)生過程：CA先是通過Hash函數(shù)對公開的明文信息做處理生成一個信息摘要，接著用自己的私鑰對信息摘要加密生成簽名。
這些明文信息和這個簽名組合起來就叫做證書，認(rèn)證機(jī)構(gòu)會把證書頒發(fā)給申請者(服務(wù)器)。
4.3.4 為什么說數(shù)字證書就能對通信方的身份進(jìn)行驗證呢？
（數(shù)字證書使得瀏覽器能驗證服務(wù)器，還有它的驗證過程）
難度：???
那是因為在客戶端第一次給服務(wù)端發(fā)送HTTPS請求的時候，服務(wù)端會將它自己的證書隨著其它的信息(例如server_random、 server_params、需要使用的加密套件等東西)一起返給客戶端。
客戶端在收到之后首先會驗證這個證書，只有驗證通過之后才會有后續(xù)操作。而驗證的過程其實也就是數(shù)字簽名的驗證過程(題5)：
前面說過了，證書其實是由明文信息(申請者的公鑰，組織信息，個人信息以及認(rèn)證機(jī)構(gòu)自己的信息等)和這個明文信息的數(shù)字簽名組成的。(對應(yīng)著題5也就是原文和數(shù)字簽名) 客戶端會用Hash函數(shù)處理明文信息生成一個信息摘要 然后再用內(nèi)置在瀏覽器上的「CA的公鑰」來解密證書里的數(shù)字簽名，得到一個信息摘要。因為我們知道證書實際是由CA頒發(fā)給服務(wù)器的，并且里面的數(shù)字簽名也是用的CA的私鑰加密的，所以只有CA的公鑰才能解。 最后再將兩個信息摘要進(jìn)行對比，若是一樣則能保證通信方的身份是正確的。
其實驗證證書的過程不僅僅是數(shù)字簽名的驗證，客戶端還會驗證證書相關(guān)的域名信息，有效時間，是不是在CRL吊銷列表里，以及它的上一級是否有效等等。
（一般答到這里就可以了，如果面試官繼續(xù)問你上一級是否有效這樣驗證，你就回答：這是一個遞歸的過程，直到驗證到根證書也就是操作系統(tǒng)內(nèi)置的Root證書或者瀏覽器內(nèi)置的Root證書為止）
就像前面說的，只有能用「CA的公鑰」解密的數(shù)字簽名并且通過了認(rèn)證的證書才是有效的，因為證書是CA頒布的。這也就保證了客戶端收到的服務(wù)器發(fā)來的公鑰是真實可用的(因為公鑰在證書的明文信息里)。
（想想其實很好理解，因為瀏覽器它自己沒有辨別證書是否合法的能力，它就把這事交給CA去做，CA是信任的過的機(jī)構(gòu)，它只要把自己的公鑰內(nèi)嵌到瀏覽器里，瀏覽器再用這個CA公鑰來解證書里的簽名就可以了。而證書的簽名也是經(jīng)過CA的私鑰加密生成的，只有CA的公鑰能解，但它的公鑰又不是隨便人能拿到的，只有各大瀏覽器廠商才有，所以這就是數(shù)字證書的驗證過程）
5. SSL/TLS
5.1 基本概念
SSL 安全套接層(Secure Sockets Layer)
TSL 傳輸層安全(Transport Layer Security)
「版本：」
SSL出過三個大版本，在第三個版本的時候被標(biāo)準(zhǔn)化成為 TLS，并被當(dāng)成 TLS的第一個版本，即：
SSL3.1?=?TLS1.0
之前的TLS1.0、TLS1.1都被認(rèn)為是不安全的，當(dāng)前主流版本是TLS1.2，2018年推出了更優(yōu)秀的TSL1.3。
5.2 幾種版本的握手
在HTTPS加密傳輸中，實際上涉及到 SSL/TLS 協(xié)議，這里是有一個TSL握手的過程。主要是分為了兩部分：
傳統(tǒng)的TLS握手也就是RSA握手； 現(xiàn)在主流的TLS1.2版本的握手，也就是ECDHE握手。
面試時可以表示自己都知道這兩類握手，不過如果要挑一個說的話，個人認(rèn)為可以介紹一下現(xiàn)在主流的TLS1.2版本的握手，請看下面的4.2.1。
5.2.1 主流的TLS1.2版本的握手，即ECDHE握手
難度：????
它的過程大致來說是這樣的：
客戶端在第一次發(fā)送HTTPS請求的時候，會把 client_random、TSL版本號、加密套件列表發(fā)送給服務(wù)器
服務(wù)器在接收到之后確認(rèn)TSL的版本號，同時發(fā)送 server_random、server_params、需要使用的加密套件、以及自己的證書給客戶端
客戶端在收到這些信息之后，首先是會對服務(wù)器的證書進(jìn)行驗證(也就是題目7)，若是驗證成功則會傳遞一個 client_params 給服務(wù)器
與此同時客戶端會通過「ECDHE算法」計算出一個pre_random，其中是傳入了兩個參數(shù)，一個是 client_params，還一個是 server_params。(也就是說：ECDHE(client_params, server_params) = per_random)
這時候客戶端就同時擁有了 client_random、server_random、pre_random，它會將這三個參數(shù)通過一個「偽隨機(jī)函數(shù)」計算得出最終的secret，這個secret就是它們后續(xù)通信所要用的對稱密鑰。
而在客戶端生成完secret之后，會給服務(wù)器發(fā)送一個收尾消息，告訴服務(wù)器之后都要用對稱加密，且對稱加密的算法是用第一次約定好的。
服務(wù)器它在接收到剛剛傳遞過來的client_params之后，也會使用和客戶端一樣的方式生成secret，并且也會發(fā)送一個收尾消息給客戶端。
當(dāng)雙方都收到收尾消息并驗證成功之后，握手就結(jié)束了。后面開始用這個secret對稱密鑰加密報文進(jìn)行傳輸。
（ECDHE基于「橢圓曲線離散對數(shù)」，傳入的兩個參數(shù)也被叫做「橢圓曲線的公鑰」）
（此時面試官如果要問你RSA握手的細(xì)節(jié)就看題目 4.2.2和 4.2.3。如果不的話可能會問你RSA握手和ECDHE握手的區(qū)別，就看題目4.2.4）
5.2.2 可我就是想你描述一下RSA握手
（這道題主要是怕面試官還想你再描述一下RSA握手，當(dāng)然你也可以先用這個簡單的版本說給他聽，詳細(xì)描述看題4.2.3）
難度：???
客戶端首先向服務(wù)端發(fā)送一個HTTPS請求 服務(wù)端會把事先配置好的公鑰證書隨著其它的信息返回給客戶端 客戶端在收到服務(wù)端發(fā)來的證書之后進(jìn)行驗證，驗證的過程參考數(shù)字證書驗證，會得到服務(wù)端的信息以及它的公鑰 驗證成功之后會用「偽隨機(jī)函數(shù)」計算出一個加密所需要的對稱密鑰(secret)，并且用服務(wù)端的公鑰加密這個對稱密鑰發(fā)送給服務(wù)端 服務(wù)端再用自己的私鑰解密剛剛的消息，得到里面的對稱密鑰。此時服務(wù)端和客戶端都有了對稱密鑰。 后面的傳輸都會用這個 secret 進(jìn)行對稱密鑰加解密傳輸
5.2.3 能否詳細(xì)描述一下RSA握手呢？
（還問你細(xì)節(jié)的話...就用這套）
難度：????
客戶端首先發(fā)送 client_random、TSL版本號、加密套件列表給服務(wù)器 服務(wù)器在接收到之后確認(rèn)TSL版本號，同時發(fā)送server_random、需要使用的加密套件、自己的證書給客戶端 客戶端在收到這些信息之后，首先是會對服務(wù)器的證書進(jìn)行驗證(也就是題目7)，若是驗證成功則會用RSA算法生成一個pre_random，且用服務(wù)器的公鑰(在證書中)加密pre_random發(fā)送給服務(wù)器。 此時，客戶端有了 client_random、server_random、pre_random，它會將這三個參數(shù)通過一個「偽隨機(jī)函數(shù)」計算得出最終的secret，這個secret就是它們后續(xù)通信所要用的對稱密鑰。 服務(wù)器接收到了剛剛用自己公鑰加密的pre_random之后，用自己的私鑰進(jìn)行解密，得到里面的 ?pre_random，用和客戶端一樣的方式生成secret。 之后就用這個 secret對稱密鑰加密報文傳輸。
（可以和4.2.1做一個對比，你很容易就可以看出，只是 step3 ，4，5不同而已）
5.2.4 那么ECDHE握手和RSA握手又有什么區(qū)別呢？
難度：???
它們的區(qū)別主要是：
生成secret(對稱密鑰)的過程不同。RSA中是使用RSA算法生成一個pre_random并用服務(wù)器的公鑰加pre_random發(fā)送給服務(wù)器，然后各自用偽隨機(jī)函數(shù)生成相同的secret對稱密鑰；而在ECDHE握手中，它沒有用到RSA算法，而是用ECDHE算法生成的pre_random，且這個過程中比RSA多了client_params和server_params兩個參數(shù)。 在生成完secret之后，ECDHE握手在客戶端發(fā)送完收尾消息后可以提前 搶跑，直接發(fā)送 HTTP 報文，節(jié)省了一個 RTT，不必等到收尾消息到達(dá)服務(wù)器，然后等服務(wù)器返回收尾消息給自己，直接開始發(fā)請求。這也叫TLS False Start。最主要的：RSA不具備向前安全性，ECDHE有
（向前安全性：一次破解并不影響歷史信息的性質(zhì)就是向前安全性）
5.2.5 向前安全性
難度：??
一句話概括：一次破解并不影響歷史信息的性質(zhì)就是向前安全性。
比如在RSA握手的過程中，客戶端拿到了服務(wù)端的公鑰，然后用此公鑰加密pre_random給服務(wù)端。如果此時有第三方有服務(wù)端的私鑰，并且截獲了之前所有報文的時候，那么它就可以破解這段密文并拿到pre_random、client_random、server_random并根據(jù)對應(yīng)的偽隨機(jī)函數(shù)生成secret，即拿到了最終通信的對稱密鑰，每一個歷史報文都能通過這樣的方式進(jìn)行破解。它就不具有向前安全性。
但是ECDHE在每次握手的時候都會產(chǎn)生一個零時的密鑰對(也就是client_params、server_params)，即使第三方有了私鑰能破解，但是對之前的歷史報文并沒有影響。它就具有向前安全性。
5.3 TSL1.3版本嗎？它較TSL1.2做了哪些改進(jìn)
難度：??
TSL1.3版本是2018年推出的。它較TSL1.2主要是做了以下改進(jìn)：
強(qiáng)化安全
廢除了很多的加密算法，只保留了5個加密套件。其中最主要的是廢棄了RSA，因為在2015年發(fā)現(xiàn)了PRAEK攻擊，即已經(jīng)有人發(fā)現(xiàn)了RSA的漏洞能進(jìn)行破解；而且RSA不具備向前安全性。
提高性能
同時利用會話復(fù)用節(jié)省了重新生成密鑰的時間，利用 PSK 做到了0-RTT連接。
6. 為何不是所有網(wǎng)站都用HTTPS？
難度：??
HTTPS的實施需要門檻，因為從證書的選擇、購買，再到部署，傳統(tǒng)模式下都比較耗時耗力 另外大家普遍認(rèn)為HTTPS會更慢一些，因為相比于HTTP的明文傳輸它的加密通信會消耗更多的CPU及內(nèi)存資源 (但其實用戶可以通過性能優(yōu)化，把證書部署到SLB(負(fù)載均衡)或者CDN來解決這個問題。) 購買證書需要開銷 國內(nèi)安全意識可能沒那么強(qiáng)
參考文章
《圖解HTTP》
掃碼關(guān)注公眾號，訂閱更多精彩內(nèi)容。
