應用層協議：HTTPS

時間 2019-11-06

標籤應用層協議 https 简体版

原文原文鏈接

1. HTTPS定義

　　Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本傳輸協議，網景公式設計了SSL(Secure Sockets Layer)協議用於對Http協議傳輸的數據進行加密，保證會話過程當中的安全性。html

　　縮寫：HTTPS，常稱爲HTTP over TLS，HTTP over SSL或HTTP Secure算法

　　兩大做用：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。segmentfault

2. 密碼學基礎　

明文： 明文指的是未被加密過的原始數據。
密文：明文被某種加密算法加密以後，會變成密文，從而確保原始數據的安全。密文也能夠被解密，獲得原始的明文。
密鑰：密鑰是一種參數，它是在明文轉換爲密文或將密文轉換爲明文的算法中輸入的參數。密鑰分爲對稱密鑰與非對稱密鑰，分別應用在對稱加密和非對稱加密上。

對稱加密
對稱加密又叫作私鑰加密，即信息的發送方和接收方使用同一個密鑰去加密和解密數據。
其加密過程以下：明文 + 加密算法 + 私鑰 => 密文 解密過程以下：密文 + 解密算法 + 私鑰 => 明文 對稱加密中用到的密鑰叫作私鑰，私鑰表示我的私有的密鑰，即該密鑰不能被泄露。 其加密過程當中的私鑰與解密過程當中用到的私鑰是同一個密鑰，這也是稱加密之因此稱之爲「對稱」的緣由。因爲對稱加密的算法是公開的，因此一旦私鑰被泄露，那麼密文就很容易被破解，因此對稱加密的缺點是密鑰安全管理困難。 對稱加密的特色是算法公開、加密和解密速度快，適合於對大數據量進行加密
常見的對稱加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。

非對稱加密
非對稱加密也叫作公鑰加密。非對稱加密與對稱加密相比，其安全性更好。對稱加密的通訊雙方使用相同的密鑰，若是一方的密鑰遭泄露，那麼整個通訊就會被破解。而非對稱加密使用一對密鑰，即公鑰和私鑰，且兩者成對出現。私鑰被本身保存，不能對外泄露。公鑰指的是公共的密鑰，任何人均可以得到該密鑰。用公鑰或私鑰中的任何一個進行加密，用另外一個進行解密。
被公鑰加密過的密文只能被私鑰解密，過程以下：明文 + 加密算法 + 公鑰 => 密文， 密文 + 解密算法 + 私鑰 => 明文
被私鑰加密過的密文只能被公鑰解密，過程以下：明文 + 加密算法 + 私鑰 => 密文， 密文 + 解密算法 + 公鑰 => 明文
因爲加密和解密使用了兩個不一樣的密鑰，這就是非對稱加密「非對稱」的緣由。
非對稱加密的缺點是加密和解密花費時間長、速度慢，只適合對少許數據進行加密。
在非對稱加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（橢圓曲線加密算法）等。

哈希算法
將任意長度的信息轉換爲較短的固定長度的值，一般其長度要比信息小得多，且算法不可逆。
例如：MD五、SHA-一、SHA-二、SHA-256 等

　指紋算法/摘要算法【hash值計算】
　對消息使用hash算法/摘要算法進行單向處理，獲取一個固定長度的信息的摘要/hash值。瀏覽器

數字簽名
對信息的摘要【經過//計算的信息/】使用簽名算法進行加密，獲得的密文就叫作數字簽名
簽名就是在信息的後面再加上一段內容（信息通過hash後的值），能夠證實信息沒有被修改過。hash值通常都會加密後（也就是簽名）再和信息一塊兒發送，以保證這個hash值不被修改。hash算法摘要算法指紋算法摘要hash值

　數字證書
　是互聯網通訊中的身份標識(主要是用戶身份信息和公鑰)，通常由CA中心頒發，既CA認證中心，或第三方權威機構。　　　　

　數字證書上一般包括：CA的簽名，證書全部人的公鑰，CA中心的簽名算法，指紋以及指紋算法，證書的惟一編號，版本，有效期等。　

