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 的性能，提高下載速度等。

另外如果你想更好的提升你的編程能力，學好C語言C++編程！彎道超車，快人一步！