目錄

1.HTTPS是什么

2.加密技術(shù)

2.1什么是加密

2.2為什么要加密

2.3加密處理防止被竊聽

3.常見的加密方式

對稱加密

非對稱加密

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

5.數(shù)字簽名

6.HTTPS的工作過程探究

方案1——只是用對稱加密

方案2——只進(jìn)行非對稱加密

?方案3——雙方都是用非對稱加密

方案4——非對稱加密+對稱加密

方案3方案4的問題所在

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

7.引入證書

CA認(rèn)證

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

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

查看瀏覽器的受信任證書發(fā)布機(jī)構(gòu)

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

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

完整流程

總結(jié)

---

1.HTTPS是什么

HTTPS也是一個(gè)應(yīng)用層協(xié)議，是在HTTP協(xié)議的基礎(chǔ)上引入了一個(gè)加密層。是為了解決HTTP的缺點(diǎn)的。我們再來回顧以下HTTP的缺點(diǎn)：

1. 通信使用明文(不加密)，內(nèi)容可能會(huì)被竊聽
2. 不驗(yàn)證通信方的身份，因此有可能遭遇偽裝
3. 無法證明報(bào)文的完整性，所以有可能已遭遇篡改

因此HTTPS = HTTP + 加密 + 認(rèn)證 + 完整性保護(hù)

2.加密技術(shù)

2.1什么是加密

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

2.2為什么要加密

因?yàn)橥ㄐ胖苯邮褂妹魑目赡軙?huì)被竊聽。由于HTTP本身不具備加密的功能，所以也無法做到對通信整體進(jìn)行加密。即HTTP使用明文方式發(fā)送。

那么為什么通信時(shí)不加密會(huì)被竊聽？

這是因?yàn)?#xff0c;按TCP/IP協(xié)議族的工作機(jī)制，通信內(nèi)容在所有的通信線路上都有可能遭到窺視。因此在通信線路的互聯(lián)網(wǎng)設(shè)備，光纜，計(jì)算機(jī)都不是個(gè)人物品，因此就有可能被竊聽和窺視。

2.3加密處理防止被竊聽

HTTP協(xié)議沒有加密機(jī)制，但是可以通過和SSL(Secure Socket Layer，安全套階層)或TLS(Transport Layer Security,安全傳輸層協(xié)議) 的組合使用，加密HTTP的通信內(nèi)容。因此HTTP和TCP進(jìn)行通信時(shí)，當(dāng)使用SSL時(shí)，先演變成HTTP先和SSL通信，再由SSL和TCP通信了。因此所謂HTTPS，其實(shí)就是HTTP協(xié)議身披了一層SSL協(xié)議。

SSL是獨(dú)立于HTTP的協(xié)議，所以不光是HTTP協(xié)議，其他運(yùn)行在應(yīng)用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用。

3.常見的加密方式

對稱加密

采用單鑰密碼系統(tǒng)的加密方法，同一個(gè)密鑰可以同時(shí)用作信息的加密和解密，這種加密方式稱為對稱加密，也稱單密鑰加密。特征：加密和解密所用的密鑰是想用的

特點(diǎn)：算法公開，計(jì)算量小，加密速度快，加密效率高

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

非對稱加密

需要兩個(gè)密鑰來進(jìn)行加密和解密，這兩個(gè)密鑰是公開密鑰和私有密鑰

特點(diǎn)：算法強(qiáng)度復(fù)雜，安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使用加密解密速度沒有對稱加密解密的速度快。

非對稱加密要用到兩個(gè)密鑰，一個(gè)叫做公鑰，一個(gè)叫做私鑰。公鑰和私鑰是配對的，最大的缺點(diǎn)是運(yùn)算速度非常慢，比對稱加密要慢很多。

• 通過公鑰對明文加密，變成密文；通過私鑰對密文解密，變成明文
• 也可以通過私鑰對明文加密，變成密文；通過公鑰對密文解密。變成明文

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

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

摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆]有解密，只不過從摘要很難反推出原信息。通常用來進(jìn)行數(shù)據(jù)對比。

