https的加密解密過程

前置知識

SSL是90年代Netscape弄出來的一套東西，爲的是解決HTTP協議明文傳輸數據的問題。後來SSL慢慢成了事實上的標準，因而IETF就把SSL標準化了，名字叫作TLS，TLS 1.0其實就是SSL 3.1。因此SSL和TLS常常被放在一塊兒寫成SSL/TLS，由於這兩個名詞在如今其實就是同一個東西。HTTPS是使用TLS的HTTP協議。

證書以及信任鏈

咱們知道，HTTPS的網站都有一個本身的證書，用於代表本身的身份。證書本質上是爲了讓公鑰能可信的傳輸。公鑰是放在證書裏面的，若是證書可信，那麼公鑰就也是可信的。那爲何一個公鑰是可信的呢？這就要說到信任鏈和CA。CA指的是Certificate Authority，CA都是權威機構，他們的證書叫作根證書，這些根證書被操做系統信任，根證書信任的證書也是可信的。所以權威機構頒發的證書都能被操做系統信任，這就組成了信任鏈。

 

這裏以RSA密鑰交換算法爲例爲例，CloudFlare提供Keyless服務，把網站放到它們的CDN上，不用提供本身的私鑰，也能使用SSL加密連接。

 

https加密解密過程：

1. 客戶端發起https請求到服務端（服務器端要一套數字證書，能夠本身製做，也能夠向組織申請），向服務器端索要公鑰。

   發送的信息通常帶上：

   • 客戶端生成的一個隨機值

   • 支持的SSL/TSL協議的版本號

   • 所支持的加密算法

   • Session ID（用於恢復會話）

2. 服務端接收到客戶端的請求後迴應客戶端以及公鑰（也就是證書）傳給客戶端。若是帶有Session ID，直接恢復對話。

   沒有Session ID通常會返回這些信息給客戶端：

   • 選擇SSL/TLS協議的版本號

   • 選擇加密方式

   • 一個服務器隨機生成的數

   • 服務器的證書

3. 客戶端收到服務端發來的公鑰後會解析證書，首先是由TLS層來驗證服務端證書是否有效，好比說頒發機構、有效時間、證書中的域名與當前會話域名是否匹配等。

   若是發現異常，就會彈出一個警告框，提示證書有問題。

   驗證完證書的有效性後，客戶端向服務端發送的信息包括有一下內容：

   • 證書校驗沒有問題的話，生成一個premaster secret（另外一個隨機值），而後用服務端發過來的證書對該隨機值進行加密。

   • 客戶端把加密的隨機值傳回給服務器，加密約定改變，通知服務器，其目的是讓服務端獲得這個隨機值，之後客戶端與服務端之間的通訊就用協商好的加密方法和密鑰進行加密。

   • 客戶端握手結束通知。這個報文也是驗證消息，是前面發送的全部內容的哈希值，用來供服務器校驗。

4. 服務器用私鑰解密後，獲得了客戶端傳過來的隨機值（私鑰），而後對該值進行對稱加密。所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，除非知道私鑰，不然沒法得到內容，於是客戶端和服務端都知道這個公鑰，只要加密算法夠彪悍，私鑰夠複雜，數據就越安全。

   這是握手過程的最後一步，服務器會把如下信息發送給客戶端：

   • 加密約定改變通知，通知客戶端，之後的通訊都適用協商好的加密方法和密鑰進行加密

   • 服務器握手結束通知，該報文也做爲校驗消息，供客戶端驗證

5. 服務端利用這個私鑰加密數據併發送數據給客戶端，加密的數據能夠被還原

6. 客戶端接收到這份數據後，利用私鑰解密這段數據，因而獲取了加密的內容。即時第三方在數據傳輸的中途獲取了這份數據，沒有私鑰也一籌莫展

SSL/TLS層是位於應用層和傳輸層之間，應用層的數據再也不直接傳遞給傳輸層，而是傳遞給SSL/TLS層，對傳過來的數據進行加密，並增長相應的頭信息。

