喜歡的點(diǎn)贊，收藏，關(guān)注一下把！

HTTPS 是什么

HTTPS 也是一個(gè)應(yīng)用層協(xié)議，是在 HTTP 協(xié)議的基礎(chǔ)上引入了?個(gè)加密層。

HTTP 協(xié)議內(nèi)容不管是GET還是POST都是按照文本的方式明文傳輸的，這就信息導(dǎo)致在傳輸過程中出現(xiàn)泄漏和被篡改的情況。所以在http和傳輸層直接添加一層軟件層 —> ssl/tls(加密層)。

如果用的是http協(xié)議，就是http構(gòu)建的請求經(jīng)過網(wǎng)絡(luò)然后交給對方http。
如果用的是https協(xié)議，從上到下要經(jīng)過加密層把請求加密之后然后在經(jīng)過網(wǎng)絡(luò)發(fā)送給對方收到https請求之后也要進(jìn)行解密。在雙方本地信息都是明文的，在網(wǎng)絡(luò)中是密文的。這樣就能保證信息在網(wǎng)絡(luò)中傳輸?shù)陌踩?/p>

那怎么知道收到的信息是加密還是沒加密的呢？
如果信息沒有加密請求的服務(wù)器端口采用的是80端口，信息加密的話請求的服務(wù)器端口采用的就是443端口。

1.什么是"加密"

加密就是把 明文 (要傳輸?shù)男畔? 進(jìn)行一系列變換,，生成 密文。
解密就是把 密文 再進(jìn)行一系列變換,，還原成 明文 。
在這個(gè)加密和解密的過程中,，往往需要一個(gè)或者多個(gè)中間的數(shù)據(jù),，輔助進(jìn)行這個(gè)過程，這樣的數(shù)據(jù)稱為 密鑰。

下面舉個(gè)簡單例子理解一下。
int a = 100;
int key = 200;
int b = a ^ key;
int c = b ^ key;
c等于什么呢？
這里我們都知道，0 ^ a = a，b ^ b = 0，
并且 ^ 是支持交換率的a ^ b ^ c == a ^ c ^ b == c ^ b ^ a
所以這里c = b ^ key == a ^ key ^ key == a ^ 0 == a

現(xiàn)在我們有一個(gè)客戶端和服務(wù)端?？蛻舳税l(fā)數(shù)據(jù)a，但并不是直接發(fā)的，我們把要發(fā)的a稱為原始數(shù)據(jù)，把a(bǔ)和key做異或運(yùn)算等于b，網(wǎng)絡(luò)傳送的時(shí)候把b傳過去，服務(wù)器端收到b，服務(wù)端也必須要有一個(gè)key，然后b^key，最終等于a。

a---->原始數(shù)據(jù)
key---->密鑰
a^key---->加密的過程
b---->密文
b---->解密

2.為什么要加密

比如說 臭名昭著的 “運(yùn)營商劫持”

假設(shè)下載一個(gè) 網(wǎng)易云，未被劫持的效果，點(diǎn)擊下載按鈕，就會彈出網(wǎng)易云的下載鏈接。已被劫持的效果，點(diǎn)擊下載按鈕，就會彈出QQ瀏覽器的下載鏈接。

由于我們通過網(wǎng)絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會經(jīng)過運(yùn)營商的網(wǎng)絡(luò)設(shè)備(路由器，交換機(jī)等)， 那么運(yùn)營商的網(wǎng)絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容，并進(jìn)行篡改。
點(diǎn)擊 “下載按鈕”， 其實(shí)就是在給服務(wù)器發(fā)送了?個(gè) HTTP 請求, 獲取到的 HTTP 響應(yīng)其實(shí)就包含了該APP 的下載鏈接。運(yùn)營商劫持之后，就發(fā)現(xiàn)這個(gè)請求是要下載網(wǎng)易云， 那么就自動的把交給用戶的響應(yīng)給篡改成 “QQ瀏覽器” 的下載地址了。

