---

前言

什么是HTTPS？

超文本傳輸安全協議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種網絡安全傳輸協議。具體介紹以前先來介紹一下以前常見的HTTP，HTTP就是我們平時瀏覽網頁時候使用的一種協議。HTTP協議傳輸的數據都是未加密的，也就是明文，因此使用HTTP協議傳輸隱私信息非常不安全。HTTP使用80端口通訊，而HTTPS占用443端口通訊。在計算機網絡上，HTTPS經由超文本傳輸協議（HTTP）進行通信，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網絡服務器的身份認證，保護交換數據的隱私與完整性。這個協議由網景公司（Netscape）在1994年首次提出，隨后擴展到互聯網上。

SSL，即傳輸層安全，是一種用C語言編寫的加密協議，在計算機網絡上提供通信安全。它通過使用加密來保護數據的完整性和保密性。

TLS，即傳輸層安全，是一種在互聯網上進行安全通信的標準。它允許客戶/服務器應用程序以一種旨在防止竊聽和篡改信息的方式在網絡上通信。

---

一、為什么需要加密？

因為http的內容是明文傳輸的，明文數據會經過中間代理服務器、路由器、wifi熱點、通信服務運營商等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊。所以我們才需要對信息進行加密。最容易理解的就是對稱加密 。

常見的加密方式：

對稱加密：

1. 采?單鑰密碼系統的加密?法，同?個密鑰可以同時?作信息的加密和解密，這種加密?法稱為對
   稱加密，也稱為單密鑰加密，特征：加密和解密所?的密鑰是相同的
2. 常?對稱加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
3. 特點：算法公開、計算量?、加密速度快、加密效率?
4. 對稱加密其實就是通過同?個"密鑰",把明?加密成密?,并且也能把密?解密成明?

非對稱加密

1. ?對稱加密需要兩個密鑰來進?加密和解密，這兩個密鑰是公開密鑰和私有密鑰。
2. 常??對稱加密算法(了解)：RSA，DSA，ECDSA
3. 特點：算法強度復雜、安全性依賴于算法與密鑰但是由于其算法復雜，?使得加密解密速度沒有對稱加密解密的速度快。
4. 公鑰和私鑰是配對的.最?的缺點就是運算速度?常慢，?對稱加密要慢很多：
   通過公鑰對明?加密,變成密?，通過私鑰對密?解密,變成明?

數據摘要&&數據指紋

1. 數字指紋(數據摘要)，其基本原理是利?單向散列函數(Hash函數)對信息進?運算，?成?串固定?度的數字摘要。數字指紋并不是?種加密機制，但可以?來判斷數據有沒有被竄改。
2. 摘要常?算法：有MD5、SHA1、SHA256、SHA512等，算法把?限的映射成有限，因此可能會有碰撞（兩個不同的信息，算出的摘要相同，但是概率?常低）
3. 摘要特征：和加密算法的區別是，摘要嚴格意義不是加密，因為沒有解密，只不過從摘要很難反推原信息，通常?來進?數據對?

二、只用對稱加密可以嗎？

如果通信雙?都各?持有同?個密鑰X，且沒有別?知道，這兩?的通信安全當然是可以被保證的（除
?密鑰被破解）

引?對稱加密之后，即使數據被截獲，由于?客不知道密鑰是啥，因此就?法進?解密，也就不知道請求的真實內容是啥了。

但事情沒這么簡單，服務器同?時刻其實是給很多客戶端提供服務的，這么多客戶端,每個??的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了,?客就也能拿到了)，因此服務器就需要維護每個客戶端和每個密鑰之間的關聯關系，這也是個很?煩的事情~

?較理想的做法,就是能在客?端和服務器建?連接的時候,雙?協商確定這次的密鑰是啥~

但是如果直接把密鑰明?傳輸，那么?客也就能獲得密鑰了~~此時后續的加密操作就形同虛設了，
因此密鑰的傳輸也必須加密傳輸!

但是要想對密鑰進?對稱加密，就仍然需要先協商確定?個"密鑰的密鑰"，這就成了"先有雞還是先有
蛋"的問題了，此時密鑰的傳輸再?對稱加密就?不通了。

三、只使用非對稱加密

鑒于?對稱加密的機制，如果服務器先把公鑰以明??式傳輸給瀏覽器，之后瀏覽器向服務器傳數據
前都先?這個公鑰加密好再傳，從客戶端到服務器信道似乎是安全的(有安全問題)，因為只有服務器有
相應的私鑰能解開公鑰加密的數據。

但是服務器到瀏覽器的這條路怎么保障安全？

如果服務器?它的私鑰加密數據傳給瀏覽器，那么瀏覽器?公鑰可以解密它，?這個公鑰是?開始通
過明?傳輸給瀏覽器的，若這個公鑰被中間?劫持到了，那他也能?該公鑰解密服務器傳來的信息
了。

四、雙方都使用非對稱加密

1. 服務端擁有公鑰S與對應的私鑰S’，客戶端擁有公鑰C與對應的私鑰C’
2. 客戶和服務端交換公鑰
3. 客戶端給服務端發信息：先?S對數據加密發送，只能由服務器解密，因為只有服務器有私鑰S’
4. 服務端給客戶端發信息：先?C對數據加密發送，只能由客戶端解密，因為只有客戶端有私鑰C’

這樣貌似也?啊，但是效率太低！！！但也有安全問題！！！