　數字證書是一個經證書受權中心 數字簽名的包含 公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書受權中心的數字簽名。數字證書還有一個重要的特徵就是隻在特定的時間段內有效。

　數字證書是一種權威性的電子文檔，能夠由權威公正的第三方機構，即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機構

　　怎麼保證服務器給客戶端下發的公鑰是真正的公鑰，而不是中間人僞造的公鑰呢？

　　http://www.javashuo.com/article/p-wybdsvhv-kt.html

　　https://blog.51cto.com/11883699/2160032

　　一、獲取公鑰

　　（1）提供一個下載公鑰的地址，回話前讓客戶端去下載。（缺點：下載地址有多是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）
　　（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鏈接以前，須要進行握手，具體過程以下：

客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書，即公鑰證書
客戶端使用服務端返回的信息驗證服務器的合法性，包括：
- 證書是否過時
- 髮型服務器證書的CA是否可靠
- 返回的公鑰是否能正確解開返回證書中的數字簽名
- 服務器證書上的域名是否和服務器的實際域名相匹配
- 驗證經過後，將繼續進行通訊，不然，終止通訊
客戶端向服務端發送本身所能支持的對稱加密方案，供服務器端進行選擇
服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式。
服務器將選擇好的加密方案經過明文方式返回給客戶端
客戶端接收到服務端返回的加密方式後，使用該加密方式生成產生隨機碼，用做通訊過程當中對稱加密的密鑰，使用服務端返回的公鑰進行加密，將加密後的隨機碼發送至服務器
服務器收到客戶端返回的加密信息後，使用本身的私鑰進行解密，獲取對稱加密密鑰。
在接下來的會話中，服務器和客戶端將會使用該密碼進行對稱加密，保證通訊過程當中信息的安全。

8. 中間人攻擊原理

　　中間人攻擊，即所謂的Man-in-the-middle attack(MITM)，顧名思義，就是攻擊者插入到本來直接通訊的雙方，讓雙方覺得還在直接跟對方通信，但實際上雙方的通訊對方已變成了中間人，信息已是被中間人獲取或篡改。

解決辦法

HTTPS 雙向驗證在客戶端中內置服務器公鑰，在服務器下將 CA 證書給瀏覽器的時候返回的公鑰，服務端要求客戶端發送客戶端的證書，客戶端會將本身的證書發送至服務端。

除了驗證公鑰的有效性以外，再比對公鑰是否是和內置的公鑰同樣，不同說明被中間者攻擊了，就斷開連接不在請求了。

9. HTTPS雙向認證

雙向認證和單向認證原理基本差很少，只是除了客戶端須要認證服務端之外，增長了服務端對客戶端的認證，具體過程以下：

客戶端向服務端發送SSL協議版本號、加密算法種類、隨機數等信息。
服務端給客戶端返回SSL協議版本號、加密算法種類、隨機數等信息，同時也返回服務器端的證書，即公鑰證書
客戶端使用服務端返回的信息驗證服務器的合法性，包括：

證書是否過時
髮型服務器證書的CA是否可靠
返回的公鑰是否能正確解開返回證書中的數字簽名
服務器證書上的域名是否和服務器的實際域名相匹配
驗證經過後，將繼續進行通訊，不然，終止通訊

服務端要求客戶端發送客戶端的證書，客戶端會將本身的證書發送至服務端
驗證客戶端的證書，經過驗證後，會得到客戶端的公鑰
客戶端向服務端發送本身所能支持的對稱加密方案，供服務器端進行選擇
服務器端在客戶端提供的加密方案中選擇加密程度最高的加密方式
將加密方案經過使用以前獲取到的公鑰進行加密，返回給客戶端
客戶端收到服務端返回的加密方案密文後，使用本身的私鑰進行解密，獲取具體加密方式，然後，產生該加密方式的隨機碼，用做加密過程當中的密鑰，使用以前從服務端證書中獲取到的公鑰進行加密後，發送給服務端
服務端收到客戶端發送的消息後，使用本身的私鑰進行解密，獲取對稱加密的密鑰，在接下來的會話中，服務器和客戶端將會使用該密碼進行對稱加密，保證通訊過程當中信息的安全。

