HTTPS原理全面介绍【备查】
來源：https://www.cnblogs.com/haimishasha/p/11373034.html
目錄
應用層協議：HTTPS
1. HTTPS定義
2.?密碼學基礎
3.?HTTP通信問題
4. SSL/TLS協議
5.?HTTP 向 HTTPS 演化的過程
5.1?對稱加密
5.2?非對稱加密
5.3?對稱加密+非對稱加密
5.4?安全的獲取公鑰?CA
6. HTTPS通信過程
1. 客戶端發起HTTPS請求
2. 服務端的配置
3. 傳送證書
4. 客戶端解析證書
5. 傳送加密信息
6. 服務端解密信息
7. 傳輸加密后的信息
8. 客戶端解密信息
7. HTTPS單向認證
8.?中間人攻擊原理
9. HTTPS雙向認證
10. https服務部署過程和原理
10.1 證書的獲取
10.2 客戶端識別證書
10.3 https的加密通信過程
10.4 綜合解惑
11.?注意
?參考網址
應用層協議：HTTPS
1. HTTPS定義
Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本傳輸協議，網景公式設計了SSL(Secure Sockets Layer)協議用于對Http協議傳輸的數據進行加密，保證會話過程中的安全性。
縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure
兩大作用：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。
?
2.?密碼學基礎
明文： 明文指的是未被加密過的原始數據。 密文：明文被某種加密算法加密之后，會變成密文，從而確保原始數據的安全。密文也可以被解密，得到原始的明文。 密鑰：密鑰是一種參數，它是在明文轉換為密文或將密文轉換為明文的算法中輸入的參數。密鑰分為對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。對稱加密 對稱加密又叫做私鑰加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。 其加密過程如下：明文 + 加密算法 + 私鑰 => 密文 解密過程如下：密文 + 解密算法 + 私鑰 => 明文 對稱加密中用到的密鑰叫做私鑰，私鑰表示個人私有的密鑰，即該密鑰不能被泄露。 其加密過程中的私鑰與解密過程中用到的私鑰是同一個密鑰，這也是稱加密之所以稱之為“對稱”的原因。由于對稱加密的算法是公開的，所以一旦私鑰被泄露，那么密文就很容易被破解，所以對稱加密的缺點是密鑰安全管理困難。 對稱加密的特點是算法公開、加密和解密速度快，適合于對大數據量進行加密 常見的對稱加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。 非對稱加密 非對稱加密也叫做公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通信雙方使用相同的密鑰，如果一方的密鑰遭泄露，那么整個通信就會被破解。而非對稱加密使用一對密鑰，即公鑰和私鑰，且二者成對出現。私鑰被自己保存，不能對外泄露。公鑰指的是公共的密鑰，任何人都可以獲得該密鑰。用公鑰或私鑰中的任何一個進行加密，用另一個進行解密。 被公鑰加密過的密文只能被私鑰解密，過程如下：明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文 被私鑰加密過的密文只能被公鑰解密，過程如下：明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文 由于加密和解密使用了兩個不同的密鑰，這就是非對稱加密“非對稱”的原因。 非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少量數據進行加密。 在非對稱加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（橢圓曲線加密算法）等。 哈希算法 將任意長度的信息轉換為較短的固定長度的值，通常其長度要比信息小得多，且算法不可逆。 例如：MD5、SHA-1、SHA-2、SHA-256 等指紋算法/摘要算法【hash值計算】
對消息使用hash算法/摘要算法進行單向處理，獲取一個固定長度的信息的摘要/hash值。
數字證書
是互聯網通信中的身份標識(主要是用戶身份信息和公鑰)，一般由CA中心頒發，既CA認證中心，或第三方權威機構?！ ?/p>
數字證書上通常包括：CA的簽名，證書所有人的公鑰，CA中心的簽名算法，指紋以及指紋算法，證書的唯一編號，版本，有效期等?！?/p>
數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。數字證書還有一個重要的特征就是只在特定的時間段內有效。
數字證書是一種權威性的電子文檔，可以由權威公正的第三方機構，即CA（例如中國各地方的CA公司）中心簽發的證書，也可以由企業級CA系統進行簽發。
?
3.?HTTP通信問題
HTTP協議基于TCP進行傳輸的，其中傳輸的內容全都裸露在報文中，如果我們獲取了一個HTTP消息體，那我們可以知道消息體中所有的內容。這其實存在很大的風險，如果HTTP消息體被劫持，那么整個傳輸過程將面臨：
（1） 竊聽風險（eavesdropping）：通信使用明文(不加密)，內容可能被竊聽。
（2） 篡改風險（tampering）：無法證明報文的完整性，所以可能遭篡改。
（3） 冒充風險（pretending）：不驗證通信方的身份，因此有可能遭遇偽裝。
正因為HTTP協議的這個缺點, HTTP變成了一種不安全的協議。
?
https://zhuanlan.zhihu.com/p/27395037
4. SSL/TLS協議
SSL：（Secure Socket Layer，安全套接字層），位于可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
TLS：(Transport Layer Security，傳輸層安全協議)，用于兩個應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。
位置：介于傳輸層與應用層之間
?
SSL/TLS協議是為了解決HTTP這三大風險而設計的，希望達到：
（1） 所有信息都是加密傳播，第三方無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。
http://www.sohu.com/a/294450321_100134138
?
5.?HTTP 向 HTTPS 演化的過程
最直觀上的差異，HTTP協議用明文傳輸報文，HTTPS用密文。
?
?
5.1?對稱加密
第一步：為了防止上述現象的發生，人們想到一個辦法：對傳輸的信息加密（即使黑客截獲，也無法破解）
如上圖所示，此種方式屬于對稱加密，雙方擁有相同的密鑰，信息得到安全傳輸，
在經過TCP的三次握手之后，客戶端和服務器開啟了連接，如果對后續雙方傳輸的內容進行對稱加密，那么理論上我們在本次傳輸中防止了內容裸露。 但是由于對稱加密使用秘鑰在兩端是一樣的，要維持每個客戶端的秘鑰不一致整套加密才有意義，這樣將會產生海量的秘鑰，維護困難。 另外，因為對稱加密需要雙方協商一致，一般可用提前約定，或者使用前傳輸秘鑰，不管是哪種方式，都很容易導致秘鑰邪泄漏。只要黑客獲取到秘鑰，那么所謂的加密傳輸就如同虛設了。此種方式的缺點是：
（1）不同的客戶端、服務器數量龐大，所以雙方都需要維護大量的密鑰，維護成本很高
（2）因每個客戶端、服務器的安全級別不同，密鑰極易泄露
?
5.2?非對稱加密
第二步：既然使用對稱加密時，密鑰維護這么繁瑣，那我們就用非對稱加密試試
如上圖所示，客戶端用公鑰對請求內容加密，服務器使用私鑰對內容解密，反之亦然·
用戶使用公鑰進行加密之后，消息體能夠安全的抵達服務器，但是在服務器返回數據的時候，黑客截取到信息之后,能夠通過公鑰對響應的內容進行解密，最后進行篡改，導致這個加密方案失敗。 另外，非對稱加密不適用與數量太大的報文，大數量的報文導致加密效率降低。（1）公鑰是開放給所有人的，但私鑰是需要保密的，存在于服務端 （2）服務器端server向client端（A、B.....）的信息傳輸是不安全的：因為所有人都可以獲取公鑰 （3）但client端（A、B.....）向server端的信息傳輸確實安全的：因為私鑰只有server端存在缺點：
（1）公鑰是公開的（也就是黑客也會有公鑰），所以第 ④ 步私鑰加密的信息，如果被黑客截獲，其可以使用公鑰進行解密，獲取其中的內容
（2）非對稱加密不適用與數量太大的報文，大數量的報文導致加密效率降低。
?
5.3?對稱加密+非對稱加密
第三步：非對稱加密既然也有缺陷，那我們就將對稱加密，非對稱加密兩者結合起來，取其精華、去其糟粕，發揮兩者的各自的優勢
如上圖所示
（1）第 ③ 步時，客戶端說：（咱們后續回話采用對稱加密吧，這是對稱加密的算法和對稱密鑰）這段話用公鑰進行加密，然后傳給服務器
（2）服務器收到信息后，用私鑰解密，提取出對稱加密算法和對稱密鑰后，服務器說：（好的）對稱密鑰加密
（3）后續兩者之間信息的傳輸就可以使用對稱加密的方式了
遇到的問題：
（1）客戶端如何獲得公鑰
（2）如何確認服務器是真實的而不是黑客，客戶端在獲取一個公鑰之后，如何確定這個公鑰是正確的服務端發出的？
5.4?安全的獲取公鑰?CA
第四步：獲取公鑰與確認服務器身份
如何安全的獲取公鑰，并確保公鑰的獲取是安全的， 那就需要用到終極武器了：SSL 證書（需要購買）和CA機構
怎么保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？
https://blog.csdn.net/xiaoming100001/article/details/81109617
https://blog.51cto.com/11883699/2160032
1、獲取公鑰
（1）提供一個下載公鑰的地址，回話前讓客戶端去下載。（缺點：下載地址有可能是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）
（2）回話開始時，服務器把公鑰發給客戶端（缺點：黑客冒充服務器，發送給客戶端假的公鑰）
2、那有木有一種方式既可以安全的獲取公鑰，又能防止黑客冒充呢？ 那就需要用到終極武器了：SSL 證書（需要購買申購）和CA機構
如上圖所示，在第 ② 步時服務器發送了一個SSL證書給客戶端，SSL 證書中包含的具體內容有：
（1）證書的發布機構CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名
6. HTTPS通信過程
? HTTPS其實是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密后的數據。
一個HTTPS請求實際上包含了兩次HTTP傳輸，可以細分為8步。
1. 客戶端發起HTTPS請求
客戶端向服務器發起HTTPS請求，連接到服務器的443端口,，請求攜帶了瀏覽器支持的加密算法和哈希算法。
2. 服務端的配置
服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存著私鑰，不能將其泄露，公鑰可以發送給任何人。
服務器收到請求，選擇瀏覽器支持的加密算法和哈希算法。
采用HTTPS協議的服務器必須要有一套數字證書，可以自己制作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。公鑰給別人加密使用，私鑰給自己解密使用。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。
3. 傳送證書
服務器將自己的CA?證書(公鑰)發送給客戶端。
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。
4. 客戶端解析證書
客戶端收到服務器端的公鑰之后，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那么HTTPS傳輸就無法繼續。如果公鑰合格，那么客戶端會生成一個隨機值，這個隨機值就是用于進行對稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，這樣在概念上和服務器端的密鑰容易進行區分。然后用服務器的公鑰對客戶端密鑰進行非對稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請求結束。
這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值。然后用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。
證書真偽進行校驗
（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操作系統中已內置的受信任的證書發布機構CA，與服務器發來的證書中的頒發者CA比對，用于校驗證書是否為合法機構頒發
（3）如果找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。
（4）如果找到，那么瀏覽器就會從操作系統中取出 頒發者CA 的公鑰，然后對服務器發來的證書里面的簽名進行解密得到服務端的公鑰和證書的數字簽名，數字簽名經過CA公鑰解密得到證書信息摘要。
（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中簽名做對比
（6）對比結果一致，則證明服務器發來的證書合法，沒有被冒充
（7）此時瀏覽器就可以讀取證書中的公鑰，用于后續加密了
5. 傳送加密信息
客戶端會發起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發送給服務器。
這部分傳送的是用證書加密后的隨機值R(私鑰)，目的就是讓服務端得到這個隨機值R，以后客戶端和服務端的通信就可以通過這個隨機值R來進行加密解密了。
6. 服務端解密信息
服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰(隨機數?R)，然后把內容用客戶端密鑰隨機數?R進行對稱加密，這樣數據就變成了密文。
服務端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復雜，數據就夠安全。
7. 傳輸加密后的信息
然后服務器將加密后的密文發送給客戶端。(服務器以隨機數?R?為密鑰把傳輸內容使用對稱加密算法加密并傳輸給瀏覽器)。
這部分信息是服務端用私鑰加密后的信息，可以在客戶端被還原
8. 客戶端解密信息
客戶端收到服務器發送來的密文，用客戶端密鑰(隨機數?R)對其進行對稱解密，得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成。
客戶端用之前生成的私鑰解密服務段傳過來的信息，于是獲取了解密后的內容。整個過程第三方即使監聽到了數據，也束手無策。
7. HTTPS單向認證
Https在建立Socket連接之前，需要進行握手，具體過程如下：
?
?
- 證書是否過期
- 發型服務器證書的CA是否可靠
- 返回的公鑰是否能正確解開返回證書中的數字簽名
- 服務器證書上的域名是否和服務器的實際域名相匹配
- 驗證通過后，將繼續進行通信，否則，終止通信
8.?中間人攻擊原理
中間人攻擊，即所謂的Man-in-the-middle attack(MITM)，顧名思義，就是攻擊者插入到原本直接通信的雙方，讓雙方以為還在直接跟對方通訊，但實際上雙方的通信對方已變成了中間人，信息已經是被中間人獲取或篡改。
?
解決辦法
HTTPS?雙向驗證在客戶端中內置服務器公鑰，在服務器下將?CA?證書給瀏覽器的時候返回的公鑰，服務端要求客戶端發送客戶端的證書，客戶端會將自己的證書發送至服務端。
除了驗證公鑰的有效性之外，再比對公鑰是不是和內置的公鑰一樣，不一樣說明被中間者攻擊了，就斷開鏈接不在請求了。
9. HTTPS雙向認證
雙向認證和單向認證原理基本差不多，只是除了客戶端需要認證服務端以外，增加了服務端對客戶端的認證，具體過程如下：
??
?
- 證書是否過期
- 發型服務器證書的CA是否可靠
- 返回的公鑰是否能正確解開返回證書中的數字簽名
- 服務器證書上的域名是否和服務器的實際域名相匹配
- 驗證通過后，將繼續進行通信，否則，終止通信
10. https服務部署過程和原理
了解https的原理，最好的方法就是走一遍流程，理論上的流程和原理通過以下幾點來解釋：
10.1 證書的獲取
https的關鍵之一就是ssl證書，為了保證證書的安全有效性，在各類委員會/廠商之間合作，通過類似圓桌會議來形成若干權威的認證機構【頂級認證機構可以有若干附屬的二級、三級...認證機構】，想要得到受信任的證書，就需要向CA機構提交證書簽名請求 (CSR, Certificate Signing Request)。過程如下：
對新的證書進行簽名，步驟如下：
- 對新證書按照指紋/hash算法進行hash值計算
- 使用CA機構的私鑰對計算出來的hash值按照簽名算法進行加密，得出的密文就是數字簽名；
- 將數字簽名放在證書的最后面【簽名完成】，得到完整的證書，并返回給申請者；
- 申請者獲取簽名證書，保證自己的HTTPS服務被信任。
?
所以最后的證書基本包括但不限于的內容如下：
- 證書的有效期
- 公鑰
- 證書所有者（Subject）
- 簽名所使用的算法
- 指紋以及指紋算法【hash算法】
- Version Number，版本號。
- Serial Number，序列號。
- 頒發機構
- 數字簽名
10.2 客戶端識別證書
在申請到受信任的證書后，客戶端是怎么知道這些證書是值得信任的呢，不同瀏覽器和系統的具體實現不太一樣，但是基本的方式差不多，都是在系統或者瀏覽器中事先準備好權威的CA機構的相關信息[公鑰、常使用的各類hash、簽名、加密算法等]。具體過程如下：
?
?
?
10.3 https的加密通信過程
在上文的流程之后【證書信任，客戶端和服務端握手中需要的非對稱算法、握手信息驗證的hash算法、正文傳輸的對稱加密】，就是具體的通信過程：
?
10.4 綜合解惑
這里的整個過程分的很細，不過還是很清晰的把整個https的原理和過程闡述了;下面解釋一下其中一些疑惑點：
可以作為全球有限的權威認證，經過其簽名的證書都可以視為可信任的，所以他們的私鑰必須要保證不被泄露，如果泄露的話需要及時的進行吊銷，
因為雖然hash值是單向的，但是計算hash的算法和內容都是公開的，如果不進行加密，那么由于其他人可以修改證書內容，根據hash算法重新計算hash，這樣就會出現安全漏洞，所以使用加密的密文才是安全的。
隨機數是作為后續整個密文加解密的關鍵秘鑰，只有獲取這個隨機數的人才可以看到通信的內容，保證通信的安全；通過客戶端產生是因為會話的發起者是用戶端，為了保證用戶端的唯一，以及保證服務端和客服端的會話內容不被篡改，如果是服務端來生成的話，第三方可以通過公鑰來解密服務端加密的隨機數，存在不安全因素。
證書驗證完成以后，需要傳遞一個隨機數，使用公鑰、私鑰進行非對稱加解密，后面在發生內容消息的前面是為了驗證通過隨機數進行對稱加解密，保證雙方獲取的數據正確性。
11.?注意
SSL證書需要購買申請，功能越強大的證書費用越高
SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展可以部分解決這個問題，但是比較麻煩，而且要求瀏覽器、操作系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增加10%到20%的耗電。
HTTPS連接緩存不如HTTP高效，流量成本高。
HTTPS連接服務器端資源占用高很多，支持訪客多的網站需要投入更大的成本。
HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是采用分而治之，類似12306網站的主頁使用HTTP協議，有關于用戶信息等方面使用HTTPS。
?
?
?參考網址
總結
以上是生活随笔為你收集整理的HTTPS原理全面介绍【备查】的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 阿尔·帕西诺谈《盗火线2》
- 下一篇： [转载]使用消息队列实现分布式事务-公认