所以：因?yàn)閔ttp的內(nèi)容是明文傳輸?shù)?，明文?shù)據(jù)會經(jīng)過路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營商、代理服務(wù)器等多個(gè)物理節(jié)點(diǎn)，如果信息在傳輸過程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是 中間人攻擊 ，所以我們才需要對信息進(jìn)行加密。

不止運(yùn)營商可以劫持，其他的 黑客 也可以用類似的收段進(jìn)行劫持，來竊取用戶隱私信息或者篡改內(nèi)容。試想?下，如果黑客在用戶登陸支付寶的時(shí)候獲取到用戶賬戶余額，甚至獲取到用戶的支付密碼…

還有比如商場不知名的免費(fèi)網(wǎng)絡(luò)，如果你用手機(jī)連接上了這個(gè)wifi，當(dāng)你用你的手機(jī)進(jìn)行上網(wǎng)的時(shí)候，首先你請求發(fā)的報(bào)文是要先轉(zhuǎn)發(fā)到這臺提供免費(fèi)網(wǎng)絡(luò)的中間設(shè)備上，如果這個(gè)中間設(shè)備安裝了類型與抓包分析報(bào)文的工具，就能拿到所有鏈接這個(gè)中間設(shè)備的數(shù)據(jù)了。不要連公共場所的網(wǎng)絡(luò)！

在互聯(lián)網(wǎng)上，明文傳輸是比較危險(xiǎn)的事情!!!
HTTPS 就是在 HTTP 的基礎(chǔ)上進(jìn)行了加密, 進(jìn)?步的來保證用戶的信息安全~

3.常見的加密方式

對稱加密

• 采用單鑰密碼系統(tǒng)的加密方法，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所用的密鑰是相同的
• 常見對稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特點(diǎn)：算法公開、計(jì)算量小、加密速度快、加密效率高

對稱加密其實(shí)就是通過同?個(gè) “密鑰” ，把明文加密成密文，并且也能把密文解密成明文。

非對稱加密

• 需要兩個(gè)密鑰來進(jìn)行加密和解密，這兩個(gè)密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。
• 常見非對稱加密算法(了解)：RSA，DSA，ECDSA
• 特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使得加密解密速度沒有對稱加密解密的速度快。

非對稱加密要用到兩個(gè)密鑰, ?個(gè)叫做 “公鑰”, ?個(gè)叫做 “私鑰”.

公鑰和私鑰是配對的. 最大的缺點(diǎn)就是運(yùn)算速度非常慢，比對稱加密要慢很多.

• 通過公鑰對明文加密, 變成密文
• 通過私鑰對密文解密, 變成明文

也可以反著用

• 通過私鑰對明文加密, 變成密文
• 通過公鑰對密文解密, 變成密文

這里舉一個(gè)簡單的生活上的例子：

A 要給 B ?些重要的文件, 但是 B 可能不在. 于是 A 和 B 提前做出約定：
B 說: 我桌子上有個(gè)盒子, 然后我給你?把鎖, 你把文件放盒子里用鎖鎖上, 然后我回頭拿著鑰匙來開鎖取文件.
在這個(gè)場景中, 這把鎖就相當(dāng)于公鑰, 鑰匙就是私鑰. 公鑰給誰都行(不怕泄露), 但是私鑰只有 B 自己持有. 持有私鑰的人才能解密.

對稱密鑰：一個(gè)秘鑰，速度快
非對稱密鑰：兩個(gè)密鑰，公鑰、私鑰，速度慢

如何理解加密的安全性？
從算力成本角度看，需要算力越大加密的安全性越大。如一條消息本身就值10塊錢但是加密之后破解這條消息需要花10個(gè)億成本，最終我們認(rèn)為這個(gè)密鑰本身是安全的。

4.數(shù)據(jù)摘要&&數(shù)據(jù)指紋

