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工做原理

  • 1、首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；
  • 2、客戶端若是校驗經過後，就根據證書的公鑰的有效， 生成隨機數，隨機數使用公鑰進行加密（RSA加密）；
  • 3、消息體產生的後，對它的摘要進行MD5（或者SHA1）算法加密，此時就獲得了RSA簽名；
  • 4、發送給服務端，此時只有服務端（RSA私鑰）能解密。
  • 5、解密獲得的隨機數，再用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/yangchong2...