HTTPS協(xié)議

• 前言

• HTTPS協(xié)議

• 加密方式：

• 數(shù)字證書：

• HTTPS的驗(yàn)證過程

• 重放與篡改：

前言

上一篇記錄了一下HTTP協(xié)議以及基于UDP協(xié)議實(shí)現(xiàn)的可靠傳輸協(xié)議QUIC協(xié)議。

眾所周知，HTTP協(xié)議是直接進(jìn)行明文傳輸?shù)模换ミ^程以及數(shù)據(jù)傳輸都沒有進(jìn)行加密，通信雙方也沒有進(jìn)行任何認(rèn)證，因此通信過程非常容易遭遇劫持、監(jiān)聽、篡改。嚴(yán)重情況下，會造成惡意的流量劫持。

所以在復(fù)雜的網(wǎng)絡(luò)環(huán)境中，急需一個(gè)傳輸安全的協(xié)議，于是HTTPS協(xié)議就產(chǎn)生了。

HTTPS協(xié)議

加密方式：

（1）對稱加密

加密解密使用相同的密鑰

（2）非對稱加密

加解密使用過的密鑰不同，一個(gè)是公開的公鑰，一個(gè)是私有的私鑰，公鑰加密的信息，只要私鑰才能解密，私鑰加密的信息，只有公鑰才能解密。

客戶端發(fā)送，使用服務(wù)端公鑰加密，服務(wù)端發(fā)送，使用客戶端公鑰加密。

數(shù)字證書：

證書由權(quán)威機(jī)構(gòu)CA發(fā)布，證書里有公鑰、證書所有者、證書發(fā)布機(jī)構(gòu)和證書有效期。

CA會用一個(gè)簽名算法給證書簽名，用只掌握在權(quán)威機(jī)構(gòu)手里的東西簽名了才行，這就是CA的私鑰。

下圖是微信公眾號網(wǎng)站的證書：

簽名算法：

對信息做一個(gè) Hash 計(jì)算，得到一個(gè) Hash 值，這個(gè)過程是不可逆的，也就是說無法通過 Hash 值得出原來的信息內(nèi)容。在把信息發(fā)送出去時(shí)，把這個(gè) Hash 值加密后，作為一個(gè)簽名和信息一起發(fā)出去

此時(shí)請求會得到一個(gè)證書，證書有個(gè)發(fā)布機(jī)構(gòu)CA，只要獲取此CA的公鑰，去解密證書的簽名，解密成功并Hash也對的上，就說明這個(gè)公鑰沒有問題。

請求的時(shí)候?qū)⒆C書（證書也是通過CA私鑰加密的）發(fā)給服務(wù)端，服務(wù)端獲取到相應(yīng)機(jī)構(gòu)的公鑰，用來解密證書，解密后，校驗(yàn)Hash值，如果校驗(yàn)成功，說明公鑰沒問題，此時(shí)就會獲取到客戶端的公鑰。

如何確定CA的公鑰就是正確的？

CA 的公鑰也需要更牛的 CA 給它簽名，然后形成 CA 的證書。

要想知道某個(gè) CA 的證書是否可靠，要看 CA 的上級證書的公鑰，能不能解開這個(gè) CA 的簽名。

這樣層層上去，直到全球皆知的幾個(gè)著名大 CA，稱為 root CA，做最后的背書。

通過這種層層授信背書的方式，從而保證了非對稱加密模式的正常運(yùn)轉(zhuǎn)。

HTTPS的驗(yàn)證過程

https 通信分為四個(gè)步驟：

1. c->s,客戶端發(fā)起加密通信請求，這個(gè)請求通常叫做 ClientHello請求，告知自己支持的協(xié)議版本號，加密算法，壓縮算法，以及一個(gè)用于生成后續(xù)通信密鑰的隨機(jī)數(shù)；

2. s->c,服務(wù)端響應(yīng)，也叫作 ServerHello，確認(rèn)加密通信協(xié)議，加密算法，以及一個(gè)用于生成后續(xù)通信密鑰的隨機(jī)數(shù)，還有網(wǎng)站證書；

