字節(jié)校招一面:聊聊Https 原理
前言
大家好,我是田螺。
有位朋友校招面試了字節(jié)的后端崗位,問到這道面試題:https 原理。
這道題其實比較簡單,我們如何更好地回答呢?我來跟大家聊聊??梢詮倪@幾個維度逐層擴展來講
- http為什么不安全?
- 對稱算法加密+HTTP
- 非對稱加密+HTTP
- 非對稱加密+對稱加密+HTTP
- 數(shù)字簽名,給你的公鑰蓋個章
- 完整的HTTPS運行流程圖
1. http為什么不安全?
我們先來看看HTTP傳輸:
圖片
- 客戶端,把一條消息,以明文的方式,發(fā)送到服務器。
- 服務的響應報文,也是以明文的方式,發(fā)回給客戶端。
Http 明文傳輸,主要有這些缺點:竊聽風險、篡改風險、冒充風險
請君試想,如果HTTP請求被某個不懷好意的中間人竊聽截取,并且,消息包含銀行密碼等敏感信息的話,造成的后果不堪設想吧。
2. 對稱算法加密+HTTP
既然,明文傳輸不安全,那我們加密是不是就可以了。比如用對稱加密算法加密。
- 對稱加密算法:需要對加密和解密使用相同密鑰的加密算法。由于其速度快,對稱性加密通常在消息發(fā)送方需要加密大量數(shù)據(jù)時使用。對稱性加密也稱為密鑰加密。
- 常見的對稱加密算法有:DES、3DES、AES
看看用對稱算法加密后,HTTP流程又是怎樣的:
圖片
- 客戶端把要發(fā)送的消息,用密鑰加密成密文。
- 客戶端把密文發(fā)送到服務器。
- 服務器收到密文消息,用同一把密鑰把密文解密成明文。
- 同理,服務端把消息報文返回給客戶端,處理過程類似。
這種方式還是有問題:
一開始客戶端怎么把密鑰發(fā)過去呢?如果不懷好意的中間人截取到了密鑰,發(fā)送的消息還是會被盜取和利用呢。
3. 非對稱加密+HTTP
既然對稱算法加密+HTTP 還是不夠安全,那我們用非對稱加密+HTTP。
什么是非對稱加密算法?
- 非對稱加密算法需要兩個密鑰:公開密鑰和私有密鑰。公開密鑰與私有密鑰是一對,如果用公開密鑰對數(shù)據(jù)進行加密,只有用對應的私有密鑰才能解密;如果用私有密鑰對數(shù)據(jù)進行加密,那么只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰,所以這種算法叫作非對稱加密算法。
- 常用非對稱加密算法:RSA、ECC
使用非對稱加密算法之后,HTTP流程又是怎樣的,如下圖:
圖片
- 客戶端向服務器發(fā)起HTTP請求
- 服務端將自己的公鑰返回到客戶端。
- 客戶端使用返回的公鑰,給要發(fā)送的消息加密。
- 客戶端將加密之后的消息密文發(fā)送給服務器。
- 服務器接收到客戶端發(fā)來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到消息數(shù)據(jù)。
這種方式依然有問題:
非對稱算法(如:RSA)有個弊端,它很慢。試想一下,如果你用瀏覽器請求,它很久才響應,你能接受嗎?
4. 非對稱加密+對稱加密+HTTP
既然非對稱加密慢。對稱加密會快好多。我們可以使用非對稱加密+對稱加密雙劍合璧的流程圖如下:
圖片
- 客戶端向服務器發(fā)起HTTP請求
- 服務端將自己的公鑰返回到客戶端。
- 客戶端產(chǎn)生對稱加密密鑰,并用服務端返回的公鑰對它加密
- 客戶端會發(fā)起第二個HTTP請求,將加密之后的客戶端密鑰發(fā)送給服務器。
- 服務器接收到客戶端發(fā)來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到客戶端密鑰,然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密,這樣數(shù)據(jù)就變成了密文。
- 服務器將加密后的密文返回給客戶端。
- 客戶端收到服務器發(fā)返回的密文,用自己的密鑰(客戶端密鑰)對其進行對稱解密,得到服務器返回的數(shù)據(jù)。
這種方式還是有問題,沒完沒了了。。。
如果中間人又來搞事情呢?要是中間人截取公鑰,把公鑰進行篡改呢? 打個比喻,把公鑰比喻你自己的手機號,它是公開的,誰都可以給你打電話。假設你發(fā)消息給你朋友,告訴他你的手機號,然后消息被中間人截取修改了,改為110,然后你朋友不知情的情況下,撥通110,打電話給你。。。
5. 數(shù)字簽名,給你的公鑰蓋個章
為了避免公鑰被篡改,引入了數(shù)字證書,如圖所下:
圖片
- 公鑰和個人信息,經(jīng)過Hash算法加密,形成消息摘要;將消息摘要拿到擁有公信力的認證中心(CA),用它的私鑰對消息摘要加密,形成數(shù)字簽名.
- 公鑰和個人信息、數(shù)字簽名共同構成數(shù)字證書。
證書驗證
圖片
- 拿到數(shù)字證書之后,用同樣的Hash算法, 先再次生成消息摘要;
- 然后用CA的公鑰對數(shù)字簽名解密, 得到CA創(chuàng)建的消息摘要, 兩者對比,就知道有沒有人篡改了。
6. 完整的HTTPS運行流程圖
圖片
- 用戶在瀏覽器里輸入一個https網(wǎng)址,然后連接到server的443端口。
- 服務器必須要有一套數(shù)字證書,可以自己制作,也可以向組織申請,區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過。這套證書其實就是一對公鑰和私鑰。
- 服務器將自己的數(shù)字證書(含有公鑰)發(fā)送給客戶端。
- 客戶端收到服務器端的數(shù)字證書之后,會對其進行檢查,如果不通過,則彈出警告框。如果證書沒問題,則生成一個密鑰(對稱加密),用證書的公鑰對它加密。
- 客戶端會發(fā)起HTTPS中的第二個HTTP請求,將加密之后的客戶端密鑰發(fā)送給服務器。
- 服務器接收到客戶端發(fā)來的密文之后,會用自己的私鑰對其進行非對稱解密,解密之后得到客戶端密鑰,然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密,這樣數(shù)據(jù)就變成了密文。
- 服務器將加密后的密文返回給客戶端。
- 客戶端收到服務器發(fā)返回的密文,用自己的密鑰(客戶端密鑰)對其進行對稱解密,得到服務器返回的數(shù)據(jù)。