十分鐘瞭解HTTPS

1、爲何要用HTTPS——HTTP協議的缺陷

1. 通訊使用明文（不加密），內容可能會被竊聽

2. 不能驗證通訊方的身份，因此請求和響應都有多是攻擊者發送的

   數據包在由A到B的過程當中，可能經歷不少次路由轉發，這個過程當中數據包可能會被劫持和替換，A和B都沒法肯定收到的信息是否就是對方發送的。

3. 沒法證實報文的完整性，多是通過篡改的信息。

   一樣是在A到B傳輸過程當中，數據包被劫持、篡改以後繼續傳輸，雖然接收方收到的數據包就是發送方發送的那個，可是內容已經遭到篡改，這樣沒法保證報文的完整性。

2、HTTPS是怎麼克服這些缺陷的？

2.1 HTTPS是什麼？

HTTPS： 在HTTP通訊時增長一層TLS通訊，之前是HTTP直接和TCP通訊，如今HTTP先與TLS通訊，再由TLS和TCP進行通訊。HTTPS擁有加密、證書校驗身份、準確性校驗這些功能，避免了HTTP的三個缺陷。

TLS的前身是SSL，TLS 1.0一般被標示爲SSL 3.1，TLS 1.1爲SSL 3.2，TLS 1.2爲SSL 3.3。

HTTP創建通訊時，只須要進行TCP三次握手就能夠開始傳輸數據了，而HTTPS在創建通訊時，先進行TCP三次握手，再進行TLS握手，而後開始發送數據。

2.2 HTTPS的加密功能

加密技術分爲：

1. 共享密鑰加密，也叫對稱密鑰加密，只有一把密鑰，通訊方必須先將密鑰發送給接收方，而後接收方使用密鑰對密文解密，可是密鑰發送的過程很難保證安全，一旦密鑰被竊取，就不能保證加密的安全了。

2. 公開密鑰加密，即非對稱密鑰加密，有兩把密鑰，公鑰public key 和私鑰private key

   公鑰是公開的，能夠隨意發佈，任何人均可以得到。A使用B發佈的公鑰加密報文，B接收後使用本身的私鑰進行解密，這樣私鑰不須要傳輸，也就沒必要擔憂被竊取的風險。

對稱加密處理速度要比非對稱加密要快，因此在保證安全的基礎上，應多使用對稱加密方式。TLS採用非對稱加密的加密方式，HTTPS採用混合加密機制： 大部分通訊使用對稱密鑰加密，但首次交換共享密鑰時是使用非對稱加密的方式，這樣就既保證了安全，又速度最快。

2.3 HTTPS的身份認證功能

按照上文介紹的非對稱加密方式，會有一個安全缺陷：客戶端怎麼知道拿到的公鑰是否就是服務端發放的公鑰呢，由於在拿到的過程當中，公鑰有可能被掉包。因而爲了不這個缺陷，引入了證書的概念。

公鑰證書

爲了保證公鑰是目標服務器發行的公鑰，須要使用權威第三方機構（如下稱爲CA機構）頒發的公鑰證書：

• 服務器去CA機構申請證書，機構頒發加數字簽名的公鑰證書，數字簽名可使用CA機構的公鑰來驗證；
• 服務器把公鑰證書以公開密鑰加密方式傳給客戶端；
• 瀏覽器內會植入經常使用CA機構的公鑰；
• 客戶端從瀏覽器拿到CA機構的公鑰，並用它驗證收到的公鑰證書的數字簽名，驗證經過，證實服務器的公鑰值得信任，客戶端就從公鑰證書取出公鑰。

總結一下就是服務器傳遞的公鑰上有CA的簽名，客戶端經過驗證簽名證明服務器的身份，並安全地獲得公鑰。

HTTPS首次交換共享密鑰使用的是非對稱加密方式，這種加密方式會使用公鑰證書來驗證服務端的身份。而想要驗證客戶端的身份就不是那麼容易了，須要用戶去申請證書，並且權威機構的證書是要花錢的，因此客戶端身份驗證充滿挑戰。現狀是，僅有特殊用途的業務實現了客戶端證書，好比那些可支撐客戶端證書支出費用的業務，例如銀行網銀就採用了客戶端證書。

2.4 HTTPS的完整性校驗功能

在HTTPS的通訊流程中，應用層發送數據時，會附加一種叫作MAC的報文摘要，MAC可以查知報文是否遭到篡改，從而保護報文的完整性。

3、HTTPS創建通訊的過程簡介

HTTPS首次創建通訊時，假設C是客戶端client，S是服務器端server，以SSL爲例：

 