5.數(shù)字簽名

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

6.HTTPS的工作過程探究

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

方案1——只是用對稱加密

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

引入對稱加密之后，即使數(shù)據(jù)被中間人截獲，但是他沒有密鑰，因此就無法進(jìn)行解密，也就不知道請求的真是內(nèi)容是什么了.

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

?比較理想的做法是客戶端在服務(wù)器建立連接的時(shí)候，雙方協(xié)商確定這次用的密鑰是什么？

但是如果直接把密鑰明文傳輸，那么中間人也可以獲得密鑰了，此時(shí)后續(xù)的加密操作就形同虛設(shè)了，因此密鑰的傳輸也需要加密。那么對密鑰進(jìn)行加密，如果也進(jìn)行對稱加密，那么也需要協(xié)商確定一個(gè)密鑰的密鑰。那么問題將會(huì)進(jìn)入死循環(huán)了。因此密鑰的傳輸如果使用對稱加密是行不通的

方案2——只進(jìn)行非對稱加密

鑒于非對稱加密的機(jī)制，如果服務(wù)器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)之前都先用這個(gè)公鑰加密好再傳，從客戶端到服務(wù)器信道似乎是安全的,因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。但是服務(wù)器到瀏覽器的這條路怎么保障安全呢？如果服務(wù)器用他的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器用公鑰可以解開它，而這個(gè)公鑰是一開始通過明文傳輸給瀏覽器的，若這個(gè)公鑰被中間人劫持了，那讓也能用該公鑰解密服務(wù)器傳來的信息。因此只進(jìn)行非對稱加密也是不安全的

?方案3——雙方都是用非對稱加密

1. 服務(wù)端擁有公鑰S和對應(yīng)的私鑰S‘,客戶端擁有公鑰C和私鑰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‘
5. 但是我們說過使用非對稱加密算法強(qiáng)度復(fù)雜，效率太慢了，無法被接受
6. 依然有安全問題

方案4——非對稱加密+對稱加密

我們知道使用非對稱加密效率太差，因此我們將非對稱加密和對稱加密配合使用來解決效率問題

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

由于對稱加密的效率??對稱加密?很多, 因此只是在開始階段協(xié)商密鑰的時(shí)候使??對稱加密, 后續(xù)的傳輸仍然使?對稱加密.

方案3方案4的問題所在

方案2方案3方案4都存在一個(gè)問題，如果最開始，中間人就開始攻擊了呢？

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

1. 服務(wù)器具有非對稱加密算法的公鑰S，私鑰S‘
2. 中間人具有非堆成加密算法的公鑰M，私鑰M’
3. 客戶端向服務(wù)器發(fā)送請求，服務(wù)器明文傳輸公鑰S給客戶端
4. 中間人挾持?jǐn)?shù)據(jù)報(bào)文，提取公鑰S并保存好，然后將被劫持報(bào)文中的公鑰S替換成自己的公鑰M，并將偽造報(bào)文發(fā)給客戶端
5. 客戶端收到報(bào)文，提取公鑰M(自己以為是服務(wù)器端發(fā)過來的)，自己形成了對稱密鑰X，用公鑰M加密X,形成報(bào)文發(fā)送給服務(wù)器
6. 中間人劫持后，直接用自己的私鑰M'進(jìn)行解密，得到通信密鑰X，再用曾經(jīng)保存的服務(wù)端公鑰S加密后再發(fā)送給服務(wù)器
7. 服務(wù)器拿到報(bào)文,用自己的私鑰S’解密，得到通信密鑰X
8. 雙方開始采用X進(jìn)行對稱加密，進(jìn)行通信。但是一切都在中間人的掌握之中

以上問題發(fā)生的本質(zhì)是客戶端無法確定收到的含有公鑰的數(shù)據(jù)報(bào)文就是目標(biāo)服務(wù)器發(fā)送過來的?

7.引入證書

CA認(rèn)證

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