• 數(shù)字指紋(數(shù)據(jù)摘要),其基本原理是利用單向散列函數(shù)(Hash函數(shù))對信息進(jìn)行運(yùn)算,生成一串固定長度的數(shù)字摘要。數(shù)字指紋并不是一種加密機(jī)制,但可以用來判斷數(shù)據(jù)有沒有被竄改。

比如說今天有一篇非常大的文章，可以基于hash為原理對這篇文章做摘要，其實(shí)就是對這篇文章整體內(nèi)容做hash，經(jīng)過hash之后形成一個(gè)固定長度的字符串，這個(gè)字符串和這篇文章對應(yīng)關(guān)系算是1:1的，意思就是今天哪怕對原始文章做任何一個(gè)局部的修改，最后經(jīng)過hash映射形成的固定長度的字符串也會立馬發(fā)生變化。

我們把一個(gè)大的內(nèi)容經(jīng)過hash變成一個(gè)固定長度的字符串這種唯一性非常強(qiáng)的字符串，我們稱之為數(shù)據(jù)摘要。

• 摘要常見算法：有MD5、SHA1、SHA256、SHA512等，算法把無限的映射成有限，因此可能會有碰撞（兩個(gè)不同的信息，算出的摘要相同，但是概率非常低）
• 摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆]有解密，只不過從摘要很難反推原信息，通常用來進(jìn)行數(shù)據(jù)對比（對比兩個(gè)文件是否是同一個(gè)文件）
  
  如百度網(wǎng)盤秒傳功能。假如你有一個(gè)百度網(wǎng)盤，你將一部黑客帝國的電影傳到網(wǎng)盤中花了2個(gè)小時(shí)，然后網(wǎng)盤內(nèi)經(jīng)過hash映射形成一個(gè)固定大小的字符串。然后張三也想上傳黑客帝國，那是不是注定百度網(wǎng)盤存在大量重復(fù)的資源，對于空間消耗太大了。百度網(wǎng)盤這時(shí)就可以將黑客帝國文件資源經(jīng)過hash映射形成數(shù)據(jù)摘要。歷史上所有網(wǎng)盤上存在的文件都形成摘要，另一個(gè)傳資源的時(shí)候先在本地把要穿的資源形成摘要然后和百度網(wǎng)盤中所維護(hù)大量的摘要進(jìn)行對比，找不到就上傳，如果找到直接把這個(gè)資源在你的網(wǎng)盤目錄下建立一個(gè)軟連接執(zhí)行這個(gè)資源，你們共用同一份資源，但是你們并不知道。這樣就實(shí)現(xiàn)了秒傳功能。

不管是大文本還是小文本都可以經(jīng)過hash映射形成固定大小的字符串！

5.數(shù)字簽名

• 摘要經(jīng)過加密，就得到數(shù)字簽名
  

6.理解鏈 - 承上啟下

• 對http進(jìn)行對稱加密，是否能解決數(shù)據(jù)通信安全的問題？問題是什么？
• 為何要用非對稱加密？為何不全用非對稱加密？

帶著問題我們看接下來的內(nèi)容。

7.HTTPS 的工作過程探究

既然要保證數(shù)據(jù)安全, 就需要進(jìn)行 “加密”.
網(wǎng)絡(luò)傳輸中不再直接傳輸明文了, 而是加密之后的 “密文”.
加密的方式有很多, 但是整體可以分成兩大類: 對稱加密 和 非對稱加密

其實(shí)在網(wǎng)絡(luò)通信，我們要解決的是如下問題：

1. 數(shù)據(jù)被監(jiān)聽
2. 數(shù)據(jù)被篡改

方案一：只使用對稱加密

如果通信雙方都各自持有同一個(gè)密鑰X，且沒有別人知道，這兩方的通信安全當(dāng)然是可以被保證的（除非密鑰被破解）

引入對稱加密之后, 即使數(shù)據(jù)被截獲, 由于黑客不知道密鑰是啥, 因此就無法進(jìn)行解密, 也就不知道請求的真實(shí)內(nèi)容是啥了.