1. C/S會先進行TCP三次握手；

2. 而後C發送Client Hello報文及其餘SSL信息，表示開始SSL通訊過程；

3. S收到後回以Server Hello及其餘SSL信息，此外S還發送公鑰證書，隨後發送Server Hello Done通知Client SSL握手協商部分結束

   即SSL第一次握手結束，這個過程最重要的是S把公鑰證書交給了C；

4. C驗證公鑰證書有效性，而後取出公鑰，而後：

   • 回以Client Key Exchange報文，報文中包含經過公鑰加密過的Pre-master-secret是一個隨機密碼串。
   • C接着發送Change Cipher Spec報文，告訴S此報文後的通訊會用Pre-master-secret進行加密。
   • C發送Finished報文，幷包含上述所有報文的總體校驗值。此次握手協商可否成功，要看S是否正確解密該報文。

5. S收到加密過的pre-master secret，用本身的私鑰獲得pre-master secret，而後：

   • 發送Change Cipher Spec報文

   • S發送Finished報文。

6. C/S使用pre-master secret+客戶端隨機數+服務端隨機數通過一系列算法，生成master secret 主密鑰，使用master secret生成對稱密鑰session key，以後傳輸的收據均使用session key加密解密。

至此，SSL鏈接創建完成，這個過程最重要的是C把Pre-master-secret用上一步傳遞的公鑰加密後傳給S。以後開始進行HTTP通訊，並用共享密鑰對通訊進行對稱加密。

4、HTTPS的問題

當使用SSL時，它的處理速度變慢：

1. 通訊速度變慢，由於除了HTTP請求和響應，還要進行SSL通訊，通訊量會增長
2. 由於C/S端都要加密解密，更耗計算資源，SSL加速器能夠改善S端問題

建議的是若是非敏感信息使用HTTP通訊，只有在包含我的信息等敏感數據時，才利用HTTPS進行通訊。特別是訪問量較多的網站在加密處理時，會承擔較大的負載，能夠僅在須要信息隱藏時才加密，以節約資源。可是查看淘寶、京東都是全部請求都採用的HTTPS，也有搜索到一些講部分頁面採用HTTP，部分頁面採用HTTPS的部署方法的博文，由於如今我對部署這一塊的東西還比較生疏，因此後續有時間再關注。

默認端口

1. HTTP默認端口80
2. HTTPS默認端口443

下面咱們來聊一聊HTTPS如何作到防劫持。

SSL握手

先來看看HTTPS創建鏈接的過程，相比HTTP的三次握手，HTTPS在三次握手以後多了SSL握手。以下圖：

 

SSL握手

整個流程大概以下：
1.瀏覽器將本身支持的一套加密規則發送給網站。

2.網站部署了一組SSL祕鑰，分私鑰和祕鑰。

3.網站從瀏覽器的加密規則中選出一組加密算法與HASH算法，並將本身的身份信息（公鑰）以證書的形式發回給瀏覽器。證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。

4.得到網站證書以後瀏覽器要作如下工做：

a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），若是證書受信任，則瀏覽器欄裏面會顯示一個小鎖頭，不然會給出證書不受信的提示。

b) 若是證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。

c) 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密。這個加密過程是非對稱加密，即公鑰加密，私鑰解密。私鑰只在網站服務器上存儲，其餘人沒法得到這個私鑰，也就沒法解密。可理解爲公鑰是鎖，私鑰是鑰匙，客戶端將隨機數用公鑰鎖上，通過網絡傳輸到服務器，整個過程就算有人攔截了信息，因爲沒有私鑰解鎖，也就沒法解密。

過程以下圖：

 

CA證書校驗

5.將生成的全部信息發送給網站。

6.網站接收瀏覽器發來的數據以後，使用本身的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。

7.使用密碼加密一段握手消息，發送給瀏覽器。

8.瀏覽器解密並計算握手消息的HASH，若是與服務端發來的HASH一致，此時握手過程結束，以後全部的通訊數據將由以前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密。

這裏瀏覽器與網站互相發送加密的握手消息並驗證，目的是爲了保證雙方都得到了一致的密碼，而且能夠正常的加密解密數據，爲後續真正數據的傳輸作一次測試。

備註：非對稱加密算法用於在握手過程當中加密生成的密碼，對稱加密算法用於對真正傳輸的數據進行加密，而HASH算法用於驗證數據的完整性。因爲瀏覽器生成的密碼是整個數據加密的關鍵，所以在傳輸的時候使用了非對稱加密算法對其加密。非對稱加密算法會生成公鑰和私鑰，公鑰只能用於加密數據，所以能夠隨意傳輸，而網站的私鑰用於對數據進行解密，因此網站都會很是當心的保管本身的私鑰，防止泄漏。

