圖解 SSL/TLS 協議

1. 概覽

在構建網絡應用，特別是暴露在 internet 中的應用時，通常都會使用 SSL/TLS 協議增強 數據傳輸的安全性，其結構如下：

2. 握手協議 Shakehand

其中最重要，最複雜（未必是被理解最清楚的）的是握手協議 Shakehand。本來想找一張清 晰易懂的 Shakehand 流程圖，看到 wikipedia 的這張圖很 好，有人持續更新它，但就是字體太小，眼睛都瞪瞎了*_*，索性操起超超超強大的 DRAW.io（需先科學上網，Why?），從新做輪子，期間參考 了《圖解密碼技術》的相 關章節，加入了便于理解的對話。希望這圖對大家有幫助。

另外，大家可以留意一下 Client 和 Server 證書（cert.）的交換時機（Phase 2 和 3） ，這就是我們平時在客戶端和服務器端所安裝的證書的使用時刻，這裏是典型的雙向證書驗 證，通常在搭建 SSL/TLS 應用的時候都這麽做，目的是確保雙方都是可信的（因為雙方都 安裝了某 CA 的 root cert， 且雙方的 cert 都由這個 CA 所 trust，所 issue）。

握手完成後，Client 和 Server 端就會使用應用數據協議和 TLS 記錄協議進行加密通信。 從結果來看，握手協議完成了下列操作：

1. Client 端獲得了 Server 端的合法公鑰，完成了 Server 認證。
2. Server 獲得了客戶端的合法公鑰，完成了 Client 認證 （當需要客戶端認證時）。
3. Client 和 Server 生成了消息認證碼(MAC：Message Authentication Code)中使用的共 享密鑰。
4. Client 和 Server 生成了加密通信中使用的共享密鑰（上圖的 MS）。

3. 解答幾個網上常見的問題：

1. SSL 和 TLS 的區別

TLS 是 SSL 的繼承者，SSL3.0，之後的 TLS1.0 相當于 “SSL3.1”。

Version	公布日期	Remark
SSL 1.0	Netscape 未公布
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0 (SSL 3.1)	1999	為了兼容 SSL，包括可以降級到 SSL 3.0 的實現，這削弱了連接的安全性
TLS 1.1 (SSL 3.2)	2006
TLS 1.2 (SSL 3.3)	2008
TLS 1.3	TBD，至 Apr 2015 還是草案狀態

2. TLS (Transport Layer Security) 是傳輸層協議嗎？

不是。它是一套應用層協議：

TLS: In the Internet Protocol Suite, TLS and SSL encrypt the data of network connections in the application layer. In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer).[citation needed]

它在會話層被初始化，然後工作在表示層。另外，不僅是 HTTP，其他應用層協議（例如 ：FTP, SMTP 等）都可以使用 TLS，而常見的 UDP 使用的是 DTLS。

3. SSL 和 TLS，應該選用哪個作為服務器端的安全策略的一部分？

盡量用最新的 TLS 1.2，它修複了之前版本的許多漏洞。當前大部分 WS（Web Server）産 品都已經支持，如 從Nginx，Tomcat 6.0.43和IIS 7.5開 始。即使你當前用的 WS 不支持 TLS 1.2，也盡可能使用支持 TLS 1.0 的 WS 版本，並 且禁用 Client 和 Server 端的 SSL 3.0，因為去年底爆出的 POODLE 安全缺陷說明僅僅升級到 TLS 1.x 是 不夠的。

利用該缺陷進行攻擊主要分兩步：

1. 攻擊者先通 過Version rollback attacks使 TLS shakehand 失敗，C/S 就會協商降級使用 SSL 3.0 再次 shakehand。
2. 然後就可以利用 POODLE 進行攻擊啦。

有鑒于此，在 POODLE 缺陷被證實後，主流浏覽器大廠已經在自家産品中強制使用 TLS 並 禁用了 SSL 3.0，杜絕 rollback 回 SSL 3.0。如果你的浏覽器已經禁用 SSL 3.0 的話， 浏覽只支持 SSL 3.0 的網站會看到類似的警告：

4. 怎麽知道我用的浏覽器和某網站支持什麽版本的 SSL/TLS 協議？

• 簡單的
• 服務端 SSL 支持檢測
• 本地 SSLv3 支持檢測
• 複雜的
• Linux/OSX: nmap --script ssl-enum-ciphers -p 443 www.alipay.com
• Windows: Zenmap

Output

username@yourhostname:[~]
nmap --script ssl-enum-ciphers -p 443 www.alipay.com
Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-05 08:36 HKT
Nmap scan report for www.alipay.com (110.75.142.111)
Host is up (0.091s latency).
DNS record for 110.75.142.111: host-111.alipay.com
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
~~~~~~~~~~（此處省略多行）~~~~~~~~~~
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     compressors:
|       NULL
|_  least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 3.82 seconds

5. 為什麽連 alipay.com 這樣的網站還保留 SSL 3.0？不是說 SSL3.0 不安全了嗎？

問得好！它不但保留了 SSL 3.0，還保留了已經不安全的 RC4 加密算法（速度極快的算法 ，8bit 的機器都能很快算出僞隨機數(圖上的 RNc)）。

這不是阿裏的疏忽，而 是像許多網站那樣想 兼容那些舊版浏覽器（雖然的數量已經很少很少），比如像我 XP 裏那萬年不升級的 IE6 和老舊 的功能手機 Candy bar phone的 內置浏覽器。