Https詳細分析

目錄介紹

• 01.為何會有Https
• 02.解決方案分析
• 03.SSL是什麼
• 04.RSA驗證的隱患
• 05.CA證書身份驗證
• 06.Https工作原理
• 07.Https代理作用
• 08.Https真安全嗎
• 09.Https效能優化

01.為何會有Https

• Http的缺點
  • 通訊使用明文；
    • 通訊使用明文意味著安全性大大降低，當通訊過程被竊聽後，無需花費額外的投入就可看到傳輸的資料。
    • 例如使用抓包工具，無需任何配置就可檢視任何使用HTTP協議的通訊資料；
  • 不驗證通訊方身份
    • 不驗證通訊方的身份，將導致通訊過程被竊聽後，可能會遭遇偽裝，例如使用抓包工具抓取資料後，就可按照資料包的格式構造HTTP請求；任何人都坑你傳送請求，不管對方是誰都返回相應。
  • 無法驗證報文的完整性
    • 不驗證報文的完整性，資料在傳輸過程中就可能被篡改，本來想看楊充呢，結果資料在傳輸過程中被換成了逗比。
    • 遭到篡改，即沒有辦法確認發出的請求/相應前後一致。
• Http的缺點解決方案
  • 通訊使用明文
    • 既然明文不安全，那可以考慮使用密文，即：對通訊資料進行加密。即便資料被竊聽，對方依然需要花費一定的投入來破解，這種高昂的成本間接提高安全級別。
  • 不驗證通訊方身份
    • 和服務端使用相同的演算法，根據網路請求引數生成一個token，請求/應答時根據token來確定雙方的身份。
  • 無法驗證報文的完整性
    • 使用MD5/SHA1等演算法進行完整性驗證，對方接收到資料後，根據同樣的演算法生成雜湊值，比對傳送方生成的雜湊值，即可驗證資料的完整性。
• 你知道Http存在哪些風險嗎？
  • 竊聽風險：Http採用明文傳輸資料，第三方可以獲知通訊內容
  • 篡改風險：第三方可以修改通訊內容
  • 冒充風險：第三方可以冒充他人身份進行通訊
• 如何解決這些風險
  • SSL/TLS協議就是為了解決這些風險而設計，希望達到：所有資訊加密傳輸，三方竊聽通訊內容；具有校驗機制，內容一旦被篡改，通訊雙發立刻會發現；配備身份證書，防止身份被冒充
• SSL原理及執行過程
  • SSL/TLS協議基本思路是採用公鑰加密法（最有名的是RSA加密演算法）。大概流程是，客戶端向伺服器索要公鑰，然後用公鑰加密資訊，伺服器收到密文，用自己的私鑰解密。
  • 為了防止公鑰被篡改，把公鑰放在數字證書中，證書可信則公鑰可信。公鑰加密計算量很大，為了提高效率，服務端和客戶端都生成對話祕鑰，用它加密資訊，而對話祕鑰是對稱加密，速度非常快。而公鑰用來機密對話祕鑰。

02.解決方案分析

• Https加密方式
  • 
• Https=Http+Ssl
  • Https保證了我們資料傳輸的安全，Https=Http+Ssl
  • 之所以能保證安全主要的原理就是利用了非對稱加密演算法，平常用的對稱加密演算法之所以不安全，是因為雙方是用統一的密匙進行加密解密的，只要雙方任意一方洩漏了密匙，那麼其他人就可以利用密匙解密資料。
  • 非對稱加密演算法之所以能實現安全傳輸的核心精華就是：公鑰加密的資訊只能用私鑰解開，私鑰加密的資訊只能被公鑰解開。