但事情沒這么簡單. 服務(wù)器同一時(shí)刻其實(shí)是給很多客戶端提供服務(wù)的. 這么多客戶端, 每個(gè)?用的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴(kuò)散了, ?客就也能拿到了). 因此服務(wù)器就需要維護(hù)每個(gè)客戶端和每個(gè)密鑰之間的關(guān)聯(lián)關(guān)系, 這也是個(gè)很麻煩的事情~

但這不是最重要的，最重要的是最開始的時(shí)候我們怎么保證客戶端和服務(wù)器看到的是同一個(gè)密鑰。如果最開始客戶端把密鑰發(fā)給服務(wù)器，那這個(gè)密鑰是明文傳還是密文傳？明文傳那黑客不就拿到了，加密傳那就需要對密鑰進(jìn)行加密，就仍然需要先協(xié)商確定一個(gè) “密鑰的密鑰”，這不就是雞生蛋還是蛋生雞的問題嗎？所以純純使用對稱加密是不行的！

因此在進(jìn)行正常的加密數(shù)據(jù)通信之前，我們得先解決密鑰如何被對方安全收到的問題！

方案二：只使用非對稱加密

通信之前先得交換密鑰，鑒于非對稱加密的機(jī)制，用公鑰和私鑰都可以加密，但用公鑰加密就要使用私鑰解密，使用私鑰加密就要使用公鑰解密。首先服務(wù)器先形成一對公鑰私鑰，客戶端發(fā)起秘鑰協(xié)商握手給服務(wù)器，服務(wù)器把公鑰推送給客戶端，這個(gè)公鑰中間人一定能拿到，客戶端拿到公鑰，不管發(fā)什么數(shù)據(jù)都先要經(jīng)過公鑰非對稱加密形成密文后然后發(fā)給服務(wù)端，雖然中間人還能看到，但是因?yàn)閷?yīng)得公鑰加密只能私鑰解密，私鑰加密只能公鑰解密。只有服務(wù)端有私鑰因此只有服務(wù)端能解密，即便是中間人拿到數(shù)據(jù)也沒有辦法因?yàn)閿?shù)據(jù)是加密的。目前從客戶端到服務(wù)器是安全的！

但是服務(wù)器給客戶端返回?cái)?shù)據(jù)就有問題了！別人給我的數(shù)據(jù)是安全的，我給別人的數(shù)據(jù)怎么保證安全。服務(wù)器直接用私鑰加密數(shù)據(jù)給客戶端發(fā)回去可以嗎？這個(gè)公鑰全世界人民都可以拿到，服務(wù)器用私鑰加密不就相當(dāng)于沒加密嗎？那服務(wù)器用公鑰加密然后給客戶端發(fā)回去，好現(xiàn)在這個(gè)數(shù)據(jù)安全了，但是客戶端拿到這個(gè)經(jīng)過公鑰加密的密文，它又沒有私鑰，怎么解密？

現(xiàn)在只能保證從C->S的安全性(暫時(shí)的安全)，沒有辦法解決S->C的安全性。
沒事我們在提第三種方案。

方案三：雙方都使用非對稱加密

1. 服務(wù)端擁有公鑰S與對應(yīng)的私鑰S’，客戶端擁有公鑰C與對應(yīng)的私鑰C’
2. 客戶和服務(wù)端交換公鑰
3. 客戶端給服務(wù)端發(fā)信息：先用S對數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因?yàn)橹挥蟹?wù)器有私鑰S’
4. 服務(wù)端給客戶端發(fā)信息：先用C對數(shù)據(jù)加密，在發(fā)送，只能由客戶端解密，因?yàn)橹挥锌蛻舳擞兴借€C’

雖然公鑰是公開的但公鑰是用來加密的，而私鑰只有自己擁有，只能自己才能進(jìn)行解密。這樣通信方案貌似是無懈可擊的，可是它有兩個(gè)問題。