如何防劫持

對於HTTP請求來講，常見的劫持有DNS劫持和內容劫持。

舉個網上的例子，有人在知乎問過一個問題。

在瀏覽器輸入以下域名https:// www.zhihu.com那瀏覽器要打開這個網站，首先要解析域名www.zhihu.com,結果這個域名被黑客劫持到他的私人服務器1.2.3.4,結果個人瀏覽器和他 的私人服務器1.2.3.4創建SSL鏈接，他的服務器1.2.3.4也和www.zhihu.com創建SSL的鏈接，我收發的數據都經過他的服務器1.2.3.4中轉，也就是黑客的服務器1.2.3.4至關於一個https代理服務器，結果我收發的全部數據，他都能看到。可能這樣被劫持嗎？

這個黑客的攻擊就是一般說的中間人攻擊，跳轉1.2.3.4就是DNS劫持，DNS被劫持到一個非源端的IP上。咱們根據上文SSL握手的流程來分析一下，這種可能性是否存在。

首先若是黑客要跟你的瀏覽器創建SSL鏈接，那麼他須要有一個CA證書，而一般系統內置根證書都是大型機構的根證書，幾乎沒法僞造。若是非要作一個只能是自簽名證書。

 

Paste_Image.png

瀏覽器拿着對方的自簽名證書和系統證書進行校驗，結果必定是以下圖所示：

 

Paste_Image.png

若是他要假冒其餘機構頒發證書，由於沒有頒發機構的祕鑰，那麼這個證書的指紋必定沒辦法對上，仍是同樣會報警。

 

Paste_Image.png

除非用戶本身主動導入一個本身信任的證書。

 

12306

記住，不要隨便安裝受信任證書，不然HTTPS也幫不了你。咱們平時爲了調試HTTPS請求，使用Charles/MitmProxy進行抓包，也須要在手機端導入一個證書，讓用戶選擇信任安裝，目的就是將Charles/MitmProxy做爲中間人代理，若是沒有用戶信任安裝證書的過程，也一樣沒法解析HTTPS的請求包。

還有人就說了，我可讓用戶回落到HTTP協議啊，中間人用HTTPS跟服務器通訊，而後用HTTP跟客戶端通訊——要知道大部分用戶在地址欄輸入URL時，並無指定協議的習慣，都是打www開頭而不是打https://www開頭，能用HTTPS全是Web+Server上80端口301+Location到HTTPS的功勞。

看起來彷佛中間人充當了一個替換頁面裏HTTPS資源到HTTP的反向代理，好像可行性仍是很高。

可是隻要利用HSTS（HTTP+Strict+Transport+Security，RFC6797）就能夠解決這個問題。經過在HTTP+Header中加入Strict-Transport-Security的聲明，告訴瀏覽器在必定時間內必須經過HTTPS協議訪問本域名下的資源。

這種狀況下，只要用戶曾經在安全網絡環境下訪問過一次某站，中間人在指定時間內也沒法讓其回落到HTTP。

解決完DNS劫持，再看內容劫持就簡單多了。

你做爲一箇中間人，你沒有服務器私鑰A，是不能解密客戶端發送的內容的，若是你沒有客戶端本身生成的密鑰B，因此你也不能解密客戶端發過去的內容的。

總結：
1.CA證書保證了公鑰的可靠性。
2.服務端私鑰+公鑰的非對稱加解密保證了客戶端生成的隨機數傳輸安全，不會被中間人攔截獲取。But，非對稱加密對服務端開銷大。
3.因此利用隨機數的對稱加密保證後續通信的安全性，也能夠下降服務器的解密開銷。
4.HTTPS只針對傳輸內容進行加密，保證的是客戶端和網站之間的信息就算被攔截也沒法破解。若是不是全站HTTPS，僅僅只是在登陸頁採用HTTPS，那些HTTP鏈接的頁面一樣是危險的，從HTTP->HTTPS跳轉依然可能被劫持。國內的部分銀行就是這樣，對安全性的考量還比不上百度，百度早就全站HTTPS了。

參考

1. 深刻理解HTTPS協議
2. 《圖解HTTP》
3. HTTPS工做原理
4. SSL的保密性、真實性、完整性和不能否認性
5. Nginx部署部分https與部分http

做者：superMaryyy連接：https://juejin.im/post/5b762e726fb9a009c72cb73f來源：掘金著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。