• 非對稱加密演算法為什麼安全
  • 服務端申請CA機構頒發的證書，則獲取到了證書的公鑰和私鑰，私鑰只有伺服器端自己知道，而公鑰可以告知其他人，如可以把公鑰傳給客戶端，這樣客戶端通過服務端傳來的公鑰來加密自己傳輸的資料，而服務端利用私鑰就可以解密這個資料了。由於客戶端這個用公鑰加密的資料只有私鑰能解密，而這個私鑰只有服務端有，所以資料傳輸就安全了。
  • 上面只是簡單說了一下非對稱加密演算法是如何保證資料安全的，實際上Https的工作過程遠比這要複雜。

03.SSL是什麼

• 什麼是SSL證書
  • Https協議中需要使用到SSL證書。SSL證書是一個二進位制檔案，裡面包含經過認證的網站公鑰和一些後設資料，需要從經銷商購買。
  • 證書有很多型別，按認證級別分類：
    • 域名認證（DV=Domain Validation）：最低階別的認證，可以確認申請人擁有這個域名
    • 公司認證（OV=Organization Validation）：確認域名所有人是哪家公司，證書裡面包含公司的資訊
    • 擴充套件認證（EV=Extended Validation）：最高階別認證，瀏覽器位址列會顯示公司名稱。
  • 按覆蓋範圍分類：
    • 單域名證書：只能用於單域名，foo.com證書不能用不www.foo.com
    • 萬用字元證書：可用於某個域名及所有一級子域名，比如*.foo.com的證書可用於foo.com，也可用於www.foo.com
    • 多域名證書：可用於多個域名，比如foo.com和bar.com
• TLS/SSL的原理是什麼？
  • SSL(Secure Sokcet Layer，安全套接字層)
  • TLS(Transport Layer Security,傳輸層安全協議)
  • 

04.RSA驗證的隱患

• SSL/TLS協議基本思路是採用公鑰加密法（最有名的是RSA加密演算法）,雖然說是採用非對稱加密，但還是有風險隱患。
• 身份驗證和金鑰協商是TLS的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但RSA演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊，存在安全隱患:
  • 客戶端C和伺服器S進行通訊，中間節點M截獲了二者的通訊;
  • 節點M自己計算產生一對公鑰pub_M和私鑰pri_M;
  • C向S請求公鑰時，M把自己的公鑰pub_M發給了C;
  • C使用公鑰 pub_M加密的資料能夠被M解密，因為M掌握對應的私鑰pri_M，而 C無法根據公鑰資訊判斷伺服器的身份，從而 C和 * M之間建立了"可信"加密連線;
  • 中間節點 M和伺服器S之間再建立合法的連線，因此 C和 S之間通訊被M完全掌握，M可以進行資訊的竊聽、篡改等操作。
  • 另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。
• 因此該方案下至少存在兩類問題：
  • 中間人攻擊和資訊抵賴
  • 

05.CA證書身份驗證

• CA 的初始是為了解決上面非對稱加密被劫持的情況，伺服器申請CA證書時將伺服器的“公鑰”提供給CA，CA使用自己的“私鑰”將“伺服器的公鑰”加密後（即：CA證書）返回給伺服器，伺服器再將“CA證書”提供給客戶端。一般系統或者瀏覽器會內建 CA 的根證書（公鑰），HTTPS 中 CA 證書的獲取流程如下所示：
  • 
  • 注意：上圖步驟 2 之後，客戶端獲取到“CA 證書”會進行本地驗證，即使用本地系統或者瀏覽器中的公鑰進行解密，每個“CA 證書”都會有一個證書編號可用於解密後進行比對（具體驗證演算法請查閱相關資料）。步驟 5 之前使用的是對稱加密，之後將使用對稱加密來提高通訊效率。
• CA證書流程原理
  • 基本的原理為，CA負責稽核資訊，然後對關鍵資訊利用私鑰進行"簽名"，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。
  • CA也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 檔案和 OCSP。CA使用具體的流程如下：
  • 
• 在這個過程注意幾點：
  • a.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握;
  • b.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名;
  • c.內建 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書（為什麼說"部署自籤SSL證書非常不安全"）
  • d.證書=公鑰+申請者與頒發者資訊+簽名;