整個對話過程當中（握手階段和其後的對話），服務器的公鑰和私鑰只須要用到一次。這就是CloudFlare可以提供Keyless服務的根本緣由。

某些客戶（好比銀行）想要使用外部CDN，加快自家網站的訪問速度，可是出於安全考慮，不能把私鑰交給CDN服務商。這時，徹底能夠把私鑰留在自家服務器，只用來解密對話密鑰，其餘步驟都讓CDN服務商去完成。

 

加解密相關知識

對稱加密

對稱加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密算法。有時又叫傳統密碼算法，就是加密密鑰可以從解密密鑰中推算出來，同時解密密鑰也能夠從加密密鑰中推算出來。而在大多數的對稱算法中，加密密鑰和解密密鑰是相同的，因此也稱這種加密算法爲祕密密鑰算法或單密鑰算法。

常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC四、IDEA

 

非對稱加密

與對稱加密算法不一樣，非對稱加密算法須要兩個密鑰：公開密鑰（public key）和 私有密鑰（private key）；而且加密密鑰和解密密鑰是成對出現的。非對稱加密算法在加密和解密過程使用了不一樣的密鑰，非對稱加密也稱爲公鑰加密，在密鑰對中，其中一個密鑰是對外公開的，全部人均可以獲取到，稱爲公鑰，其中一個密鑰是不公開的稱爲私鑰。

 

主要算法：RSA、Elgamal、揹包算法、Rabin、D-H、ECC（橢圓曲線加密算法）

 

使用最普遍的是RSA算法，Elgamal是另外一種經常使用的非對稱加密算法。

 

RSA性能是很是低的，緣由在於尋找大素數、大數計算、數據分割須要耗費不少的CPU週期，因此通常的HTTPS鏈接只在第一次握手時使用非對稱加密，經過握手交換對稱加密密鑰，在以後的通訊走對稱加密。

 

總結：

服務端用RSA生成公鑰和私鑰，把公鑰放在證書裏發送給客戶端，私鑰本身保存

客戶端接收到公鑰後，首先向一個權威的服務器檢查證書的合法性，若是證書合法，客戶端產生一段隨機數，這個隨機數就做爲通訊的密鑰，咱們稱之爲對稱密鑰，用公鑰加密這段隨機數，而後發送到服務器

服務器用密鑰解密獲取對稱密鑰，而後，雙方就已對稱密鑰進行加密解密通訊了

 

傳輸服務器的證書（公鑰）時，被別人竊取走了怎麼辦？

固然服務器沒有這麼笨，傳給客戶端的證書是被加密了的，並且是由第三方權威機構CA的私鑰加密證書，第三方權威機構CA的公鑰維護於(存在於)每一個瀏覽器(不管是中間的黑客、真正的請求者，還有服務器)中。這些有CA機構頒發的證書，都是有CA機構加密了的，客戶端或者中間商收到這份CA頒發的證書，均可以解密出服務器的公鑰。

 

那麼，最開始https請求到服務器給的證書（CA機構頒發的）過程當中，證書到達客戶端的路上被黑客攔截了，中間的 "笨笨的黑客" 向CA申請了一套本身的證書，把自家的證書發回給那個客戶端，而後經過本身申請的那一套證書的私鑰解密出客戶端發出的信息，經過攔截下來的服務器端的公鑰解密服務端返回給客戶端的信息，在中間的位置竊取信息。固然這種事情不會發生，權威的CA機構頒發的證書是有數字簽名的，任何組織申請的證書都有對應的證書編碼，證書是頒發給誰的，使用者是誰，這些申請者的詳細信息都是被記錄在案，客戶端接收到這份證書後會計算出證書數字簽名，證書的使用者對不上也是沒有用的。

這樣，經過權威的CA機構和證書的數字簽名，客戶端和服務器端之間創建起的對話祕鑰就不會被別人竊取走，即時中間的第三者拿到了服務器的公鑰也沒有辦法解密用服務器公鑰加密的內容。