咱們爲何要用 HTTPS

咱們爲何要用 HTTPS

摘要：本文屬於原創，歡迎轉載，轉載請保留出處：https://github.com/jasonGeng88/blog

前言

講 HTTPS 以前，咱們先來回顧一下 HTTP 協議。HTTP 是一種超文本傳輸協議，它是無狀態的、簡單快速的、基於 TCP 的可靠傳輸協議。

既然 HTTP 協議這麼好，那怎麼有冒出來了一個 HTTPS 呢？主要是由於 HTTP 是明文傳輸的，這就形成了很大的安全隱患。在網絡傳輸過程當中，只要數據包被人劫持，那你就至關於赤身全裸的暴露在他人面前，毫無半點隱私可言。想象一下，若是你連了一個不可信的 WIFI，正好有使用了某個支付軟件進行了支付操做，那麼你的密碼可能就到別人手裏去了，後果可想而知。

網絡環境的就是這樣，給你帶來便利的同時，也處處充滿了挑戰與風險。對於小白用戶，你不能指望他有多高的網絡安全意識，產品應該經過技術手段，讓本身變得更安全，從源頭來控制風險。這就誕生了 HTTPS 協議。

HTTPS

簡單理解，HTTP 不就是由於明文傳輸，因此形成了安全隱患。那讓數據傳輸以加密的方式進行，不就消除了該隱患。

從網絡的七層模型來看，原先的四層 TCP 到七層 HTTP 之間是明文傳輸，在這之間加一個負責數據加解密的傳輸層（SSL/TLS），保證在網絡傳輸的過程當中數據是加密的，而 HTTP 接收到的依然是明文數據，不會有任何影響。

SSL是Netscape開發的專門用戶保護Web通信的，目前版本爲3.0。最新版本的TLS 1.0是IETF(工程任務組)制定的一種新的協議，它創建在SSL 3.0協議規範之上，是SSL 3.0的後續版本。二者差異極小，能夠理解爲SSL 3.1，它是寫入了RFC的。

優點

<font color="grey">本節參考阮一峯的SSL/TLS協議運行機制的概述。</font>

在看實現細節以前，咱們先看一下 HTTP 具體的安全隱患，以及 HTTPS 的解決方案。

HTTP 三大風險：

1. 竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。

2. 篡改風險（tampering）：第三方能夠修改通訊內容。

3. 冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

HTTPS 解決方案

1. 全部信息都是加密傳播，第三方沒法竊聽。

2. 具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

3. 配備身份證書，防止身份被冒充。

實現

經過上面的介紹，對 HTTPS 有了大體的瞭解。可本質問題還沒說，HTTPS 是如何作到數據的加密傳輸？這兒不打算搬出複雜的算法公式，仍是以最通俗的話述來說講個人理解。

首先，先來了解下加密算法的方式，經常使用的有兩種：對稱加密與非對稱加密。

• 對稱加密：即通訊雙方經過相同的密鑰進行信息的加解密。加解密速度快，可是安全性較差，若是其中一方泄露了密鑰，那加密過程就會被人破解。

• 非對稱加密：相比對稱加密，它通常有公鑰和私鑰。公鑰負責信息加密，私鑰負責信息解密。兩把密鑰分別由發送雙發各自保管，加解密過程需兩把密鑰共同完成。安全性更高，但同時計算量也比對稱加密要大不少。

對於網絡通訊過程，在安全的前提下，仍是須要保證響應速度。如何每次都進行非對稱計算，通訊過程勢必會受影響。因此，人們但願的安全傳輸，最終確定是以對稱加密的方式進行。如圖：

首先 Session Key 是如何獲得的，而且在 Session Key 以前的傳輸都是明文的。Session Key 經過網絡傳輸確定不安全，因此它必定各自加密生成的。所以在這以前，雙方還要互通，確認加密的算法，而且各自添加隨機數，提升安全性。如圖：

這樣雙方確認了使用的 SSL/TLS 版本，以及生成 Session Key 的加密算法。而且雙方擁有了2個隨機數（客戶端、服務端各自生成一個）。但是若是按照目前的隨機參數，加上加密算法生成 Session Key 呢，仍是存在風險，加密算法是有限固定的，並且隨機數都是明文傳輸的，有被截獲的可能。