• CA證書鏈
  • 如 CA根證書和伺服器證書中間增加一級證書機構，即中間證書，證書的產生和驗證原理不變，只是增加一層驗證，只要最後能夠被任何信任的CA根證書驗證合法即可。
  • a.伺服器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書;
  • b.中間證書 inter.pem 的簽發 CA 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書;
  • c.客戶端內建信任 CA 的 root.pem 證書，因此伺服器證書 server.pem 的被信任。
  • 

06.Https工作原理

• HTTPS工作原理
  • 一、首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；
  • 二、客戶端如果校驗通過後，就根據證書的公鑰的有效， 生成隨機數，隨機數使用公鑰進行加密（RSA加密）；
  • 三、訊息體產生的後，對它的摘要進行MD5（或者SHA1）演算法加密，此時就得到了RSA簽名；
  • 四、傳送給服務端，此時只有服務端（RSA私鑰）能解密。
  • 五、解密得到的隨機數，再用AES加密，作為金鑰（此時的金鑰只有客戶端和服務端知道）。
  • 
• 詳細一點的原理流程
  • 客戶端發起HTTPS請求
    • 這個沒什麼好說的，就是使用者在瀏覽器裡輸入一個https網址，然後連線到server的443埠。
  • 服務端的配置
    • 採用HTTPS協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
  • 傳送證書
    • 這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等等。
  • 客戶端解析證書
    • 這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。
  • 傳送加密資訊
    • 這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。
  • 服務端解密資訊
    • 服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。
  • 傳輸加密後的資訊
    • 這部分資訊是服務端用私鑰加密後的資訊，可以在客戶端被還原。
  • 客戶端解密資訊
    • 客戶端用之前生成的私鑰解密服務端傳過來的資訊，於是獲取瞭解密後的內容。整個過程第三方即使監聽到了資料，也束手無策。

07.Https代理作用

• HTTPS代理的作用是什麼？
  • 代理作用：提高訪問速度、Proxy可以起到防火牆的作用、通過代理伺服器訪問一些不能直接訪問的網站、安全性得到提高
  • 

08.Https真安全嗎

• charles抓包原理圖
  • 
• 大概步驟流程
  • 第一步，客戶端向伺服器發起HTTPS請求，charles截獲客戶端傳送給伺服器的HTTPS請求，charles偽裝成客戶端向伺服器傳送請求進行握手 。
  • 第二步，伺服器發回相應，charles獲取到伺服器的CA證書，用根證書（這裡的根證書是CA認證中心給自己頒發的證書）公鑰進行解密，驗證伺服器資料簽名，獲取到伺服器CA證書公鑰。然後charles偽造自己的CA證書（這裡的CA證書，也是根證書，只不過是charles偽造的根證書），冒充伺服器證書傳遞給客戶端瀏覽器。
  • 第三步，與普通過程中客戶端的操作相同，客戶端根據返回的資料進行證書校驗、生成密碼Pre_master、用charles偽造的證書公鑰加密，並生成HTTPS通訊用的對稱金鑰enc_key。
  • 第四步，客戶端將重要資訊傳遞給伺服器，又被charles截獲。charles將截獲的密文用自己偽造證書的私鑰解開，獲得並計算得到HTTPS通訊用的對稱金鑰enc_key。charles將對稱金鑰用伺服器證書公鑰加密傳遞給伺服器。
  • 第五步，與普通過程中伺服器端的操作相同，伺服器用私鑰解開後建立信任，然後再傳送加密的握手訊息給客戶端。
  • 第六步，charles截獲伺服器傳送的密文，用對稱金鑰解開，再用自己偽造證書的私鑰加密傳給客戶端。
  • 第七步，客戶端拿到加密資訊後，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與伺服器端就這樣建立了”信任“。
  • 在之後的正常加密通訊過程中，charles如何在伺服器與客戶端之間充當第三者呢？
  • 伺服器—>客戶端：charles接收到伺服器傳送的密文，用對稱金鑰解開，獲得伺服器傳送的明文。再次加密， 傳送給客戶端。
  • 客戶端—>服務端：客戶端用對稱金鑰加密，被charles截獲後，解密獲得明文。再次加密，傳送給伺服器端。由於charles一直擁有通訊用對稱金鑰enc_key，所以在整個HTTPS通訊過程中資訊對其透明。