最開始說過，非對稱加密算法非常復(fù)雜所以它非常慢！

1. 慢
2. 還是有安全問題，這是和方案二安全問題是一樣的，下面在提它們的安全問題

方案四：非對稱加密 + 對稱加密

先解決慢的問題

• 服務(wù)端具有非對稱公鑰S和私鑰S’
• 客戶端發(fā)起https請求，獲取服務(wù)端公鑰S
• 客戶端在本地生成對稱密鑰C, 通過公鑰S加密形成X, 發(fā)送給服務(wù)器.
• 由于中間的網(wǎng)絡(luò)設(shè)備沒有私鑰, 即使是截獲了數(shù)據(jù), 也無法還原出內(nèi)部的原文, 也就無法獲取到對稱密鑰(真的嗎?)
• 服務(wù)器拿到X通過私鑰S’解密, 還原出客戶端發(fā)送的對稱密鑰C. 并且使用這個(gè)對稱密鑰加密給客戶端返回的響應(yīng)數(shù)據(jù).
• 后續(xù)客戶端和服務(wù)器的通信都只用對稱加密即可. 由于該密鑰只有客戶端和服務(wù)器兩個(gè)主機(jī)知道, 其他主機(jī)/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒有意義.

前半部分采用非對稱加密：交換密鑰，后半部分采用對稱加密：雙方不存在了安全問題。既安全，又高效。

但真的沒有問題了嗎？

方案二、方案三、方案四都存在?個(gè)問題，如果最開始，中間?就已經(jīng)開始攻擊了呢？

中間人攻擊 - 針對上面的場景

確實(shí)，在方案2/3/4中，客戶端獲取到公鑰S之后，客戶端形成的對稱秘鑰C然后用服務(wù)端給客戶端的公鑰S對C進(jìn)加密，中間人即使竊取到了數(shù)據(jù)，此時(shí)中間人確實(shí)無法解出客戶端形成的密鑰C，因?yàn)橹挥蟹?wù)器有私鑰S’。

但是中間人的攻擊，如果在最開始握手協(xié)商的時(shí)候就進(jìn)行了，那就不一定了，假設(shè)hacker在最開始的時(shí)候已經(jīng)成功成為中間人

• 服務(wù)器具有非對稱加密算法的公鑰S，私鑰S’
• 中間人具有非對稱加密算法的公鑰M，私鑰M’
• 客戶端向服務(wù)器發(fā)起請求，服務(wù)器明文傳送公鑰S給客戶端
• 中間人劫持?jǐn)?shù)據(jù)報(bào)文，提取公鑰S并保存好，然后將被劫持報(bào)文中的公鑰S替換成為自己的公鑰M，并將偽造報(bào)文發(fā)給客戶端
• 客戶端收到報(bào)文，提取公鑰M(自己當(dāng)然不知道公鑰被更換過了)，自己形成對稱秘鑰C，用公鑰M加密C，形成報(bào)文X發(fā)送給服務(wù)器
• 中間人劫持后，直接用自己的私鑰M’進(jìn)行解密，得到通信秘鑰C，再用曾經(jīng)保存的服務(wù)端公鑰S加密后，形成新的報(bào)文Y推送給服務(wù)器
• 服務(wù)器拿到報(bào)文Y，用自己的私鑰S’解密，得到通信秘鑰C
• 雙方開始采用C進(jìn)行對稱加密，進(jìn)行通信。但是?切都在中間?的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)行竊聽甚至修改，都是可以的
  
  所以前面非對稱加密，后面對稱加密也是有坑的。

上面的攻擊方案，同樣適用于方案2、方案3

問題本質(zhì)出在哪里了呢？
服務(wù)器返回公鑰的時(shí)候，被中間人竊取并替換了&&客戶端沒有辨別公鑰是否合法的能力