10. https服務部署過程和原理

瞭解https的原理，最好的方法就是走一遍流程，理論上的流程和原理經過如下幾點來解釋：

證書申請
證書信任
密文通訊

10.1 證書的獲取

https的關鍵之一就是ssl證書，爲了保證證書的安全有效性，在各種委員會/廠商之間合做，經過相似圓桌會議來造成若干權威的認證機構【頂級認證機構能夠有若干附屬的二級、三級...認證機構】，想要獲得受信任的證書，就須要向CA機構提交證書籤名請求 (CSR, Certificate Signing Request)。過程以下：

證書申請者【通常是公司、我的開發者等】須要使用加密算法【大部分是RSA算法】來生成私鑰，其中私鑰保存在服務器上，不提供給任何人。
使用私鑰生成證書籤名請求 (CSR, Certificate Signing Request)【CSR中附帶有公鑰】，須要提供一些申請者相關的信息【域名、擁有者等信息】，發送給CA機構請求他們的簽名，通過他們簽名才能成爲被信任的證書。
CA機構對申請者進行驗證【這裏不一樣類型收費不一樣，驗證方式也會不一樣】，驗證經過後，將會在證書中添加部分信息【證書頒發機構、有效期、指紋/hash算法、簽名算法】，造成新的證書。【CA機構也是使用其自身的私鑰來簽名其餘證書的】
對新的證書進行簽名，步驟以下：
- 對新證書按照指紋/hash算法進行hash值計算
- 使用CA機構的私鑰對計算出來的hash值按照簽名算法進行加密，得出的密文就是數字簽名；
- 將數字簽名放在證書的最後面【簽名完成】，獲得完整的證書，並返回給申請者；
- 申請者獲取簽名證書，保證本身的HTTPS服務被信任。

因此最後的證書基本包括但不限於的內容以下：

證書的有效期
公鑰
證書全部者（Subject）
簽名所使用的算法
指紋以及指紋算法【hash算法】
Version Number，版本號。
Serial Number，序列號。
頒發機構
數字簽名

10.2 客戶端識別證書

在申請到受信任的證書後，客戶端是怎麼知道這些證書是值得信任的呢，不一樣瀏覽器和系統的具體實現不太同樣，可是基本的方式差很少，都是在系統或者瀏覽器中事先準備好權威的CA機構的相關信息[公鑰、常使用的各種hash、簽名、加密算法等]。具體過程以下：

瀏覽器訪問某https服務，帶上瀏覽器自身支持的一系列Cipher Suite（密鑰算法套件，後文簡稱Cipher）[C1,C2,C3, …]發給服務器【算法套件包括非對稱算法、對稱算法、hash算法】；
服務器接收到瀏覽器的全部Cipher後，與本身支持的套件做對比，若是找到雙方都支持的Cipher【雙方套件中都能支持的最優先算法】，則告知瀏覽器，並返回本身的證書；
瀏覽器確認和服務端後續的密文通訊的加密算法，同時對證書進行認證；
使用證書中的認證機構【多是二級、三級機構】的公鑰【系統、瀏覽器事先準備好的】按照證書中的簽名算法進行解密【認證機構使用私鑰加密的密文只能經過該認證機構的公鑰進行解密】，解密獲取hash值；
使用證書中的hash/摘要算法對證書信息【證書籤名除外的信息[服務器公鑰、有效期等]】hash值計算，和4中解密的hash值進行對比，若是相等，表示證書值得信任；【經過數字簽名來保證證書內容沒有被篡改】。

10.3 https的加密通訊過程

在上文的流程以後【證書信任，客戶端和服務端握手中須要的非對稱算法、握手信息驗證的hash算法、正文傳輸的對稱加密】，就是具體的通訊過程：