• 總結一下
  • HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了伺服器證書公鑰和HTTPS連線的對稱金鑰，前提是客戶端選擇信任並安裝Charles的CA證書，否則客戶端就會“報警”並中止連線。這樣看來，HTTPS還是很安全的。
• 相對安全
  • 從抓包的原理可以看出，對Https進行抓包，需要PC端和手機端同時安裝證書。
  • 既然這麼容易被抓包，那Https會不會顯得很雞肋？其實並不會，能抓包，那是因為你信任抓包工具，手機上安裝了與之對應的證書，你要不安裝證書，你抓一個試試。而且安全這個課題，是在攻防中求發展，沒有最安全，只有更安全，所以將攻擊的成本提高了，就間接達到了安全的目標。

09.Https效能優化

• HTTPS效能損耗
  • 增加延時
    • 分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通訊，至少增加延時2* RTT，利用會話快取從而複用連線，延時也至少1* RTT*
  • 消耗較多的CPU資源
    • 除資料傳輸之外，HTTPS通訊主要包括對對稱加解密、非對稱加解密(伺服器主要採用私鑰解密資料);壓測 TS8 機型的單核 CPU：對稱加密演算法AES-CBC-256 吞吐量 600Mbps，非對稱 RSA 私鑰解密200次/s。不考慮其它軟體層面的開銷，10G 網路卡為對稱加密需要消耗 CPU 約17核，24核CPU最多接入 HTTPS 連線 4800;靜態節點當前10G 網路卡的 TS8 機型的 HTTP 單機接入能力約為10w/s，如果將所有的HTTP連線變為HTTPS連線，則明顯RSA的解密最先成為瓶頸。因此，RSA的解密能力是當前困擾HTTPS接入的主要難題。
• HTTPS接入優化
  • CDN接入
    • HTTPS 增加的延時主要是傳輸延時 RTT，RTT 的特點是節點越近延時越小，CDN 天然離使用者最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時。
    • CDN 節點通過和業務伺服器維持長連線、會話複用和鏈路質量優化等可控方法，極大減少 HTTPS 帶來的延時。
  • 會話快取
    • 雖然前文提到 HTTPS 即使採用會話快取也要至少1*RTT的延時，但是至少延時已經減少為原來的一半，明顯的延時優化;同時，基於會話快取建立的 HTTPS 連線不需要伺服器使用RSA私鑰解密獲取 Pre-master 資訊，可以省去CPU 的消耗。如果業務訪問連線集中，快取命中率高，則HTTPS的接入能力講明顯提升。當前TRP平臺的快取命中率高峰時期大於30%，10k/s的接入資源實際可以承載13k/的接入，收效非常可觀。
  • 硬體加速
    • 為接入伺服器安裝專用的SSL硬體加速卡，作用類似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力且不影響業務程式的。測試某硬體加速卡單卡可以提供35k的解密能力，相當於175核 CPU，至少相當於7臺24核的伺服器，考慮到接入伺服器其它程式的開銷，一張硬體卡可以實現接近10臺伺服器的接入能力。
  • 遠端解密
    • 本地接入消耗過多的 CPU 資源，浪費了網路卡和硬碟等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它伺服器，如此則可以充分發揮伺服器的接入能力，充分利用頻寬與網路卡資源。遠端解密伺服器可以選擇 CPU 負載較低的機器充當，實現機器資源複用，也可以是專門優化的高計算效能的伺服器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。
  • SPDY/HTTP2
    • 前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入效能，但是方法都基於不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優勢，通過修改協議的方法來提升 HTTPS 的效能，提高下載速度等。

技術部落格彙總：https://github.com/yangchong211/YCBlogs