下面要圍繞 客戶端能夠具有辨別服務(wù)器發(fā)過來的公鑰的合法性！ 來解決問題。

引入證書

CA認(rèn)證

服務(wù)端在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書里含有證書申請者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務(wù)端公鑰的權(quán)威性。

CA證書說白了就是一個(gè)文本文件，這個(gè)文件是可以安裝在你的系統(tǒng)中的，放在磁盤的某個(gè)目錄下，當(dāng)客戶端首次請求瀏覽器把這個(gè)文件返回給客戶端。

下面是證書申請的流程:
作為申請方首先要形成公鑰私鑰對，然后確實(shí)申請信息，最后生成請求.csr文件，提交給CA機(jī)構(gòu)審核，審核通過CA簽發(fā)證書，返回給server，client發(fā)起請求，server先把證書給client，client對證書做驗(yàn)證，驗(yàn)證通過從證書里提取公鑰，然后就像剛才的過程形成對稱密鑰，然后加密返回給server，然后雙方就可以通信了。

這個(gè)1、2、3過程只是在服務(wù)器申請證書才會做，申請好之后從此往后只有4、5、6過程。除非證書到期了才要重新申請證書。

客戶端能夠具有辨別服務(wù)器發(fā)過來的公鑰的合法性! 我們說是通過證書來進(jìn)行甄別的，那證書如何做到的呢？

理解數(shù)據(jù)簽名

簽名的形成是基于非對稱加密算法的，注意，目前暫時(shí)和https沒有關(guān)系，不要和https中的公鑰私鑰搞混了。

簽名：

對一份文本(可以認(rèn)為這里是CA證書內(nèi)的明文信息)經(jīng)過hash散列形成散列值，我們稱之為數(shù)據(jù)摘要。然后用簽名者的私鑰(CA機(jī)構(gòu)的私鑰)對數(shù)據(jù)摘要加密形成了數(shù)據(jù)簽名，更重要的把這個(gè)數(shù)據(jù)簽名和這個(gè)明文信息合在一起，形成數(shù)字簽名的數(shù)據(jù)。

驗(yàn)證：

把原始文本和簽名分開，一個(gè)對原始文本使用相同的散列函數(shù)進(jìn)行散列形成散列值，另一個(gè)對簽名用簽名者的公鑰解密形成散列值，然后對比兩個(gè)散列值，如果這兩個(gè)散列值不一樣，就注定有人要么改了原始文件，要么改了簽名。只要這兩個(gè)散列值一樣，那么原始文本和它曾經(jīng)形成的簽名是一樣的，說明這個(gè)原始文本沒有被篡改過！

數(shù)字簽名的本質(zhì)是為了防止篡改。

下面我們在以畫圖的方式理解簽名和驗(yàn)證的過程。

簽名：

首先說一下，CA為了簽發(fā)證書，CA也有自己的CA公鑰，CA私鑰。

因?yàn)槲覀兪褂肅A的私鑰形成數(shù)據(jù)簽名，所以只有CA能形成可信任的證書！(CA私鑰只在CA)

驗(yàn)證：

當(dāng)客戶端首次向服務(wù)器發(fā)起請求，服務(wù)器會把簽發(fā)好的證書推送給客戶端，那客戶端拿到證書不就是拿到公鑰了嗎，這個(gè)公鑰不就是曾經(jīng)服務(wù)端申請的公鑰嗎。

現(xiàn)在的問題就是如何保證這個(gè)公鑰的合法性呢？
所以客戶端要對收到的證書進(jìn)行驗(yàn)證。

如何驗(yàn)證？

將證書上的明文數(shù)據(jù)和數(shù)字簽名分開，把明文數(shù)據(jù)經(jīng)過相同的hash映射(這個(gè)hash是公開的)形成數(shù)據(jù)摘要。因?yàn)?strong>CA會在所有的瀏覽器中內(nèi)置自己的公鑰！所以瀏覽器會拿著CA公鑰對CA曾經(jīng)的數(shù)字簽名進(jìn)行解密！得到曾經(jīng)原始數(shù)據(jù)的摘要。然后對比兩個(gè)摘要。兩者相等說明證書內(nèi)部沒被串改，如果兩者不相等說明證書被篡改過。