讓加密算法變得不可預測，可能性不大。那麼可否再傳輸一個加密的隨機數，這個隨機數就算被截獲，也沒法破譯。這就用到了非對稱加密算法，咱們在步驟二中，把公鑰傳輸給客戶端。這樣客戶端的第三個隨機數用公鑰加密，只有擁有私鑰的服務端才能破譯第三個參數，這樣生成的 Session 就是安全的了。如圖：

不容易啊，看似完成了。如今生成的 Session Key 是不可預測的（就算被截獲也無所謂），咱們能夠放心的進行私密通訊了。真的是這樣嗎？咱們彷佛對服務端給的公鑰十分信任，若是你目前通訊的自己就不可信，或者被中間人劫持，由它發送僞造的公鑰給你，那後果可想而知，這就是傳說中的「中間人攻擊」。

因此，咱們得包裝一下公鑰，讓它變得安全。這就引出了數字證書的概念，數字證書由受信任的證書機構頒發，證書包含證書文件與證書私鑰文件。私鑰文件由服務端本身保存，證書文件發送給請求的客戶端，文件包含了域名信息、公鑰以及相應的校驗碼。客戶能夠根據獲得的證書文件，校驗證書是否可信。如圖：

這下算簡單講完了整個的通訊過程，首先在 TCP 三次握手後，進行非對稱算法的加密（校驗證書），將獲得的參數進行加密生成會話所需的 Session Key，在以後的數據傳輸中，經過 Session Key 進行對稱密碼傳輸，會話信息在私密的通道下完成。

固然，實際的過程遠比這來的複雜，這中間包括了複雜的算法以及細節內容，有興趣的同窗，可查閱相關的資料進行了解。

證書

關於數字證書，下面簡單介紹一下證書的一些類別：

按驗證級別分類

• Domain Validation（DV）：最基本的驗證方式，只保證訪問的域名是安全的。但在證書中不會說起任何公司/組織信息，因此這算是最低級別的驗證。

示例：https://robowhois.com

• Organization Validation（OV）：這一級別的證書解決了上面域名與公司沒法對應的問題，該證書中會描述公司/組織的相關信息。確保域名安全的同時，也保證了域名與公司的綁定關係。

示例：https://www.baidu.com

• Extended Validation（EV）：該級別的證書具備最高的安全性，也是最值得信任的。它除了給出更詳細的公司/組織信息外，還在瀏覽器的地址欄上直接給出了公司名稱。

示例：https://www.github.com

按覆蓋級別分類

• 單域名 SSL 證書：這類證書只能針對一個域名使用，如，當證書與 yourdomain.com 配對了，那就不能在用在 sub.yourdomain.com 上了。

• 通配符域名 SSL 證書：這類證書能夠覆蓋某個域名下的全部子域名。如，當證書與 yourdomain.com 配對了，那默認 sub.yourdomain.com 以及其餘子域名都加入了安全驗證。

• 多多域名 SSL 證書：這類證書可使用在多個不一樣的域名上。如，域名 a.com 與 b.com 上能夠配對同一個證書。

從 HTTP 遷移的注意點

• 首先須要從相關的網站申請須要的證書；

• 在服務器上開放 HTTPS 所需的443端口，並設置相應的證書地址，下面貼一段在 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;
    }
}

• 對於原先的80端口，需作重定向的跳轉。將原先訪問 HTTP 協議的用戶，自動跳轉用 HTTPS 上來。

• 出於性能考慮，Session Key 的生成相對耗 CPU 的資源，因此儘可能減小 Key 的生成次數。這裏有兩種方案：

  • 採用長鏈接方式；

  • 在回話建立時，對生成的 Session Key 進行緩存（仍以 nginx 爲例）；

  http {
      #配置共享會話緩存大小
      ssl_session_cache   shared:SSL:10m;
      #配置會話超時時間
      ssl_session_timeout 10m;
      ...

總結

本文不涉及任何高深的概念，都是以本身的一些理解來進行講述，但願對你們有用！

最後，推薦一個比較好用的 HTTP 抓包工具（含 HTTPS）。

• Charles 4.0 Mac破解版

• 使用 Charles 獲取 https 的數據