前言

大家好，我是田螺。

有位朋友校招面試了字節(jié)的后端崗位，問到這道面試題：https 原理。

這道題其實比較簡單，我們?nèi)绾胃玫鼗卮鹉?？我來跟大家聊聊。可以從這幾個維度逐層擴展來講

• http為什么不安全？
• 對稱算法加密+HTTP
• 非對稱加密+HTTP
• 非對稱加密+對稱加密+HTTP
• 數(shù)字簽名，給你的公鑰蓋個章
• 完整的HTTPS運行流程圖

1. http為什么不安全？

我們先來看看HTTP傳輸：

圖片

• 客戶端，把一條消息，以明文的方式，發(fā)送到服務(wù)器。
• 服務(wù)的響應(yīng)報文，也是以明文的方式，發(fā)回給客戶端。

Http 明文傳輸，主要有這些缺點：竊聽風險、篡改風險、冒充風險

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

2. 對稱算法加密+HTTP

既然，明文傳輸不安全，那我們加密是不是就可以了。比如用對稱加密算法加密。

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

看看用對稱算法加密后，HTTP流程又是怎樣的：

圖片

• 客戶端把要發(fā)送的消息，用密鑰加密成密文。
• 客戶端把密文發(fā)送到服務(wù)器。
• 服務(wù)器收到密文消息，用同一把密鑰把密文解密成明文。
• 同理，服務(wù)端把消息報文返回給客戶端，處理過程類似。

這種方式還是有問題:

一開始客戶端怎么把密鑰發(fā)過去呢？如果不懷好意的中間人截取到了密鑰，發(fā)送的消息還是會被盜取和利用呢。

3. 非對稱加密+HTTP

既然對稱算法加密+HTTP 還是不夠安全，那我們用非對稱加密+HTTP。

什么是非對稱加密算法？

• 非對稱加密算法需要兩個密鑰：公開密鑰和私有密鑰。公開密鑰與私有密鑰是一對，如果用公開密鑰對數(shù)據(jù)進行加密，只有用對應(yīng)的私有密鑰才能解密；如果用私有密鑰對數(shù)據(jù)進行加密，那么只有用對應(yīng)的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種算法叫作非對稱加密算法。
• 常用非對稱加密算法：RSA、ECC

使用非對稱加密算法之后，HTTP流程又是怎樣的，如下圖：

圖片

• 客戶端向服務(wù)器發(fā)起HTTP請求
• 服務(wù)端將自己的公鑰返回到客戶端。
• 客戶端使用返回的公鑰，給要發(fā)送的消息加密。
• 客戶端將加密之后的消息密文發(fā)送給服務(wù)器。
• 服務(wù)器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后得到消息數(shù)據(jù)。

這種方式依然有問題:

非對稱算法（如：RSA）有個弊端，它很慢。試想一下，如果你用瀏覽器請求，它很久才響應(yīng)，你能接受嗎？

4. 非對稱加密+對稱加密+HTTP

既然非對稱加密慢。對稱加密會快好多。我們可以使用非對稱加密+對稱加密雙劍合璧的流程圖如下：

圖片

• 客戶端向服務(wù)器發(fā)起HTTP請求
• 服務(wù)端將自己的公鑰返回到客戶端。
• 客戶端產(chǎn)生對稱加密密鑰，并用服務(wù)端返回的公鑰對它加密
• 客戶端會發(fā)起第二個HTTP請求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。
• 服務(wù)器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密，這樣數(shù)據(jù)就變成了密文。
• 服務(wù)器將加密后的密文返回給客戶端。
• 客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對其進行對稱解密，得到服務(wù)器返回的數(shù)據(jù)。

這種方式還是有問題，沒完沒了了。。。

如果中間人又來搞事情呢？要是中間人截取公鑰，把公鑰進行篡改呢? 打個比喻，把公鑰比喻你自己的手機號，它是公開的，誰都可以給你打電話。假設(shè)你發(fā)消息給你朋友，告訴他你的手機號，然后消息被中間人截取修改了，改為110，然后你朋友不知情的情況下，撥通110，打電話給你。。。

5. 數(shù)字簽名，給你的公鑰蓋個章

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

圖片

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

 證書驗證

圖片

• 拿到數(shù)字證書之后，用同樣的Hash算法， 先再次生成消息摘要；
• 然后用CA的公鑰對數(shù)字簽名解密， 得到CA創(chuàng)建的消息摘要， 兩者對比，就知道有沒有人篡改了。

6. 完整的HTTPS運行流程圖

圖片

1. 用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。
2. 服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。
3. 服務(wù)器將自己的數(shù)字證書（含有公鑰）發(fā)送給客戶端。
4. 客戶端收到服務(wù)器端的數(shù)字證書之后，會對其進行檢查，如果不通過，則彈出警告框。如果證書沒問題，則生成一個密鑰（對稱加密），用證書的公鑰對它加密。
5. 客戶端會發(fā)起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發(fā)送給服務(wù)器。
6. 服務(wù)器接收到客戶端發(fā)來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后得到客戶端密鑰，然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密，這樣數(shù)據(jù)就變成了密文。
7. 服務(wù)器將加密后的密文返回給客戶端。
8. 客戶端收到服務(wù)器發(fā)返回的密文，用自己的密鑰（客戶端密鑰）對其進行對稱解密，得到服務(wù)器返回的數(shù)據(jù)。