需要注意的是：申請證書的時(shí)候，需要在特定的平臺(tái)生成查，會(huì)同時(shí)生成一對兒密鑰對，即公鑰和私鑰。這對密鑰對就是用來在網(wǎng)絡(luò)通信中進(jìn)行明文加密以及數(shù)字簽名的

其中公鑰會(huì)隨著CSR文件，一起發(fā)給CA進(jìn)行權(quán)威認(rèn)證，私鑰服務(wù)端自己保留，用來后續(xù)進(jìn)行通信(其實(shí)主要就是用來交換對稱密鑰)

?

?

形成CSR之后就是想CA進(jìn)行申請認(rèn)證，不過一般認(rèn)證過程很繁瑣，網(wǎng)絡(luò)各種提供證書申請的服務(wù)商一般真的需要，直接找平臺(tái)解決就行

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

?

1. CA機(jī)構(gòu)擁有?對稱加密的私鑰A和公鑰A'
2. CA機(jī)構(gòu)對服務(wù)端申請的證書明?數(shù)據(jù)進(jìn)?hash，形成數(shù)據(jù)摘要
3. 然后對數(shù)據(jù)摘要?CA私鑰A'加密，得到數(shù)字簽名S

服務(wù)端申請的證書明?和數(shù)字簽名S 共同組成了數(shù)字證書，這樣?份數(shù)字證書就可以頒發(fā)給服務(wù)端了

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

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

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

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

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

查看瀏覽器的受信任證書發(fā)布機(jī)構(gòu)

以Microsoft的默認(rèn)瀏覽器為例

?我們可以在微軟的瀏覽器下查看安全瀏覽Web的各種情況

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

1. 中間人篡改了證書的明文
2. 由于他沒有CA機(jī)構(gòu)的私鑰，所以無法Hash之后用私鑰加密形成簽名，那么也就沒法對篡改后的證書形成匹配的簽名
3. 如果強(qiáng)行篡改，客戶端收到該證書后會(huì)發(fā)現(xiàn)明文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，也就種植向服務(wù)器傳輸信息

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

• 因?yàn)橹虚g?沒有CA私鑰，所以?法制作假的證書(為什么？)
• 所以中間?只能向CA申請真證書，然后???申請的證書進(jìn)?掉包
• 這個(gè)確實(shí)能做到證書的整體掉包，但是別忘記，證書明?中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客?端依舊能夠識(shí)別出來。
• 永遠(yuǎn)記住：中間?沒有CA私鑰，所以對任何證書都?法進(jìn)?合法修改，包括??的

?但是還有個(gè)問題, 如果?客把 hello 篡改了, 同時(shí)也把哈希值重新計(jì)算下, 客?端就分辨不出來了呀.

?所以被傳輸?shù)墓Ｖ挡荒軅鬏斆?, 需要傳輸密?.

完整流程

總結(jié)

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

• 第?組(?對稱加密): ?于校驗(yàn)證書是否被篡改. 服務(wù)器持有私鑰(私鑰在形成CSR?件與申請證書時(shí)獲得), 客?端持有公鑰(操作系統(tǒng)包含了可信任的 CA 認(rèn)證機(jī)構(gòu)有哪些, 同時(shí)持有對應(yīng)的公鑰). 服務(wù)器在客?端請求是，返回?cái)y帶簽名的證書. 客?端通過這個(gè)公鑰進(jìn)?證書驗(yàn)證, 保證證書的合法性，進(jìn)?步保證證書中攜帶的服務(wù)端公鑰權(quán)威性。
• 第?組(?對稱加密): ?于協(xié)商?成對稱加密的密鑰. 客?端?收到的CA證書中的公鑰(是可被信任的)給隨機(jī)?成的對稱加密的密鑰加密, 傳輸給服務(wù)器, 服務(wù)器通過私鑰解密獲取到對稱加密密鑰.
• 第三組(對稱加密): 客?端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個(gè)對稱密鑰加密解密.

第?組?對稱加密的密鑰是為了讓客?端把這個(gè)對稱密鑰傳給服務(wù)器.

第?組?對稱加密的密鑰是為了讓客?端拿到第?組?對稱加密的公鑰.