五、使用非對稱加密+對稱加密

我們用對稱加密提高效率：

1. 服務端具有?對稱公鑰S和私鑰S’
2. 客戶端發起https請求，獲取服務端公鑰S
3. 客戶端在本地?成對稱密鑰C，通過公鑰S加密，發送給服務器
4. 由于中間的?絡設備沒有私鑰,即使截獲了數據，也?法還原出內部的原?，也就?法獲取到對稱密鑰(真的嗎？)
5. 服務器通過私鑰S’解密，還原出客戶端發送的對稱密鑰C，并且使?這個對稱密鑰加密給客戶端返回的響應數據
6. 后續客戶端和服務器的通信都只?對稱加密即可，由于該密鑰只有客戶端和服務器兩個主機知道，其他主機/設備不知道密鑰即使截獲數據也沒有意義

看似天衣無縫，但實際上還存在安全問題！如果從最開始，中間人就開始攻擊了呢？

1. 服務器具有?對稱加密算法的公鑰S，私鑰S’
2. 中間?具有?對稱加密算法的公鑰M，私鑰M’
3. 客戶端向服務器發起請求，服務器明?傳送公鑰S給客戶端
4. 中間?劫持數據報?，提取公鑰S并保存好，然后將被劫持報?中的公鑰S替換成為??的公鑰M，并將偽造報?發給客?端
5. 客戶端收到報?，提取公鑰M(??當然不知道公鑰被更換過了)，??形成對稱秘鑰X，?公鑰M加密X，形成報?發送給服務器
6. 中間?劫持后，直接???的私鑰M’進?解密，得到通信秘鑰X，再?曾經保存的服務端公鑰S加密后，將報?推送給服務器
7. 服務器拿到報?，???的私鑰S’解密，得到通信秘鑰X
8. 雙?開始采?X進?對稱加密，進?通信。但是?切都在中間?的掌握中，劫持數據，進?竊聽甚?修改，都是可以的

問題本質出在哪?了呢？客戶端?法確定收到的含有公鑰的數據報?，就是?標服務器發送過來的！

六、引入證書

服務端在使?HTTPS前，需要向CA機構申領?份數字證書，數字證書?含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務端公鑰的權威性。

下圖截自《圖解TCP/IP》:

證書本身的傳輸過程中，如何防止被篡改？即如何證明證書本身的真實性？身份證運用了一些防偽技術，而數字證書怎么防偽呢？

1.如何放防止數字證書被篡改？

我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數字證書的“防偽技術”，這里的“簽名”就叫數字簽名：

數字簽名的制作過程：

1. CA機構擁有非對稱加密的私鑰和公鑰。
2. CA機構對證書明文數據T進行hash。
3. 對hash后的值用私鑰加密，得到數字簽名S。

瀏覽器驗證過程：

1. 拿到證書，得到明文T，簽名S。
2. 用CA機構的公鑰對S解密（由于是瀏覽器信任的機構，所以瀏覽器有它的公鑰），得到S’。
3. 用證書里指明的hash算法對明文T進行hash得到T’。
4. 顯然通過以上步驟，T’應當等于S‘，除非明文或簽名被篡改。所以此時比較S’是否等于T’，等于則表明證書可信。

2.中間人有可能篡改該證書嗎？

假設中間人篡改了證書的原文，由于他沒有CA機構的私鑰，所以無法得到此時加密后簽名，無法相應地篡改簽名。瀏覽器收到該證書后會發現原文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人。

3.中間人有可能掉包該證書嗎？

假設有另一個網站B也拿到了CA機構認證的證書，它想劫持網站A的信息。于是它成為中間人攔截到了A傳給瀏覽器的證書，然后替換成自己的證書，傳給瀏覽器，之后瀏覽器就會錯誤地拿到B的證書里的公鑰了，這確實會導致上文“中間人攻擊”那里提到的漏洞？

其實這并不會發生，因為證書里包含了網站A的信息，包括域名，瀏覽器把證書里的域名與自己請求的域名比對一下就知道有沒有被掉包了。

4.怎么證明CA機構的公鑰是可信的？

讓我們回想一下數字證書到底是干啥的？沒錯，為了證明某公鑰是可信的，即“該公鑰是否對應該網站”，那CA機構的公鑰是否也可以用數字證書來證明？沒錯，操作系統、瀏覽器本身會預裝一些它們信任的根證書，如果其中會有CA機構的根證書，這樣就可以拿到它對應的可信公鑰了。

實際上證書之間的認證也可以不止一層，可以A信任B，B信任C，以此類推，我們把它叫做信任鏈或數字證書鏈。也就是一連串的數字證書，由根證書為起點，透過層層信任，使終端實體證書的持有者可以獲得轉授的信任，以證明身份。

5.每次進行HTTPS請求時都必須在SSL/TLS層進行握手傳輸密鑰嗎？

每次請求都經歷一次密鑰傳輸過程非常耗時，那怎么達到只傳輸一次呢？

服務器會為每個瀏覽器（或客戶端軟件）維護一個session ID，在TLS握手階段傳給瀏覽器，瀏覽器生成好密鑰傳給服務器后，服務器會把該密鑰存到相應的session ID下，之后瀏覽器每次請求都會攜帶session ID，服務器會根據session ID找到相應的密鑰并進行解密加密操作，這樣就不必要每次重新制作、傳輸密鑰了！