以前不是說中間人最開始的時(shí)候改公鑰嗎，現(xiàn)在把證書帶上。

中間人有沒有可能篡改該證書？

即使現(xiàn)在中間人把證書公鑰給替換了，但數(shù)字簽名中間人沒有CA私鑰，那數(shù)字簽名就改不了。 未來在做hash形成數(shù)據(jù)摘要，和解密過的數(shù)字簽名形成的數(shù)據(jù)摘要，一定不同，那客戶端立馬就知道這個(gè)證書是被改過的。因此公鑰中間人不能改了。

那中間人把公鑰改了，然后中間人拿自己的私鑰做數(shù)字簽名，可以嗎？理論上可以，但是客戶端根本不認(rèn)識你這個(gè)數(shù)字簽名，客戶端用的是內(nèi)置的CA公鑰進(jìn)行解密，解不開也是不行的。

到目前為止中間人沒有辦法進(jìn)行任何局部的替換。無論是明文，還是簽名！

中間人整個(gè)掉包證書？

中間人現(xiàn)在把整個(gè)證書全部替換掉可以嗎？首先因?yàn)闉g覽器在做解密的會使用CA在所有的瀏覽器內(nèi)置的CA公鑰進(jìn)行解密，就這一條就注定了你要對證書進(jìn)行整體替換，你這個(gè)證書就必須是真的證書！是你這個(gè)中間人曾經(jīng)向CA機(jī)構(gòu)認(rèn)證過的證書，首先沒有這么傻的中間人，即使真有這樣的人，行但你會發(fā)現(xiàn)另一個(gè)問題，每一個(gè)證書明文都有一個(gè)域名，客戶端目標(biāo)訪問的網(wǎng)站是www.qq.com，即使中間人用真證書來改，但是注定了中間人用的這個(gè)域名和客戶端訪問的域名是不一樣的(域名具有唯一性)。你的域名是www.xx.com，即使中間人你用的真證書把我應(yīng)收到證書給換了，行客戶端收到了，然后用CA公鑰解密也可以，兩個(gè)數(shù)字摘要也是一樣的，好證書沒被篡改過，但是客戶端一對比就知道了，我要請求的是www.qq.com，但是你的證書怎么給我的是www.xx.com，雖然證書是真的但是域名不一樣，客戶端立馬意思到不對?？蛻舳苏諛幽茏R別出來。

中間人也沒有辦法進(jìn)行整體替換

方案五：非對稱加密 + 對稱加密 + 證書認(rèn)證

非對稱加密用來進(jìn)行密鑰交換，對稱加密用來實(shí)際真實(shí)通信時(shí)加密數(shù)據(jù)的安全和效率問題，證書用來證明非對稱加密之前在進(jìn)行密鑰協(xié)商階段服務(wù)器公鑰的合法性。
三位一體真正解決了問題。

下面看具體流程：

在客戶端和服務(wù)器剛一建立連接的時(shí)候, 服務(wù)器給客戶端返回一個(gè) 證書，證書包含了之前服務(wù)端的公鑰, 也包含了網(wǎng)站的身份信息

客戶端進(jìn)行認(rèn)證

當(dāng)客戶端獲取到這個(gè)證書之后, 會對證書進(jìn)行校驗(yàn)(防止證書是偽造的).

• 判定證書的有效期是否過期
• 判定證書的發(fā)布機(jī)構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)).
• 驗(yàn)證證書是否被篡改: 從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰, 對簽名解密, 得到?個(gè) hash 值(稱為數(shù)據(jù)摘要), 設(shè)為 hash1. 然后計(jì)算整個(gè)證書的 hash 值, 設(shè)為 hash2. 對比 hash1 和 hash2 是否相等. 如果相等, 則說明證書是沒有被篡改過的。