客戶端信任了服務端的證書，並和服務端確認了雙方的加密算法【握手中須要的非對稱算法、握手信息驗證的hash算法、正文傳輸的對稱加密】；
客戶端生成隨機數，經過證書中的公鑰按照約定的非對稱加密算法進行加密，獲得加密的隨機數祕鑰，同時將以前全部的通訊信息【祕鑰算法套件、證書等全部的通訊內容】按照約定的hash/摘要算法獲取hash值，並使用隨機數和協商好的對稱加密算法進行簽名加密，將隨機數祕鑰和加密簽名發送到服務端。
服務端收到隨機數祕鑰和加密簽名，先使用私鑰將隨機數按照約定的非對稱解密算法進行解密，獲取隨機數，同時使用隨機數按照約定的對稱解密算法進行解密，獲取待驗證的hash值，將以前的通訊消息體【祕鑰算法套件、證書等全部的通訊內容】按照約定的hash/摘要算法獲取hash值，與剛纔解密獲取的待驗證的hash值對比，驗證加密成功與否。
成功之後，服務器再次將以前全部的通訊信息【祕鑰算法套件、證書等全部的通訊內容】按照約定的hash/摘要算法獲取hash值，並使用隨機數和協商好的對稱加密算法進行簽名加密，將隨機數祕鑰發送到客戶端，
客戶端使用隨機數按照約定的對稱解密算法進行解密，獲取待驗證的hash值，將以前的通訊消息體【祕鑰算法套件、證書等全部的通訊內容】按照約定的hash/摘要算法獲取hash值，與剛纔解密獲取的待驗證的hash值對比，驗證加密成功與否，
成功的話整個連接過程完成，以後將使用隨機數和約定的對稱加密算法進行密文通訊，【若是上面的任何步驟出現問題，都將會結束整個握手過程，致使創建安全鏈接失敗】。

10.4 綜合解惑

這裏的整個過程分的很細，不過仍是很清晰的把整個https的原理和過程闡述了;下面解釋一下其中一些疑惑點：

CA機構認證的做用？
能夠做爲全球有限的權威認證，通過其簽名的證書均可以視爲可信任的，因此他們的私鑰必需要保證不被泄露，若是泄露的話須要及時的進行吊銷，
簽名爲何須要加密計算的hash值，hash值已是單向不可逆的運算了？
由於雖然hash值是單向的，可是計算hash的算法和內容都是公開的，若是不進行加密，那麼因爲其餘人能夠修改證書內容，根據hash算法從新計算hash，這樣就會出現安全漏洞，因此使用加密的密文才是安全的。
爲何要有隨機數，爲何在客戶端生成？
隨機數是做爲後續整個密文加解密的關鍵祕鑰，只有獲取這個隨機數的人才能夠看到通訊的內容，保證通訊的安全；經過客戶端產生是由於會話的發起者是用戶端，爲了保證用戶端的惟一，以及保證服務端和客服端的會話內容不被篡改，若是是服務端來生成的話，第三方能夠經過公鑰來解密服務端加密的隨機數，存在不安全因素。
證書驗證完成後，爲何客戶端須要和服務端互相發送一次簽名信息？
證書驗證完成之後，須要傳遞一個隨機數，使用公鑰、私鑰進行非對稱加解密，後面在發生內容消息的前面是爲了驗證經過隨機數進行對稱加解密，保證雙方獲取的數據正確性。

11. 注意

HTTPS協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用
SSL證書的信用鏈體系並不安全，特別是在某些國家能夠控制CA根證書的狀況下，中間人攻擊同樣可行
SSL證書須要購買申請，功能越強大的證書費用越高
SSL證書一般須要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗（SSL有擴展能夠部分解決這個問題，可是比較麻煩，並且要求瀏覽器、操做系統支持，Windows XP就不支持這個擴展，考慮到XP的裝機量，這個特性幾乎沒用）。
根據ACM CoNEXT數據顯示，使用HTTPS協議會使頁面的加載時間延長近50%，增長10%到20%的耗電。
HTTPS鏈接緩存不如HTTP高效，流量成本高。
HTTPS鏈接服務器端資源佔用高不少，支持訪客多的網站須要投入更大的成本。
HTTPS協議握手階段比較費時，對網站的響應速度有影響，影響用戶體驗。比較好的方式是採用分而治之，相似12306網站的主頁使用HTTP協議，有關於用戶信息等方面使用HTTPS。

參考網址

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。