談?wù)凥TTPS演變過(guò)程

走過(guò)路過(guò)不要錯(cuò)過(guò)

點(diǎn)擊藍(lán)字關(guān)注我們

前言

本文談?wù)凥TTPS設(shè)計(jì)演變過(guò)程，希望對(duì)大家理解HTTPS有幫助，有不對(duì)的地方歡迎指出。

密碼學(xué)基礎(chǔ)知識(shí)

在討論HTTPS之前，需要掌握一些密碼學(xué)基礎(chǔ)概念。

明文、密文、密鑰

明文： 指沒(méi)有經(jīng)過(guò)加密的信息/數(shù)據(jù)。

密文：明文被某種加密算法加密之后，會(huì)變成密文，從而確保原始數(shù)據(jù)的安全。密文也可以被解密，得到原始的明文。

密鑰：是一種參數(shù)，它是在明文轉(zhuǎn)換為密文或?qū)⒚芪霓D(zhuǎn)換為明文的算法中輸入的參數(shù)。密鑰分為對(duì)稱密鑰與非對(duì)稱密鑰。

對(duì)稱加密

定義：需要對(duì)加密和解密使用相同密鑰的加密算法。由于其速度快，對(duì)稱性加密通常在消息發(fā)送方需要加密大量數(shù)據(jù)時(shí)使用。對(duì)稱性加密也稱為密鑰加密。

常用的對(duì)稱加密算法： DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK等。

加密過(guò)程： 明文 + 加密算法 + 私鑰 => 密文

解密過(guò)程： 密文 + 解密算法 + 私鑰 => 明文

由于對(duì)稱加密的算法是公開的，所以一旦私鑰被泄露，那么密文就很容易被破解，所以對(duì)稱加密的缺點(diǎn)是密鑰安全管理困難。

非對(duì)稱加密

定義

1. 非對(duì)稱加密算法需要兩個(gè)密鑰：公開密鑰和私有密鑰。公開密鑰與私有密鑰是一對(duì)，如果用公開密鑰對(duì)數(shù)據(jù)進(jìn)行加密，只有用對(duì)應(yīng)的私有密鑰才能解密；如果用私有密鑰對(duì)數(shù)據(jù)進(jìn)行加密，那么只有用對(duì)應(yīng)的公開密鑰才能解密。

2. 公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。私鑰被自己保存，不能對(duì)外泄露。

3. 因?yàn)榧用芎徒饷苁褂玫氖莾蓚€(gè)不同的密鑰，所以這種算法叫作非對(duì)稱加密算法。

常用非對(duì)稱加密算法： RSA、Elgamal、背包算法、Rabin、D-H、ECC（橢圓曲線加密算法）等。

被公鑰加密過(guò)的密文只能被私鑰解密，過(guò)程如下：

明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文

被私鑰加密過(guò)的密文只能被公鑰解密，過(guò)程如下：

明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文

HTTP明文傳輸

HTTPS發(fā)展源頭是HTTP（超文本傳輸協(xié)議），所以我們先來(lái)看看HTTP傳輸，如下：

流程

客戶端，把一條消息，以明文的方式，發(fā)送到服務(wù)器。

那么在網(wǎng)絡(luò)上赤裸裸的明文傳輸會(huì)有什么問(wèn)題呢？

問(wèn)題

請(qǐng)君試想，如果HTTP請(qǐng)求被某個(gè)不懷好意的中間人截取，并且，消息包含銀行密碼等敏感信息的話，造成的后果不堪設(shè)想吧。

解決方案

既然明文傳輸會(huì)有問(wèn)題，那么，我們可以用加密算法加密嘛。

對(duì)稱算法加密+HTTP

接下來(lái)，看看用對(duì)稱算法加密后，是怎樣的，如圖：

流程

• 客戶端把要發(fā)送的消息，用密鑰加密成密文。

• 客戶端把密文發(fā)送到服務(wù)器。

• 服務(wù)器收到密文消息，用同一把密鑰把密文解密成明文。

問(wèn)題

這種方式還是有問(wèn)題，一開始客戶端怎么把密鑰發(fā)過(guò)去呢？如果不懷好意的中間人截取到了密鑰，發(fā)送的消息還是會(huì)被盜取和利用呢。

解決方案

可以考慮非對(duì)稱加密試試。

非對(duì)稱加密+HTTP

OK,我們?cè)賮?lái)看看，使用非對(duì)稱加密算法，又是怎樣，如圖：

流程

• 客戶端向服務(wù)器發(fā)起HTTPS請(qǐng)求，連接到服務(wù)器的443端口。

• 服務(wù)端將自己的公鑰返回到客戶端。

• 客戶端使用返回的公鑰，給要發(fā)送的消息加密。

• 客戶端將加密之后的消息密文發(fā)送給服務(wù)器。

• 服務(wù)器接收到客戶端發(fā)來(lái)的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后得到消息數(shù)據(jù)。

問(wèn)題

縱觀整個(gè)過(guò)程，感覺(jué)沒(méi)啥問(wèn)題，即使中間人截取了公鑰，也沒(méi)啥用，他沒(méi)有私鑰解密不了。但是，非對(duì)稱算法（如：RSA）有個(gè)弊端，它很慢。試想一下，如果你用瀏覽器請(qǐng)求，它很久才響應(yīng)，你能接受嗎？

解決方案

因?yàn)閷?duì)稱加密快，但是它安全性不高，非對(duì)稱加密安全性高，但是它慢，那么，可以考慮非對(duì)稱加密+對(duì)稱加密結(jié)合一起嘛。

非對(duì)稱加密+對(duì)稱加密+HTTP

非對(duì)稱加密+對(duì)稱加密雙劍合璧的流程圖如下：

流程

