前言
講 HTTPS 之前，我們先來回顧一下 HTTP 協(xié)議崭放。HTTP 是一種超文本傳輸協(xié)議哨苛，它是無狀態(tài)的、簡(jiǎn)單快速的币砂、基于 TCP 的可靠傳輸協(xié)議建峭。
既然 HTTP 協(xié)議這么好，那怎么有冒出來了一個(gè) HTTPS 呢决摧？主要是因?yàn)?HTTP 是明文傳輸?shù)囊谡簦@就造成了很大的安全隱患。在網(wǎng)絡(luò)傳輸過程中掌桩，只要數(shù)據(jù)包被人劫持边锁，那你就相當(dāng)于赤身全裸的暴露在他人面前，毫無半點(diǎn)隱私可言波岛。想象一下茅坛，如果你連了一個(gè)不可信的 WIFI，正好有使用了某個(gè)支付軟件進(jìn)行了支付操作则拷，那么你的密碼可能就到別人手里去了贡蓖，后果可想而知。
網(wǎng)絡(luò)環(huán)境的就是這樣煌茬，給你帶來便利的同時(shí)斥铺，也到處充滿了挑戰(zhàn)與風(fēng)險(xiǎn)。對(duì)于小白用戶坛善，你不能期望他有多高的網(wǎng)絡(luò)安全意識(shí)晾蜘，產(chǎn)品應(yīng)該通過技術(shù)手段，讓自己變得更安全眠屎，從源頭來控制風(fēng)險(xiǎn)剔交。這就誕生了 HTTPS 協(xié)議。
HTTPS
簡(jiǎn)單理解改衩，HTTP 不就是因?yàn)槊魑膫鬏斸＃栽斐闪税踩[患。那讓數(shù)據(jù)傳輸以加密的方式進(jìn)行燎字，不就消除了該隱患腥椒。
從網(wǎng)絡(luò)的七層模型來看，原先的四層 TCP 到七層 HTTP 之間是明文傳輸候衍，在這之間加一個(gè)負(fù)責(zé)數(shù)據(jù)加解密的傳輸層（SSL/TLS）笼蛛，保證在網(wǎng)絡(luò)傳輸?shù)倪^程中數(shù)據(jù)是加密的，而 HTTP 接收到的依然是明文數(shù)據(jù)蛉鹿，不會(huì)有任何影響滨砍。
[圖片上傳失敗...(image-1f4ad-1513224051213)]
<font color="grey">SSL是Netscape開發(fā)的專門用戶保護(hù)Web通訊的，目前版本為3.0妖异。最新版本的TLS 1.0是IETF(工程任務(wù)組)制定的一種新的協(xié)議惋戏，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本他膳。兩者差別極小响逢，可以理解為SSL 3.1，它是寫入了RFC的棕孙。</font>
優(yōu)勢(shì)
<font color="grey">本節(jié)參考阮一峰的SSL/TLS協(xié)議運(yùn)行機(jī)制的概述舔亭。</font>
在看實(shí)現(xiàn)細(xì)節(jié)之前，我們先看一下 HTTP 具體的安全隱患蟀俊，以及 HTTPS 的解決方案钦铺。
HTTP 三大風(fēng)險(xiǎn)：
- 竊聽風(fēng)險(xiǎn)（eavesdropping）：第三方可以獲知通信內(nèi)容。
- 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容肢预。
- 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信矛洞。
HTTPS 解決方案
- 所有信息都是加密傳播，第三方無法竊聽烫映。
- 具有校驗(yàn)機(jī)制沼本，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)窑邦。
- 配備身份證書擅威，防止身份被冒充。
實(shí)現(xiàn)
通過上面的介紹冈钦，對(duì) HTTPS 有了大致的了解郊丛。可本質(zhì)問題還沒說瞧筛，HTTPS 是如何做到數(shù)據(jù)的加密傳輸厉熟？這兒不打算搬出復(fù)雜的算法公式，還是以最通俗的話述來講講我的理解较幌。
首先揍瑟，先來了解下加密算法的方式，常用的有兩種：對(duì)稱加密與非對(duì)稱加密乍炉。
對(duì)稱加密：即通信雙方通過相同的密鑰進(jìn)行信息的加解密绢片。加解密速度快滤馍，但是安全性較差，如果其中一方泄露了密鑰底循，那加密過程就會(huì)被人破解巢株。
非對(duì)稱加密：相比對(duì)稱加密，它一般有公鑰和私鑰熙涤。公鑰負(fù)責(zé)信息加密阁苞，私鑰負(fù)責(zé)信息解密。兩把密鑰分別由發(fā)送雙發(fā)各自保管祠挫，加解密過程需兩把密鑰共同完成那槽。安全性更高，但同時(shí)計(jì)算量也比對(duì)稱加密要大很多等舔。
對(duì)于網(wǎng)絡(luò)通信過程骚灸，在安全的前提下，還是需要保證響應(yīng)速度慌植。如何每次都進(jìn)行非對(duì)稱計(jì)算逢唤，通信過程勢(shì)必會(huì)受影響。所以涤浇，人們希望的安全傳輸鳖藕，最終肯定是以對(duì)稱加密的方式進(jìn)行。如圖：
[圖片上傳失敗...(image-4364d7-1513224051213)]
首先 Session Key 是如何得到的只锭，并且在 Session Key 之前的傳輸都是明文的著恩。Session Key 通過網(wǎng)絡(luò)傳輸肯定不安全，所以它一定各自加密生成的蜻展。因此在這之前喉誊，雙方還要互通，確認(rèn)加密的算法纵顾，并且各自添加隨機(jī)數(shù)伍茄，提高安全性。如圖：
[圖片上傳失敗...(image-1655f-1513224051213)]
這樣雙方確認(rèn)了使用的 SSL/TLS 版本施逾，以及生成 Session Key 的加密算法敷矫。并且雙方擁有了2個(gè)隨機(jī)數(shù)（客戶端、服務(wù)端各自生成一個(gè)）汉额〔苷蹋可是如果按照目前的隨機(jī)參數(shù)，加上加密算法生成 Session Key 呢蠕搜，還是存在風(fēng)險(xiǎn)怎茫，加密算法是有限固定的，而且隨機(jī)數(shù)都是明文傳輸?shù)募斯啵斜唤孬@的可能轨蛤。
讓加密算法變得不可預(yù)測(cè)蜜宪，可能性不大。那么能否再傳輸一個(gè)加密的隨機(jī)數(shù)祥山，這個(gè)隨機(jī)數(shù)就算被截獲端壳，也無法破譯。這就用到了非對(duì)稱加密算法枪蘑，我們?cè)诓襟E二中，把公鑰傳輸給客戶端岖免。這樣客戶端的第三個(gè)隨機(jī)數(shù)用公鑰加密岳颇，只有擁有私鑰的服務(wù)端才能破譯第三個(gè)參數(shù)，這樣生成的 Session 就是安全的了颅湘。如圖：
[圖片上傳失敗...(image-eaf419-1513224051213)]
不容易啊话侧，看似完成了。現(xiàn)在生成的 Session Key 是不可預(yù)測(cè)的（就算被截獲也無所謂）闯参，我們可以放心的進(jìn)行私密通信了瞻鹏。真的是這樣嗎？我們似乎對(duì)服務(wù)端給的公鑰十分信任鹿寨，如果你目前通信的本身就不可信新博，或者被中間人劫持，由它發(fā)送偽造的公鑰給你脚草，那后果可想而知赫悄，這就是傳說中的“中間人攻擊”。
所以馏慨，我們得包裝一下公鑰埂淮，讓它變得安全。這就引出了數(shù)字證書的概念写隶，數(shù)字證書由受信任的證書機(jī)構(gòu)頒發(fā)倔撞，證書包含證書文件與證書私鑰文件。私鑰文件由服務(wù)端自己保存慕趴，證書文件發(fā)送給請(qǐng)求的客戶端痪蝇，文件包含了域名信息、公鑰以及相應(yīng)的校驗(yàn)碼冕房∨常客戶可以根據(jù)得到的證書文件，校驗(yàn)證書是否可信毒费。如圖：
[圖片上傳失敗...(image-abda42-1513224051213)]
這下算簡(jiǎn)單講完了整個(gè)的通信過程丙唧，首先在 TCP 三次握手后，進(jìn)行非對(duì)稱算法的加密（校驗(yàn)證書）觅玻，將得到的參數(shù)進(jìn)行加密生成會(huì)話所需的 Session Key想际，在之后的數(shù)據(jù)傳輸中培漏，通過 Session Key 進(jìn)行對(duì)稱密碼傳輸，會(huì)話信息在私密的通道下完成胡本。
當(dāng)然牌柄，實(shí)際的過程遠(yuǎn)比這來的復(fù)雜，這中間包括了復(fù)雜的算法以及細(xì)節(jié)內(nèi)容侧甫，有興趣的同學(xué)珊佣，可查閱相關(guān)的資料進(jìn)行了解。
證書
關(guān)于數(shù)字證書披粟，下面簡(jiǎn)單介紹一下證書的一些類別：
按驗(yàn)證級(jí)別分類
- Domain Validation（DV）：最基本的驗(yàn)證方式咒锻，只保證訪問的域名是安全的。但在證書中不會(huì)提及任何公司/組織信息守屉，所以這算是最低級(jí)別的驗(yàn)證惑艇。
[圖片上傳失敗...(image-3b3829-1513224051213)]
- Organization Validation（OV）：這一級(jí)別的證書解決了上面域名與公司無法對(duì)應(yīng)的問題，該證書中會(huì)描述公司/組織的相關(guān)信息拇泛。確保域名安全的同時(shí)滨巴，也保證了域名與公司的綁定關(guān)系。
[圖片上傳失敗...(image-e2ecb1-1513224051213)]
- Extended Validation（EV）：該級(jí)別的證書具有最高的安全性俺叭，也是最值得信任的恭取。它除了給出更詳細(xì)的公司/組織信息外，還在瀏覽器的地址欄上直接給出了公司名稱熄守。
[圖片上傳失敗...(image-ba0708-1513224051213)]
[圖片上傳失敗...(image-b7eb74-1513224051213)]
按覆蓋級(jí)別分類
- 單域名 SSL 證書：這類證書只能針對(duì)一個(gè)域名使用秽荤，如，當(dāng)證書與 yourdomain.com 配對(duì)了柠横，那就不能在用在 sub.yourdomain.com 上了窃款。
- 通配符域名 SSL 證書：這類證書可以覆蓋某個(gè)域名下的所有子域名。如牍氛，當(dāng)證書與 yourdomain.com 配對(duì)了晨继，那默認(rèn) sub.yourdomain.com 以及其他子域名都加入了安全驗(yàn)證。
- 多多域名 SSL 證書：這類證書可以使用在多個(gè)不同的域名上搬俊。如紊扬，域名 a.com 與 b.com 上可以配對(duì)同一個(gè)證書。
從 HTTP 遷移的注意點(diǎn)
- 首先需要從相關(guān)的網(wǎng)站申請(qǐng)需要的證書唉擂；
- 在服務(wù)器上開放 HTTPS 所需的443端口餐屎，并設(shè)置相應(yīng)的證書地址，下面貼一段在 nginx 上的配置：
server {
listen 443;
server_name localhost;
ssl on;
root html;
index index.html index.htm;
ssl_certificate cert/證書文件.pem;
ssl_certificate_key cert/證書私鑰.key;
ssl_session_timeout 5m;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
root html;
index index.html index.htm;
}
}
對(duì)于原先的80端口玩祟，需做重定向的跳轉(zhuǎn)腹缩。將原先訪問 HTTP 協(xié)議的用戶，自動(dòng)跳轉(zhuǎn)用 HTTPS 上來。
-
出于性能考慮藏鹊，Session Key 的生成相對(duì)耗 CPU 的資源润讥，所以盡量減少 Key 的生成次數(shù)。這里有兩種方案：
- 采用長連接方式盘寡；
- 在回話創(chuàng)建時(shí)楚殿，對(duì)生成的 Session Key 進(jìn)行緩存（仍以 nginx 為例）；
http { #配置共享會(huì)話緩存大小 ssl_session_cache shared:SSL:10m; #配置會(huì)話超時(shí)時(shí)間 ssl_session_timeout 10m; ...
總結(jié)
本文不涉及任何高深的概念竿痰，都是以自己的一些理解來進(jìn)行講述脆粥，希望對(duì)大家有用！
最后影涉，推薦一個(gè)比較好用的 HTTP 抓包工具（含 HTTPS）变隔。