3. c->s,客戶端在收到上一步服務(wù)端的響應(yīng)之后，首先會檢查證書的頒發(fā)者是否可信任，是否過期，域名是否一致，并且從操作系統(tǒng)的證書鏈中找出該證書的上一級證書，并拿出服務(wù)端證書的公鑰，然后驗(yàn)證簽名和hash，如果驗(yàn)證失敗，就會顯示警告，會在瀏覽器看到，“此網(wǎng)站有風(fēng)險(xiǎn)，是否繼續(xù)什么的”。如果驗(yàn)證通過，客戶端會向服務(wù)端發(fā)送一個(gè)稱作 “pre-master-key” 的隨機(jī)數(shù)，該隨機(jī)數(shù)使用證書的公鑰加密，以及編碼改變通知（以后咋們就用協(xié)商的密鑰堆成加密通信了），客戶端完成握手。

4. 服務(wù)端在收到上一步客戶端請求之后，也會確認(rèn)以后發(fā)給客戶端的信息都是加密的，并且完成握手。

此時(shí)，客戶端有第一步自己生成的隨機(jī)數(shù)，第二步收到服務(wù)端的隨機(jī)數(shù)，第三步的 pre-master-key，服務(wù)端也是如此，他們就可以用這三個(gè)隨機(jī)數(shù)使用約定的算法生成同一個(gè)密鑰來加密以后的通信數(shù)據(jù)了。

重放與篡改：

有了加密和解密，黑客截獲了包也打不開了，但是它可以發(fā)送 N 次。

這個(gè)往往通過 Timestamp 和 Nonce 隨機(jī)數(shù)聯(lián)合起來，然后做一個(gè)不可逆的簽名來保證。

Nonce 隨機(jī)數(shù)保證唯一，或者 Timestamp 和 Nonce 合起來保證唯一，同樣的，請求只接受一次，于是服務(wù)器多次收到相同的 Timestamp 和 Nonce，則視為無效即可。

如果有人想篡改 Timestamp 和 Nonce，還有簽名保證不可篡改性，如果改了用簽名算法解出來，就對不上了，可以丟棄了。

Nonce是由服務(wù)器生成的一個(gè)隨機(jī)數(shù)，在客戶端第一次請求頁面時(shí)將其發(fā)回客戶端；客戶端拿到這個(gè)Nonce，將其與用戶密碼串聯(lián)在一起并進(jìn)行非可逆加密（MD5、SHA1等等），然后將這個(gè)加密后的字符串和用戶名、Nonce、加密算法名稱一起發(fā)回服務(wù)器；服務(wù)器使用接收到的用戶名到數(shù)據(jù)庫搜索密碼，然后跟客戶端使用同樣的算法對其進(jìn)行加密，接著將其與客戶端提交上來的加密字符串進(jìn)行比較，如果兩個(gè)字符串一致就表示用戶身份有效。這樣就解決了用戶密碼明文被竊取的問題，攻擊者就算知道了算法名和nonce也無法解密出密碼。

每個(gè)nonce只能供一個(gè)用戶使用一次，這樣就可以防止攻擊者使用重放攻擊，因?yàn)樵揌ttp報(bào)文已經(jīng)無效。可選的實(shí)現(xiàn)方式是把每一次請求的Nonce保存到數(shù)據(jù)庫，客戶端再一次提交請求時(shí)將請求頭中得Nonce與數(shù)據(jù)庫中得數(shù)據(jù)作比較，如果已存在該Nonce，則證明該請求有可能是惡意的。然而這種解決方案也有個(gè)問題，很有可能在兩次正常的資源請求中，產(chǎn)生的隨機(jī)數(shù)是一樣的，這樣就造成正常的請求也被當(dāng)成了攻擊，隨著數(shù)據(jù)庫中保存的隨機(jī)數(shù)不斷增多，這個(gè)問題就會變得很明顯。所以，還需要加上另外一個(gè)參數(shù)Timestamp（時(shí)間戳）。

Timestamp是根據(jù)服務(wù)器當(dāng)前時(shí)間生成的一個(gè)字符串，與nonce放在一起，可以表示服務(wù)器在某個(gè)時(shí)間點(diǎn)生成的隨機(jī)數(shù)。這樣就算生成的隨機(jī)數(shù)相同，但因?yàn)樗鼈兩傻臅r(shí)間點(diǎn)不一樣，所以也算有效的隨機(jī)數(shù)