HTTPS 加密原理探究

標籤：ast   傳輸   中間人   中間   而不是   解密   middle   引入   bsp   

由於之前項目中IOS系統建議將http協議換成https協議所以查看相關資料在此記錄 HTTPS 通訊過程的基本原理

問：Https是什嗎？

答：

HTTP 協議定義了一套規範，讓用戶端或瀏覽器可以和伺服器正常通訊，完成資料轉送

但是，HTTP 使用明文傳輸，你輸入的賬戶密碼等重要訊息易被中間人竊聽，從而造成資料泄露，所以說 HTTP 是不安全的，為瞭解決安全傳輸的問題，人們發明了 HTTPS，即 HTTP + Secure

問：為什麼 HTTPS 是安全的？

答：

只要把傳輸的資料加密，那麼通訊就是安全的，前提是除通訊雙方外，任何第三方無法解密

問：HTTPS 是怎麼實現安全通訊的？

答：

使用對稱式加密技術，簡單而言，通訊雙方各有一把相同的鑰匙（所謂對稱），用戶端把資料加密鎖起來後，傳送給伺服器，伺服器再用鑰匙解密。同理，伺服器加密後傳輸給用戶端的資料，用戶端也可以用鑰匙解密，此處有一個新問題怎樣在通訊之前，給雙方分配兩把一樣的鑰匙呢？有一個簡單的解決方案是：用戶端在每次請求通訊之前，先和伺服器協商，通過某種辦法，產生只有雙方知道的對稱金鑰

這個過程就是所謂：金鑰交換(Key Exchange)，金鑰交換演算法有很多，常見的有

• Deffie-Hellman 金鑰交換演算法
• RSA 金鑰交換演算法 

在此，以RSA演算法為例進行介紹

RSA 金鑰交換演算法需要用戶端向伺服器提供一個 Pre-Master-Key，然後通訊雙方再產生 Master-Key，最後根據 Master-Key 產生後續一系列所需要的密鑰，包括傳輸資料的時候使用的對稱金鑰。那麼用戶端怎麼把 Pre-Master-Key 告訴伺服器呢？

在此引入一種新的加密技術：非對稱式加密（伺服器可以產生一對不同的密鑰，一把私自儲存，稱為私密金鑰；一把向所有人公開，稱為公開金鑰
這對密鑰有這樣的性質：公開金鑰加密後的資料只有私密金鑰能解密，私密金鑰加密後的資料只有公開金鑰能解密）

具體的互動過程：

1. 用戶端向伺服器索取公開金鑰 PublicKey；
2. 伺服器將公開金鑰發給用戶端（這裡沒有保密需求，因為公開金鑰是向所有人公開的）；
3. 用戶端使用伺服器的公開金鑰 PublicKey 把 Pre-Master-Key 加密成密文，傳送給伺服器；
4. 伺服器用私密金鑰 PrivateKey 解密密文，擷取到用戶端發送的 Pre-Master-Key;

在此又會引發新的問題，由於互連網是公開的，伺服器發送給用戶端的公開金鑰可能在傳送過程中被中間人截獲並篡改（所謂中間人攻擊 Man-in-the-middle attack，縮寫：MITM），因為中間人也可以產生一對非對稱金鑰，它會截獲伺服器發送的公開金鑰，然後把它自己的公開金鑰 MiddleMan-PublicKey 發送給用戶端，進行欺騙。

為瞭解決這個問題，伺服器需要到權威機構 (Authority) 辦一張認證 Certificate，上面記載了伺服器的網域名稱、公開金鑰、所屬單位，還有簽發機關、有效期間等當用戶端收到伺服器發過來的認證後，只要認證不是偽造的，那麼上面記載的公開金鑰肯定也就是真的！

不過，這裡又有個新問題：怎麼證明認證不是偽造的？

只要伺服器發送的認證上有權威機構 Authority 的簽名，就可以確信認證是頒發給伺服器的，而不是誰偽造的

如此看來

HTTPS 通訊過程已經很明朗了：

1. 作業系統/瀏覽器 內建了 CA 根憑證；
2. 用戶端因此可以驗證伺服器發送的認證真實性，從而擷取到伺服器的公開金鑰；
3. 有了伺服器的公開金鑰，用戶端就可以把 Pre-Master-Key 傳送給伺服器；
4. 伺服器擷取到 Pre-Master-Key 後，通過後續產生的對稱金鑰，就可以和用戶端加密通訊了。

 

HTTPS 加密原理探究