HTTPS工作流程

oaksharks發表於2020-04-19

HTTP

1. RSA演算法

1.1. 特點

RSA的金鑰分成兩個部分：

PublicKey
- 加密資料
- 驗證簽名
- 不能解密
- 任何人都可以獲得
Private Key
- 資料簽名（摘要演算法）
- 解密
- 加密（不用此功能）
- 不公開

RSA演算法的特點：

公鑰端到私鑰端的通訊是安全的
- 因為只有私鑰能解密
任何人都可以拿到公鑰給私鑰端發資訊
私鑰端給公鑰端回訊息不安全
- 私鑰發的訊息公鑰可解密，任何人都可看到
- 私鑰回的訊息可以簽名，保證無法被篡改

1.2. 生產中應用RSA演算法

下文中的發訊息可以理解為C/S中客戶端，收訊息和回訊息理解為服務端。

單對RSA金鑰適合場景：

單向發訊息和收訊息要求絕對安全
回訊息要求不能被篡改，內容被別人看到也無所謂

以上滿足以上特點的場景很少，更多時候希望通訊雙方的所有資料都是加密的，並且都雙方都可以解密，而且別人無法破解。這種時候可以使用對稱加密，但是需要雙方都配置好金鑰就好了；如果使用RSA，只利用RSA發訊息安全的特點，那麼有兩種方式：

方式一：兩對RSA金鑰

思路：兩對RSA金鑰，發訊息時都用對方的公鑰。
準備：雙方各生成一對公鑰和私鑰，並把公鑰給對方。
發訊息：用對方的公鑰把訊息加密發給對方。
收訊息：用自己的私鑰解密訊息。
回訊息：類似發訊息，用對方的公鑰傳送加密訊息。

如果在Client-Server模型應用中使用這種方式步驟為：

服務端開放自己的公鑰
- 客戶端傳送訊息給服務端用服務端的公鑰
客戶端生成自己公鑰和私鑰，並把自己的公鑰發給服務端
- 服務端回訊息時候用客戶端的私鑰加密

這種方式是ssh免密登陸的實現，客戶端接受服務端的公鑰放到 ~/.ssh/known_hosts,客戶端再把自己的公鑰配置到服務端的~/.ssh/authorized_keys，這樣就實現了雙向加密通訊。

方式二：RSA+對稱加密

思路：公鑰端發訊息時候，對訊息再進行一次對稱加密並把密碼發給私鑰端，後續對稱加密通訊
準備：只要收訊息一端有RSA金鑰對，發訊息一端不需要有自己的金鑰對
發訊息：公鑰端把資料對稱加密，然後把加密結果和對稱加密的金鑰用公鑰加密，一起發給私鑰端
收訊息：私鑰解密後拿到對稱金鑰和報文，再對報文解密得到明文
回訊息：回訊息只對稱加密資料然後簽名，公鑰端先驗籤再用公鑰解密

方式二https協議使用方案，也是ssh協議非免密的實現方案。

2. HTTPS協議

http是應用層協議，在tcp協議之上。這兩個協議傳輸的都是明文，tcp之上再加一層安全協議SSL（Security Socket Layer），基於這一層實現http得到的就是https。

SSL是安全套接字程式設計介面，後來又進化為TLS（Transport Layer Security）傳輸層安全，定位類似，都是給TCP協議加密的。不管SSL和TLS都是軟體實現的協議，在TCP/IP 4層模型中，它們也是應用層的。

在上一章，我們知道https同時利用了rsa和對稱加密方法，通訊流程為：

步驟1：客戶端請求服務端的證書
- 這一步被攔截、篡改了也沒問題，因為只是通訊前的準備工作
步驟2：服務端給客戶端傳送證書
- 客戶端收到證書後驗真，如果OK，就有服務端的公鑰了
- 證書是公開的，被攔截了也沒問題
- 如果被篡改成假證書，並且客戶端驗證通過就不安全了
  - 客戶端用假證書的公鑰加密併傳送，被攔截後可以被跟假公鑰配對的私鑰破解
  - 證書必須由專業結構（CA）發放
    - 發放機構對證書所有者稽核
    - 如果使用假證書破解就可以根據家假證書找到破解者
步驟3：客戶端生成對稱金鑰並用公鑰傳送給服務端
- 客戶端記錄下來生成的金鑰
步驟4：服務端解析出對稱金鑰並儲存
步驟5：客戶端使用對稱金鑰加密資料傳送
步驟6：服務端使用對稱金鑰解密資料，並把響應資料用對稱金鑰加密

rsa的主要作用：

客戶端與伺服器之間約定對稱金鑰

對稱加密的作用：

http報文安全傳輸

SSL證書包含的資訊：

證書的釋出機構CA(Certificate Authoritie)
證書的有效期
公鑰
證書所有者
簽名

證書最主要的作用就是儲存伺服器的公鑰，並且保證伺服器的的公鑰是安全有效的，整個https安全的核心也是基於證書發放機構絕對安全。如果客戶端拿著一個假的證書用了一個假的rsa 公鑰，並且加密了傳送，那這個假的公鑰所對應的私鑰就可以解密資料了。證書的真假只有靠證書的發放結構去驗證，選擇一家靠譜的釋出機構很重要。