—— 加餐開始 ——
相關技術#
SSL/TLS#
為了解決 HTTP 明文傳輸信息的安全問題，HTTPS 在 HTTP 的基礎上引入了 SSL/TLS (Secure Sockets Layer / Transport Layer Security) 安全協議，使得信息能夠加密傳輸。
我們先來看一下 SSL/TLS 的發展歷史：
其實，SSL 是 TLS 的前身。
SSL 是網景公司設計的，在 SSL 3.0 後，網景公司將 SSL 交給了 IETF（互聯網工程任務組），IETF 將 SSL 標準化，推出 TLS 1.0（= SSL 3.1），並將其錄入 RFC（記錄互聯網規範、協議、過程等的標準文件）。經過更新迭代，
目前（2022 年 5 月）使用的 TLS 版本只剩下 1.2 和 1.3。
PS：圖裡為什麼沒有看到 SSL 1.0 呢？因為它存在很大的安全漏洞，所以根本沒有被公開發布。
參考：
-
SSL/TLS 歷史與前沿導覽——Blog
-
SSL/TLS 協議各版本間的差異—— 安信證書
關於 TLS 握手的過程，我們簡單看下下面這張圖（左邊是單向認證過程，右邊是雙向認證過程）：
可以看到：
-
TLS 握手是在建立了 TCP 連接之後；
-
雙向認證過程中，客戶端也會發送自己的證書給服務端；
-
在 ChangeCipherSpec 後，信息就是加密傳輸的了；
整個 TLS 握手過程主要涉及傳遞證書、密鑰交換等步驟，具體的原理，我這裡推薦一些不錯的資料～
可以帶著2 個問題去看下面的資料：1）ClientHello 只是簡單的說 “Hello” 嗎？2）加密傳輸信息所用的密鑰是怎麼來的？（在後面的「實踐部分 > WireShark」會公布答案，大大推薦通過網絡包分析工具 WireShark 加深對 TLS 握手過程的理解。）
-
視頻：SSL/TLS 握手過程——bilibili
-
文章
-
SSL/TLS 協議運行機制的概述—— 阮一峰
-
HTTPS - 揭秘 TLS 1.2 協議完整握手過程——51CTO
-
HTTPS RSA 握手解析—— 小林 Coding
-
HTTPS ECDHE 握手解析—— 小林 Coding
-
Tips：從小林 Coding 的文章可以發現，上圖裡的流程不是絕對的，因為不同的密鑰交換算法（RSA、ECDHE...），對應的流程會有差異，比如基於 RSA 的密鑰交換算法的流程中，沒有 ServerKeyExchange 消息。
SSH#
SSH（Secure Shell）也是一種網絡安全協議，也是由 IETF 制定的。但它是基於 TLS 之上的應用層協議（TLS 作用於運輸層與應用層之間），通過加密和認證機制實現安全的訪問和文件傳輸等業務。如果你經常用雲主機或者 Github，那你對它一定不陌生～
SSH 連接的建立過程可以分為 3 步：
1）客戶端驗證服務器
你在首次 SSH 連接雲主機的時候，應該見過下面這張圖：
客戶端收到了雲主機的一些信息，關鍵是這裡的 “指紋”（即 ECDSA 簽名算法中公鑰的 SHA-256 值），我們可以通過ssh-keyscan -t ECDSA -p 22 [host] > key.pub獲取服務器的真實公鑰，然後通過ssh-keygen -E sha256 -lf key.pub計算其 SHA256 值，與圖中的 “指紋” 比對。如果一致，再決定連接。
由此可見，這裡的驗證過程是由客戶端控制的，客戶端可以不做任何比對，直接信任連接，但這樣存在風險。
2）生成信息加密傳輸的密鑰（通過密鑰交換算法），之後的通信均加密
3）服務器驗證客戶端（2 種方式）
a. 客戶端沒有上傳公鑰：服務端會給客戶端一個公鑰，客戶端使用該公鑰加密用戶信息（如密碼），傳給服務端，服務端校驗通過後，連接建立成功。
b. 客戶端提前上傳了公鑰到服務端：服務端會利用該公鑰加密一個隨機數發給客戶端，客戶端使用對應的私鑰解密，再傳給服務端，服務端校驗通過後，連接建立成功。
參考：SSH 免密登錄原理與實現—— 掘金
iOS 簽名#
從圖可以看出，iOS 簽名其實是一個很複雜的過程，一段文字可能無法詳細描述。
這裡只需要知道 iOS 簽名中 2 個必不可少的重要文件即可：
1）.mobileprovision 文件：又叫 PP 文件（圖中為 Provisioning Profile），可以把它理解為證書的升級版，裡面不僅有 1 個以上的 iOS 開發者證書，還有各種其它信息。
2）.p12 文件：由開發者證書和對應私鑰組成，與圖中的關鍵步驟 2 和 4 相關。Xcode 打包時需要搜索 Keychain 裡屬於 PP 文件中證書集合的證書，取出裡面的私鑰對 App 進行簽名。
詳細的講解可以看我之前的文章：iOS | 圖解 iOS 簽名背後的原理，這也是本文的源頭。
記住，如果你遇到 iOS 簽名打包相關的問題，就先從上面的 2 個文件裡入手吧～
一些實踐#
最後，介紹兩個不錯的實踐工具，來鞏固今天的內容。
OpenSSL#
OpenSSL 是一個開源的密碼學工具包，我們可以嘗試用下面的腳本，複習一下今天學習的算法。
# Generate private key (RSA)
openssl genrsa -out private.pem
# Generate public key from private key
openssl rsa -in private.pem -pubout -out pubkey.pem
echo "hello, world" > test.txt
# Encrypt
openssl rsautl -encrypt -pubin -inkey pubkey.pem -in test.txt -out test.enc
# Decrypt
openssl rsautl -decrypt -inkey private.pem -in test.enc -out test.dec
# Signature (hash:SHA-256)
## Generate
openssl dgst -sign private.pem -sha256 -out test.sig test.txt
## Verify
openssl dgst -verify pubkey.pem -sha256 -signature test.sig test.txt
# View Key as text
## Private key
openssl rsa -in private.pem -noout -text
## Public key
openssl rsa -pubin -in pubkey.pem -noout -text
# Generate a self-signed certificate
# {Creating a Self-Signed Certificate With OpenSSL——Baeldung}
...
參考：
-
openssl——Linux 命令大全
WireShark#
WireShark 是一個開源的網絡包分析工具，用它來深入理解各種網絡協議準沒錯～
下面，我們先回顧一下「相關技術 > SSL/TLS」那一節提出的問題：
1）ClientHello 只是簡單的說 “Hello” 嗎？
2）加密傳輸信息所用的密鑰是怎麼來的？
接下來，打開 WireShark，對獲取的網絡包簡單做一下過濾，如ip.addr == 115.236.119.85 && tls。
可以看到，ClientHello 裡傳遞的信息還不少，關鍵信息包括 TLS 版本、隨機數（密鑰交換算法用）、支持的 21 種加密套件（可供服務端選擇的密鑰交換算法）等。這也就解答了上面的第 1 個問題。
繼續分析後面的每一條信息，我們還會發現在 ServerHello 裡，服務端選擇了一種密鑰交換算法，最終通過該算法生成了加密傳輸信息所用的密鑰。這也就解答了上面的第 2 個問題。
更多的細節，等著你安裝 WireShark 去探索～
—— 加餐結束 ——