• 客戶端向服務(wù)器發(fā)起HTTPS請(qǐng)求，連接到服務(wù)器的443端口。

• 服務(wù)端將自己的公鑰返回到客戶端。

• 客戶端產(chǎn)生對(duì)稱加密密鑰，并用服務(wù)端返回的公鑰對(duì)它加密

• 客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。

• 服務(wù)器接收到客戶端發(fā)來(lái)的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對(duì)返回?cái)?shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。

• 服務(wù)器將加密后的密文返回給客戶端。

• 客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器返回的數(shù)據(jù)。

問(wèn)題

這個(gè)流程看來(lái)，似乎已經(jīng)天衣無(wú)縫了呢？但是，如果中間人又來(lái)搞事情呢？要是中間人截取公鑰，把公鑰進(jìn)行篡改呢? 打個(gè)比喻，把公鑰比喻你自己的手機(jī)號(hào)，它是公開的，誰(shuí)都可以給你打電話。假設(shè)你發(fā)消息給你朋友，告訴他你的手機(jī)號(hào)，然后消息被中間人截取修改了，改為110，然后你朋友不知情的情況下，撥通110，打電話給你。。。

解決方案

為了避免公鑰被篡改，需要引入數(shù)字簽名，類似給你的公鑰蓋個(gè)章，證明身份用。

數(shù)字證書登場(chǎng)

為了避免公鑰被篡改，引入了數(shù)字證書，如圖所下：

數(shù)字證書構(gòu)成

• 公鑰和個(gè)人信息，經(jīng)過(guò)Hash算法加密，形成消息摘要；將消息摘要拿到擁有公信力的認(rèn)證中心（CA），用它的私鑰對(duì)消息摘要加密，形成數(shù)字簽名.

• 公鑰和個(gè)人信息、數(shù)字簽名共同構(gòu)成數(shù)字證書。

數(shù)字證書驗(yàn)證

• 拿到數(shù)字證書之后，用同樣的Hash算法， 先再次生成消息摘要；

• 然后用CA的公鑰對(duì)數(shù)字簽名解密， 得到CA創(chuàng)建的消息摘要， 兩者對(duì)比，就知道有沒(méi)有人篡改了。

完整的HTTPS運(yùn)行流程圖

介紹完數(shù)字證書，完整的HTTPS流程千呼萬(wàn)喚始出來(lái)了，如圖：

1. 用戶在瀏覽器里輸入一個(gè)https網(wǎng)址，然后連接到server的443端口。

2. 服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請(qǐng)，區(qū)別就是自己頒發(fā)的證書需要客戶端驗(yàn)證通過(guò)。這套證書其實(shí)就是一對(duì)公鑰和私鑰。

3. 服務(wù)器將自己的數(shù)字證書（含有公鑰）發(fā)送給客戶端。

4. 客戶端收到服務(wù)器端的數(shù)字證書之后，會(huì)對(duì)其進(jìn)行檢查，如果不通過(guò)，則彈出警告框。如果證書沒(méi)問(wèn)題，則生成一個(gè)密鑰（對(duì)稱加密），用證書的公鑰對(duì)它加密。

5. 客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請(qǐng)求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。

6. 服務(wù)器接收到客戶端發(fā)來(lái)的密文之后，會(huì)用自己的私鑰對(duì)其進(jìn)行非對(duì)稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對(duì)返回?cái)?shù)據(jù)進(jìn)行對(duì)稱加密，這樣數(shù)據(jù)就變成了密文。

7. 服務(wù)器將加密后的密文返回給客戶端。

8. 客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對(duì)其進(jìn)行對(duì)稱解密，得到服務(wù)器返回的數(shù)據(jù)。

總結(jié)

1. 對(duì)稱加密  效率高，所以最終目的是要使用對(duì)稱加密進(jìn)行客戶端與服務(wù)端的通信。但客戶端如何告訴服務(wù)端要共同使用的密鑰，而不被第三方獲取

2. 所以引入了非對(duì)稱加密，客戶端先與服務(wù)端建立連接，然后服務(wù)端保留自己的私鑰，把公鑰返回給客戶端。但客戶端接收公鑰的過(guò)程中，第三方也可以截取公鑰，甚至對(duì)公鑰進(jìn)行篡改

3. 所以引入了數(shù)字證書，起初服務(wù)端在返回給客戶端公鑰的時(shí)候，附帶了數(shù)字證書。數(shù)字證書是使用非對(duì)稱加密，切私鑰永遠(yuǎn)只保存在CA，且數(shù)字證書的形成是可逆的。

4. 所以客戶端在對(duì)比服務(wù)端的公鑰沒(méi)問(wèn)題后，使用服務(wù)端的公鑰非對(duì)稱加密 對(duì)將要使用的 對(duì)稱加密密鑰 加密后，發(fā)送給服務(wù)端，然后服務(wù)端私鑰解密。

5. 至此客戶端、服務(wù)端僅彼此獲得了對(duì)稱加密的密鑰，達(dá)成了高效安全傳輸數(shù)據(jù)的目的。

---

往期精彩推薦

騰訊、阿里、滴滴后臺(tái)面試題匯總總結(jié) — （含答案）

面試：史上最全多線程面試題 ！

最新阿里內(nèi)推Java后端面試題

JVM難學(xué)？那是因?yàn)槟銢](méi)認(rèn)真看完這篇文章

—END—

關(guān)注作者微信公眾號(hào) —《JAVA爛豬皮》

了解更多java后端架構(gòu)知識(shí)以及最新面試寶典

你點(diǎn)的每個(gè)好看，我都認(rèn)真當(dāng)成了

看完本文記得給作者點(diǎn)贊+在看哦~~~大家的支持，是作者源源不斷出文的動(dòng)力