HTTPS 原理剖析
為什么使用 HTTPS
HTTP 協(xié)議，本身是明文傳輸?shù)?，沒有經(jīng)過任何安全處理。那么這個(gè)時(shí)候就很容易在傳輸過程中被中間者竊聽、篡改、冒充等風(fēng)險(xiǎn)。這里提到的中間者主要指一些網(wǎng)絡(luò)節(jié)點(diǎn)，是用戶數(shù)據(jù)在瀏覽器和服務(wù)器中間傳輸必須要經(jīng)過的節(jié)點(diǎn)，比如 WIFI 熱點(diǎn)，路由器，防火墻，反向代理，緩存服務(wù)器等。
HTTP 協(xié)議，中間者可以竊聽隱私，使用戶的敏感數(shù)據(jù)暴露無遺；篡改網(wǎng)頁，例如往頁面插的廣告內(nèi)容，甚至進(jìn)行流量劫持，比如有的時(shí)候你會(huì)發(fā)現(xiàn)域名沒輸錯(cuò)，結(jié)果卻跑到了一個(gè)釣魚網(wǎng)站上，因?yàn)楸凰俪至恕?/p>
為了解決這三大風(fēng)險(xiǎn)，HTTPS 的價(jià)值就體現(xiàn)出來了。
- 內(nèi)容加密，第三方無法竊聽。
- 身份認(rèn)證，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。
- 數(shù)據(jù)完整性。防止內(nèi)容冒充或者篡改。
什么是 HTTPS
HTTPS，簡(jiǎn)單的理解 HTTP 的安全版，即 HTTP 下加入 SSL 層，由兩部分組成：HTTP + SSL / TLS。
HTTPS 原理剖析
- 用戶在瀏覽器里輸入一個(gè) https 網(wǎng)址，此時(shí)客戶端發(fā)起 HTTPS 請(qǐng)求，通過 TCP 和服務(wù)器建立連接（443端口）。
- 服務(wù)器存放 CA 證書進(jìn)行處理，注意的是采用 HTTPS 協(xié)議的服務(wù)器必須要有一套數(shù)字證書，這套證書其實(shí)就是一對(duì)公鑰和私鑰。
- 服務(wù)器向客戶端返回證書。證書里面包含了很多信息：比如域名，申請(qǐng)證書的公司，公鑰等。以下是一個(gè)淘寶網(wǎng)的 CA 證書。
- 客戶端對(duì)證書進(jìn)行解析。這部分工作是有客戶端的 TLS 來完成的，首先會(huì)驗(yàn)證公鑰是否有效，比如頒發(fā)機(jī)構(gòu)，過期時(shí)間等，如果發(fā)現(xiàn)異常，則會(huì)彈出一個(gè)警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個(gè)隨機(jī)數(shù)，然后用證書對(duì)該隨機(jī)數(shù)進(jìn)行加密。
- 向服務(wù)器發(fā)送證書加密后的隨機(jī)數(shù)。
- 服務(wù)器用它的私鑰進(jìn)行解密，得到了客戶端傳過來的隨機(jī)數(shù)。
- 服務(wù)器用客戶端的隨機(jī)數(shù)加密后的信息發(fā)送給客戶端。
- 客戶端用之前生成的密鑰解密服務(wù)端傳過來的信息。
以上就是整個(gè) HTTPS 的交互過程，大家是不是對(duì)整個(gè)流程有了比較大致的了解了呢。
HTTPS 的相關(guān)場(chǎng)景
真實(shí)業(yè)務(wù)場(chǎng)景是復(fù)雜的，這里，整理 3 個(gè)項(xiàng)目中遇到的比較復(fù)雜的應(yīng)用場(chǎng)景。
場(chǎng)景一，對(duì) HTTPS 進(jìn)行 CDN 加速
這種情況下，CA 證書需要存放在哪里呢？主要兩個(gè)方案：
- 服務(wù)器（源站）提供證書給 CDN 廠商，包括公鑰證書和私鑰，CDN 負(fù)責(zé)交互和內(nèi)容緩存，CDN 有緩存則直接響應(yīng)，以 HTTP 或 HTTPS 的形式回源。這個(gè)方案，適用僅對(duì)防劫持、防篡改有需求，而愿意提供證書給 CDN 的源站加速。
- 服務(wù)器（源站）不提供證書，CDN 存放公鑰，服務(wù)器（源站）存放私鑰。在 CDN 與前端瀏覽器進(jìn)行 TLS 的認(rèn)證和秘鑰協(xié)商過程中，通過安全的信道把協(xié)商過程中的信息以 HTTP 或 HTTPS 的形式轉(zhuǎn)發(fā)給源網(wǎng)站。此方案中，CDN 不做緩存，僅以自有的加速網(wǎng)絡(luò)，將用戶的請(qǐng)求快速送到服務(wù)器（源站），降低公網(wǎng)延遲。這個(gè)方案，適用于對(duì)安全要求更高，不愿將私鑰共享給 CDN 的源站加速。
場(chǎng)景二，對(duì)HTTPS 的域名通過 CNAME 綁定到另外一個(gè) HTTPS 域名上
這個(gè)情況下，我們需要一個(gè)證書還是兩個(gè)證書呢？
我們的方案是，兩個(gè)證書。因?yàn)槊總€(gè)證書跟自己的域名進(jìn)行綁定，即使它們都在同一個(gè)服務(wù)器上，也不能使用同一個(gè)證書。
場(chǎng)景三，兩臺(tái)服務(wù)器的證書問題
因?yàn)榘踩珕栴}，CA 證書在一臺(tái)服務(wù)器上，而服務(wù)部署在另外一臺(tái)服務(wù)器上。這種情況就比較難辦。
此時(shí)，需要借助 Nginx 進(jìn)行反向代理，回源到具體的服務(wù)器。
HTTPS 設(shè)計(jì)上的借鑒
對(duì)于 HTTPS 設(shè)計(jì)上的方案，對(duì)于我們而言，有什么可以借鑒的地方么？
答案是肯定的：有。一個(gè)非常典型的方案就是 RSA 雙向認(rèn)證。
RSA 雙向認(rèn)證，顧名思義，就是用對(duì)方的公鑰加密是為了保密，這個(gè)只有對(duì)方用私鑰能解密。用自己的私鑰加密是為了防抵賴，能用我的公鑰解開，說明這是我發(fā)來的。例如，支付寶的支付接口就是非常典型的RSA雙向認(rèn)證的安全方案。此外，我們之前的教育資源、敏感驗(yàn)證碼出于安全性考慮都借鑒了這個(gè)方案。