常見問題

為什么摘要內(nèi)容在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名?

這個(gè)問題其實(shí)我們前面就已經(jīng)回到了，就比如證書，如果不對摘要加密形成簽名，那中間人把證書改了，然后重新hash映射形成一個(gè)摘要放在證書里，客戶端收到也用相同的hash把證書明文信息形成摘要，即使中間人改了證書，那客戶端也看不出來。這個(gè)加密的過程是為了讓CA參與進(jìn)來，防止被篡改。

為什么原始數(shù)據(jù)不直接加密形成簽名，而是要先hash形成摘要?

首先對文本做hash摘要會把文本變成一個(gè)固定大小的(比較短)的hash值是非?？斓模⑶覍ash值做加密形成簽名速度也非?？?。其次有的算法對加密的文本長度是有要求的，對大的文本沒有辦法做整體加密。(縮小簽名密文的長度，加快數(shù)字簽名的驗(yàn)證簽名的運(yùn)算速度）

如何成為中間人 - 了解

• ARP欺騙：在局域網(wǎng)中，hacker經(jīng)過收到ARP Request廣播包，能夠偷聽到其它節(jié)點(diǎn)的 (IP, MAC)地址。例， 黑客收到兩個(gè)主機(jī)A, B的地址，告訴B (受害者) ，自己是A，使得B在發(fā)送給A 的數(shù)據(jù)包都被黑客截取
• ICMP攻擊：由于ICMP協(xié)議中有重定向的報(bào)文類型，那么我們就可以偽造一個(gè)ICMP信息然后發(fā)送給局域網(wǎng)中的客戶端，并偽裝自己是一個(gè)更好的路由通路。從而導(dǎo)致目標(biāo)所有的上網(wǎng)流量都會發(fā)送到我們指定的接口上，達(dá)到和ARP欺騙同樣的效果
• 假wifi && 假網(wǎng)站等

完整流程

總結(jié)

HTTPS 工作過程中涉及到的密鑰有三組

第一組(非對稱加密)(CA的公鑰和私鑰)：用于校驗(yàn)證書是否被篡改。 服務(wù)器持有自己私鑰(私鑰在形成CSR文件與申請證書時(shí)獲得)，客戶端持有CA公鑰(操作系統(tǒng)包含了可信任的 CA 認(rèn)證機(jī)構(gòu)有哪些， 同時(shí)持有對應(yīng)的公鑰)。服務(wù)器在客戶端請求時(shí)，返回?cái)y帶簽名的證書?？蛻舳送ㄟ^這個(gè)CA公鑰證書驗(yàn)證，保證證書的合法性，進(jìn)一步保證證書中攜帶的服務(wù)端公鑰權(quán)威性。

第二組(非對稱加密)(服務(wù)器的公鑰和私鑰)：用于協(xié)商生成對稱加密的密鑰。客戶端用收到的CA證書中的服務(wù)器公鑰(是可被信任的)給隨機(jī)生成的對稱加密的密鑰加密，傳輸給服務(wù)器，服務(wù)器通過自己私鑰解密獲取到對稱加密密鑰。

第三組(對稱加密)： 客戶端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個(gè)對稱密鑰加密解密。

其實(shí)一切的關(guān)鍵都是圍繞這個(gè)對稱加密的密鑰，其他的機(jī)制都是輔助這個(gè)密鑰工作的。

第二組非對稱加密的密鑰是為了讓客戶端把這個(gè)對稱密鑰傳給服務(wù)器
第一組非對稱加密的密鑰是為了讓客戶端拿到第二組非對稱加密的公鑰文章來源地址http://www.zghlxwxcb.cn/news/detail-851984.html

到了這里，關(guān)于【Linux網(wǎng)絡(luò)編程】HTTPS協(xié)議的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！