1.HTTP傳輸協(xié)議的缺點(diǎn)
在上一篇文章中詳細(xì)講解了TCP/IP協(xié)議棧中的幾個協(xié)議设预，其中就有對HTTP做了一個比較詳細(xì)的講解。我們知道生年，HTTP協(xié)議基于TCP進(jìn)行傳輸?shù)拇乐眨渲袀鬏數(shù)膬?nèi)容全都裸露在報文中，如果我們獲取了一個HTTP消息體穿稳，那我們可以知道消息體中所有的內(nèi)容存皂。這其實(shí)存在很大的風(fēng)險，如果HTTP消息體被劫持逢艘，那么整個傳輸過程將面臨：
- （1） 竊聽風(fēng)險（eavesdropping）：第三方可以獲知通信內(nèi)容旦袋。
- （2） 篡改風(fēng)險（tampering）：第三方可以修改通信內(nèi)容。
- （3） 冒充風(fēng)險（pretending）：第三方可以冒充他人身份參與通信它改。
正因?yàn)镠TTP協(xié)議的這個缺點(diǎn), HTTP變成了一種不安全的協(xié)議疤孕。
2. 加密協(xié)議SSL/TLS
互聯(lián)網(wǎng)加密通信協(xié)議的歷史，幾乎與互聯(lián)網(wǎng)一樣長央拖。
1994年祭阀，NetScape公司設(shè)計(jì)了SSL協(xié)議（Secure Sockets Layer）的1.0版，但是未發(fā)布鲜戒。
1995年专控，NetScape公司發(fā)布SSL 2.0版，很快發(fā)現(xiàn)有嚴(yán)重漏洞遏餐。
1996年伦腐，SSL 3.0版問世，得到大規(guī)模應(yīng)用失都。
1999年蔗牡，互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司，發(fā)布了SSL的升級版TLS 1.0版嗅剖。
2006年和2008年辩越，TLS進(jìn)行了兩次升級，分別為TLS 1.1版和TLS 1.2版信粮。最新的變動是2011年TLS 1.2的修訂版黔攒。
目前，應(yīng)用最廣泛的是TLS 1.0，接下來是SSL 3.0督惰。但是不傅，主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。
TLS 1.0通常被標(biāo)示為SSL 3.1赏胚，TLS 1.1為SSL 3.2访娶，TLS 1.2為SSL 3.3。
3.更加安全的HTTPS
我們知道HTTP的缺點(diǎn)就是報文裸露沒有加密觉阅，如果我們對報文進(jìn)行加密崖疤，那么這個缺點(diǎn)就被解決了。通過HTTP和SLL的結(jié)合典勇，誕生的HTTPS就是我們這篇文章的主角劫哼。
4. HTTP協(xié)議和SLL/TLS協(xié)議是如何結(jié)合使用的
4.1 加密算法
據(jù)記載，公元前400年割笙，古希臘人就發(fā)明了置換密碼权烧；在第二次世界大戰(zhàn)期間，德國軍方啟用了“恩尼格瑪”密碼機(jī)伤溉，所以密碼學(xué)在社會發(fā)展中有著廣泛的用途般码。
對稱加密
有流式、分組兩種乱顾，加密和解密都是使用的同一個密鑰侈询。
例如：DES、AES-GCM糯耍、ChaCha20-Poly1305等
非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的扔字，分別稱為：公鑰、私鑰温技，公鑰和算法都是公開的革为，私鑰是保密的。非對稱加密算法性能較低舵鳞，但是安全性超強(qiáng)震檩，由于其加密特性，非對稱加密算法能加密的數(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)容進(jìn)行對稱加密并级，那么理論上我們在本次傳輸中防止了內(nèi)容裸露。但是由于對稱加密使用秘鑰在兩端是一樣的凛虽，要維持每個客戶端的秘鑰不一致整套加密才有意義死遭，這樣將會產(chǎn)生海量的秘鑰广恢，維護(hù)困難凯旋。另外，因?yàn)閷ΨQ加密需要雙方協(xié)商一致钉迷，一般可用提前約定至非，或者使用前傳輸秘鑰，不管是哪種方式糠聪，都很容易導(dǎo)致秘鑰邪泄漏荒椭。只要黑客獲取到秘鑰，那么所謂的加密傳輸就如同虛設(shè)了舰蟆。
4.3 對HTTP消息體進(jìn)行非對稱加密
我們使用非對稱加密試試趣惠。
用戶使用公鑰進(jìn)行加密之后，消息體能夠安全的抵達(dá)服務(wù)器身害，但是在服務(wù)器返回數(shù)據(jù)的時候味悄，黑客截取到信息之后,能夠通過公鑰對響應(yīng)的內(nèi)容進(jìn)行解密，最后進(jìn)行篡改塌鸯，導(dǎo)致這個加密方案失敗侍瑟。另外，非對稱加密不適用與數(shù)量太大的報文丙猬，大數(shù)量的報文導(dǎo)致加密效率降低涨颜。
4.4 對稱加密和非對稱加密結(jié)合使用
- 對稱加密的方式，如果能夠保證秘鑰不被黑客獲取茧球，那么它其實(shí)是很安全的庭瑰，并且，對稱加密的在速度具有很大的優(yōu)勢抢埋。
- 非對稱加密在請求發(fā)起方時见擦，盡管使用的是公鑰加密钉汗，但是因?yàn)楸仨毷褂盟借€解密的特點(diǎn)，因此能夠保證消息體在向服務(wù)器發(fā)送的過程中是安全的鲤屡。缺點(diǎn)在于服務(wù)器返回的使用私鑰加密的內(nèi)容會被公鑰解開损痰。
結(jié)合兩者的優(yōu)缺點(diǎn)的做法：
- 使用對稱加密對消息體進(jìn)行加密。
- 對稱加密的算法和對稱秘鑰使用公鑰加密之后酒来，在 ClientHello 時發(fā)送給服務(wù)器卢未。
- 后續(xù)雙方的內(nèi)容進(jìn)行對稱加密。
具體的做法如下圖：
那么使用這種方式時堰汉，有兩個問題辽社。
- 如何將公鑰給到客戶端？
- 客戶端在獲取一個公鑰之后翘鸭，如何確定這個公鑰是正確的服務(wù)端發(fā)出的滴铅？
直接下載公鑰不可靠的，因?yàn)楹诳涂赡茉谙螺d公鑰的時候劫持了請求就乓，并偽造一個公鑰返回給客戶端汉匙。后續(xù)的請求都將會被黑客欺騙。
那應(yīng)該怎么做呢生蚁？
答案是：使用證書噩翠！
數(shù)字證書是一個經(jīng)證書授權(quán)中心數(shù)字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰邦投、名稱以及證書授權(quán)中心的數(shù)字簽名伤锚。數(shù)字證書還有一個重要的特征就是只在特定的時間段內(nèi)有效。
數(shù)字證書是一種權(quán)威性的電子文檔志衣，可以由權(quán)威公正的第三方機(jī)構(gòu)屯援，即CA（例如中國各地方的CA公司）中心簽發(fā)的證書，也可以由企業(yè)級CA系統(tǒng)進(jìn)行簽發(fā)念脯。
簡單來說狞洋，證書可以攜帶公鑰，如果我們將證書給客戶端下載和二，那就解決了客戶端獲取公鑰的問題徘铝。 同時由于受第三方權(quán)威機(jī)構(gòu)的認(rèn)證，下載后對證書進(jìn)行驗(yàn)證惯吕，如果證書可信（并非個人簽名）惕它，并且是我們指定的服務(wù)器上的證書，那么說明證書是真是有效的废登，這就解決了公鑰可能是偽造的問題淹魄。
最后附一張?jiān)敿?xì)的HTTPS請求過程圖示：
參考：
SSL/TLS協(xié)議運(yùn)行機(jī)制的概述 - 阮一峰
HTTPS系列干貨（一）：HTTPS 原理詳解
