1.HTTP傳輸協(xié)議的缺點
在上一篇文章中詳細講解了TCP/IP協(xié)議棧中的幾個協(xié)議，其中就有對HTTP做了一個比較詳細的講解。我們知道，HTTP協(xié)議基于TCP進行傳輸?shù)?，其中傳輸?shù)膬?nèi)容全都裸露在報文中，如果我們獲取了一個HTTP消息體，那我們可以知道消息體中所有的內(nèi)容。這其實存在很大的風險，如果HTTP消息體被劫持，那么整個傳輸過程將面臨：
- （1） 竊聽風險（eavesdropping）：第三方可以獲知通信內(nèi)容。
- （2） 篡改風險（tampering）：第三方可以修改通信內(nèi)容。
- （3） 冒充風險（pretending）：第三方可以冒充他人身份參與通信。
正因為HTTP協(xié)議的這個缺點, HTTP變成了一種不安全的協(xié)議。
2. 加密協(xié)議SSL/TLS
互聯(lián)網(wǎng)加密通信協(xié)議的歷史，幾乎與互聯(lián)網(wǎng)一樣長。
1994年，NetScape公司設(shè)計了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布。
1995年，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴重漏洞。
1996年，SSL 3.0版問世，得到大規(guī)模應用。
1999年，互聯(lián)網(wǎng)標準化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。
目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經(jīng)實現(xiàn)了TLS 1.2的支持。
TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
3.更加安全的HTTPS
我們知道HTTP的缺點就是報文裸露沒有加密，如果我們對報文進行加密，那么這個缺點就被解決了。通過HTTP和SLL的結(jié)合，誕生的HTTPS就是我們這篇文章的主角。
4. HTTP協(xié)議和SLL/TLS協(xié)議是如何結(jié)合使用的
4.1 加密算法
據(jù)記載，公元前400年，古希臘人就發(fā)明了置換密碼；在第二次世界大戰(zhàn)期間，德國軍方啟用了“恩尼格瑪”密碼機，所以密碼學在社會發(fā)展中有著廣泛的用途。
對稱加密
有流式、分組兩種，加密和解密都是使用的同一個密鑰。
例如：DES、AES-GCM、ChaCha20-Poly1305等
非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對稱加密算法性能較低，但是安全性超強，由于其加密特性，非對稱加密算法能加密的數(shù)據(jù)長度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE
哈希算法
將任意長度的信息轉(zhuǎn)換為較短的固定長度的值，通常其長度要比信息小得多，且算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等
數(shù)字簽名
簽名就是在信息的后面再加上一段內(nèi)容（信息經(jīng)過hash后的值），可以證明信息沒有被修改過。hash值一般都會加密后（也就是簽名）再和信息一起發(fā)送，以保證這個hash值不被修改。
4.2 對HTTP消息體對稱加密
在經(jīng)過TCP的三次握手之后，客戶端和服務(wù)器開啟了連接，如果對后續(xù)雙方傳輸?shù)膬?nèi)容進行對稱加密，那么理論上我們在本次傳輸中防止了內(nèi)容裸露。但是由于對稱加密使用秘鑰在兩端是一樣的，要維持每個客戶端的秘鑰不一致整套加密才有意義，這樣將會產(chǎn)生海量的秘鑰，維護困難。另外，因為對稱加密需要雙方協(xié)商一致，一般可用提前約定，或者使用前傳輸秘鑰，不管是哪種方式，都很容易導致秘鑰邪泄漏。只要黑客獲取到秘鑰，那么所謂的加密傳輸就如同虛設(shè)了。
4.3 對HTTP消息體進行非對稱加密
我們使用非對稱加密試試。
用戶使用公鑰進行加密之后，消息體能夠安全的抵達服務(wù)器，但是在服務(wù)器返回數(shù)據(jù)的時候，黑客截取到信息之后,能夠通過公鑰對響應的內(nèi)容進行解密，最后進行篡改，導致這個加密方案失敗。另外，非對稱加密不適用與數(shù)量太大的報文，大數(shù)量的報文導致加密效率降低。
4.4 對稱加密和非對稱加密結(jié)合使用
- 對稱加密的方式，如果能夠保證秘鑰不被黑客獲取，那么它其實是很安全的，并且，對稱加密的在速度具有很大的優(yōu)勢。
- 非對稱加密在請求發(fā)起方時，盡管使用的是公鑰加密，但是因為必須使用私鑰解密的特點，因此能夠保證消息體在向服務(wù)器發(fā)送的過程中是安全的。缺點在于服務(wù)器返回的使用私鑰加密的內(nèi)容會被公鑰解開。
結(jié)合兩者的優(yōu)缺點的做法：
- 使用對稱加密對消息體進行加密。
- 對稱加密的算法和對稱秘鑰使用公鑰加密之后，在 ClientHello 時發(fā)送給服務(wù)器。
- 后續(xù)雙方的內(nèi)容進行對稱加密。
具體的做法如下圖：
那么使用這種方式時，有兩個問題。
- 如何將公鑰給到客戶端？
- 客戶端在獲取一個公鑰之后，如何確定這個公鑰是正確的服務(wù)端發(fā)出的？
直接下載公鑰不可靠的，因為黑客可能在下載公鑰的時候劫持了請求，并偽造一個公鑰返回給客戶端。后續(xù)的請求都將會被黑客欺騙。
那應該怎么做呢？
答案是：使用證書！
數(shù)字證書是一個經(jīng)證書授權(quán)中心數(shù)字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權(quán)中心的數(shù)字簽名。數(shù)字證書還有一個重要的特征就是只在特定的時間段內(nèi)有效。
數(shù)字證書是一種權(quán)威性的電子文檔，可以由權(quán)威公正的第三方機構(gòu)，即CA（例如中國各地方的CA公司）中心簽發(fā)的證書，也可以由企業(yè)級CA系統(tǒng)進行簽發(fā)。
簡單來說，證書可以攜帶公鑰，如果我們將證書給客戶端下載，那就解決了客戶端獲取公鑰的問題。 同時由于受第三方權(quán)威機構(gòu)的認證，下載后對證書進行驗證，如果證書可信（并非個人簽名），并且是我們指定的服務(wù)器上的證書，那么說明證書是真是有效的，這就解決了公鑰可能是偽造的問題。
最后附一張詳細的HTTPS請求過程圖示：
