HTTPS可以看作是安全的HTTP囤屹，你可能聽說過關(guān)于HTTPS的一些問題熬甚，比如什么握手，什么證書肋坚，加密之類的等等乡括。
HTTPS為何能保障web的安全，其運行原理是怎樣的智厌，當我們深入了解下去诲泌，其設計的思路對我們其他安全方面的設計也有一定的啟發(fā)作用。
與HTTP的區(qū)別
簡單來說峦剔，HTTPS就是在HTTP的基礎上加了一層安全協(xié)議档礁，用以保障數(shù)據(jù)安全。
HTTP HTTPS
|--------| |-----------|
|HTTP | |HTTP |
|--------| |-----------|
|TCP | |SSL or TLS |
|--------| |-----------|
|IP | |TCP |
|--------| |-----------|
|IP |
|-----------|
如上圖吝沫，HTTPS相比HTTP多了一層SSL/TLS呻澜。
HTTPS流程
HTTPS流程包含握手和后續(xù)的數(shù)據(jù)傳輸，握手的目的是為了客戶端與服務端協(xié)商加密算法等參數(shù)惨险。
SSL/TLS基本過程是這樣的：
- 客戶端向服務器端所要并驗證證書
- 雙方協(xié)定加密算法以及“對話密鑰”
- 雙方采用協(xié)商后的“對話密鑰”進行加密通信
前兩步羹幸，被稱作“握手階段”。
握手流程如上面圖中紅色部分辫愉。
- 客戶端首次請求服務器栅受，告訴服務器自己支持的協(xié)議版本，支持的加密算法及壓縮算法恭朗，并生成一個隨機數(shù)（client random）告知服務器屏镊。
客戶端需要提供的信息：支持的協(xié)議版本，如TSL1.0版本痰腮；客戶端生成的隨機數(shù)而芥，用以稍后生成“對話密鑰”；支持的加密算法膀值；支持的壓縮方法
- 服務器確認雙方使用的加密方法棍丐，并返回給客戶端證書以及一個服務器生成的隨機數(shù)（server random）
服務器需要提供的信息：協(xié)議的版本；加密的算法沧踏；服務器生成的隨機數(shù)歌逢；服務器證書；
- 客戶端收到證書后翘狱，首先驗證證書的有效性秘案，然后生成一個新的隨機數(shù)（premaster secret），并使用數(shù)字證書中的公鑰，加密這個隨機數(shù)阱高，發(fā)送給服務器师骗。
客戶端會對服務器下發(fā)的證書進行驗證，驗證通過后讨惩，客戶端會再次生成一個隨機數(shù)（premaster secret）辟癌，然后使用服務器證書中的公鑰進行加密，以及放一個ChangeCipherSpec消息即編碼改變的消息荐捻，還有整個前面所有消息的hash值黍少，進行服務器驗證，然后用新秘鑰加密一段數(shù)據(jù)一并發(fā)送到服務器处面，確保正式通信前無誤厂置。
- 服務器接收到加密后的隨機數(shù)后，使用私鑰進行解密魂角，獲取這個隨機數(shù)（premaster secret）
- 服務器和客戶端根據(jù)約定的加密方法昵济，使用前面的三個隨機數(shù)（client random, server random, premaster secret），生成“對話密鑰”（session key）野揪，用來加密接下來的整個對話過程访忿。
從上面的流程來看，需要注意一下幾點：
- 生成對話密鑰需要三個隨機數(shù)斯稳，但整個通話的安全海铆，只取決于第三個隨機數(shù)能不能被破解。因為前兩個隨機數(shù)通信過程中并未加密挣惰，明文通信卧斟，存在被攔截的可能。
- 握手之后的對話憎茂，使用“對話密鑰”進行加密珍语，采用對稱加密。服務器的公鑰和私鑰只用于加密和解密“對話密鑰”
幾個問題
1??為什么握手過程需要三個隨機數(shù)竖幔，而且安全性只取決于第三個隨機數(shù)板乙？
前兩個隨機數(shù)采用明文傳輸，存在被攔截的風險赏枚，最終對話密鑰安全性只和第三個隨機數(shù)有關(guān)亡驰，那么前兩個隨機數(shù)有沒有必要晓猛？
"不管是客戶端還是服務器饿幅，都需要隨機數(shù)，這樣生成的密鑰才不會每次都一樣戒职。由于SSL協(xié)議中證書是靜態(tài)的栗恩，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說洪燥，pre-master-key本身就是一個隨機數(shù)磕秤，再加上hello消息中的隨機乳乌，三個隨機數(shù)通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)市咆，如果隨機數(shù)不隨機汉操，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了蒙兰，因此必須引入新的隨機因素磷瘤，那么客戶端和服務器加上pre master secret三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機搜变，可是是三個偽隨機就十分接近隨機了采缚，每增加一個自由度，隨機性增加的可不是一挠他。"
所以簡單來說扳抽，采用三個隨機數(shù)是為了是最終的對話密鑰更“隨機”。
2??為什么HTTPS的流程設計這么復雜殖侵，只用對稱加密或非對稱加密加密信息不可么贸呢？
不可。
對于對稱加密拢军，存在最大的問題就是贮尉，密鑰的存儲與分發(fā)。由于對稱加密算法加密朴沿，解密過程使用同一個密鑰猜谚，因此，密鑰在傳輸過程中如果被攔截赌渣，那么等同于明文傳輸魏铅。
如果只是簡單的使用非對稱加密，由于公鑰是公開的坚芜，如果服務器返回的加密內(nèi)容被黑客攔截览芳，那么黑客可以直接使用公鑰進行解密，獲取其中的內(nèi)容鸿竖。
因此HTTPS將對稱加密與非對稱加密結(jié)合起來沧竟，先在握手階段采用非對稱加密算法傳輸對話密鑰，確定對話密鑰后缚忧，采用對稱加密算法加密會話內(nèi)容悟泵。
而且，由于對稱加密算法比非對稱加密要快闪水， 所以糕非，采用 '非對稱加密+對稱加密' 這種混合模式比 '非對稱加密+非對稱加密' 這種模式效率也高。可以說是在安全性以及性能方面的綜合考慮朽肥。
3??對于證書的驗證禁筏，客戶端是如何做的？
首先衡招，服務器端需要先向CA機構(gòu)申請證書篱昔，申請證書的時候，服務器向CA機構(gòu)提供服務器的公鑰始腾，CA機構(gòu)用自己的CA私鑰對服務器的公鑰進行簽名旱爆，生成數(shù)字摘要，然后將服務器公鑰和數(shù)字簽名打進證書窘茁。
客戶端從服務器拿到證書后怀伦，根據(jù)證書上的CA簽發(fā)機構(gòu)，從內(nèi)置的根證書里找到對應的CA機構(gòu)公鑰山林，用此公鑰解開數(shù)字簽名房待，得到摘要，根據(jù)此驗證證書的合法性驼抹。
4??fiddler/charles等可實現(xiàn)對https請求的攔截桑孩，怎么實現(xiàn)的？
首先框冀，fiddler/charles要實現(xiàn)對https的攔截流椒，首先要做的就是，在客戶端安裝fiddler/charles自己導出的證書明也，并信任該證書宣虾。
原理就是，fiddler/charles在客戶端和服務器間充當了中間人的角色温数，在客戶端面前假裝是https服務器绣硝，在真正的https服務器前假裝是客戶端。
流程如下圖：
- fiddler/charles攔截客戶端發(fā)送給https服務器的握手請求撑刺，并偽裝成客戶端向服務器發(fā)送請求進行握手
- 服務器發(fā)回響應鹉胖，fiddler/charles獲取到服務器的CA證書，用根證書公鑰進行解密够傍，驗證服務器數(shù)字簽名甫菠，獲取到服務器CA證書的公鑰。然后fiddler/charles偽造自己的CA證書冕屯，冒充服務器證書傳遞給客戶端瀏覽器寂诱。
- 與普通過程中客戶端操作相同，客戶端根據(jù)返回的數(shù)據(jù)進行證書校驗愕撰，校驗時由于已提前導入了fiddler/charles中導出的根證書刹衫，所以這里證書校驗會通過。通過校驗后搞挣，客戶端生成 pre_master带迟，用fiddler/charles偽造的證書公鑰加密，并生成https通信用的對稱密鑰 enc_key囱桨。
- fiddler/charles攔截到密文仓犬，用自己偽造證書的私鑰解開，得到enc_key舍肠，并將該密鑰使用服務器證書中的公鑰加密并傳遞給真正的https服務器搀继。
- https服務器收到密文后，利用自己的私鑰解開該對稱加密密鑰翠语，建立信任叽躯，握手完成，并使用對稱密鑰加密消息肌括，開始通信点骑。
- fiddler/charles攔截到服務器發(fā)送的密文，用對稱密鑰解開谍夭，獲得密文黑滴，再次加密，發(fā)送給客戶端紧索。
- 同樣袁辈，客戶端向服務器發(fā)送消息時，用對稱密鑰加密珠漂，被fiddler/charles攔截晚缩，解密獲得明文，再次加密媳危，發(fā)送給服務器橡羞。
之后的整個過程，fiddler/charles都將會持有對稱加密的密鑰济舆，因此對于客戶端和服務器來說卿泽，它們相對于是透明的，整個過程是無感知的滋觉。
整個過程的關(guān)鍵在于签夭，客戶端安裝并信任了fiddler/charles導出的根證書，使得fiddler/charles可以在客戶端面前偽裝成服務器椎侠，在服務器面前偽裝成客戶端第租，所以才能攔截https加密數(shù)據(jù)。
總結(jié)一下
- HTTPS整個過程采用了對稱加密與非對稱加密兩種加密方式我纪，非對稱加密通過證書方式實現(xiàn)慎宾，用于加密傳輸后續(xù)對稱加密算法用到的密鑰丐吓。對稱加密用于加密報文。這樣做的目的在于趟据，保證安全的同時券犁，提高加解密效率。
- 客戶端驗證服務器端的證書汹碱，然后通過協(xié)商采用一種非對稱加密算法加密傳輸對稱加密時所需要的密鑰粘衬，然后使用該密鑰加密傳輸報文。
- HTTPS從邏輯上是安全的咳促，但前提是服務器端采用的證書得通過安全機構(gòu)的認證稚新，而且我們得信任該機構(gòu)。
