閱讀阮一峰博客《SSL/TLS協(xié)議運(yùn)行機(jī)制的概述》和《圖解SSL/TLS協(xié)議》摘錄

作用

不使用SSL/TLS。 明文傳播的風(fēng)險(xiǎn)：

1. 竊聽風(fēng)險(xiǎn)
2. 篡改風(fēng)險(xiǎn)
3. 冒充風(fēng)險(xiǎn)

SSL/TLS設(shè)計(jì)

1. 加密傳輸。
2. 校驗(yàn)機(jī)制。
3. 身份證書。

基本的運(yùn)行過程

SSL/TLS協(xié)議基本思路是采用公鑰加密法?？蛻舳讼认蚍?wù)器索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

但是，這里有兩個(gè)問題。

1）如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

2）公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？

解決方法：每次對話（session），客戶端和服務(wù)器都生成一個(gè)“對話密鑰”（session key），用它來加密信息。由于“對話密鑰”是對稱加密，所以運(yùn)算速度非?？欤?wù)器公鑰只用于加密“對話密鑰”本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。

因此，SSL/TLS協(xié)議的基本過程就是這樣的：

1）客戶端向服務(wù)器端索要并驗(yàn)證公鑰。
2）雙方協(xié)商生成“對話密鑰”。
3）雙方采用“對話密鑰”進(jìn)行加密通信。

上述過程的前兩步，又稱“握手階段”（handshake）。

握手階段的詳細(xì)過程

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

handshake.png

1. 客戶端發(fā)出請求（ClientHello）

1. 支持的協(xié)議版本，比如TLS 1.0版本。
   2）客戶端生成的隨機(jī)數(shù)，稍后用于生成“對話密鑰”。
   3）支持的加密方法，比如RSA公鑰加密。
   4）支持的壓縮方法。

2. 服務(wù)器響應(yīng)（ServerHello）

1. 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。
   2）服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成“對話密鑰”。
   3）確認(rèn)事宜的加密方法，比如RSA公鑰加密。
   4）服務(wù)器證書。

3. 客戶端響應(yīng)

1）一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽。
2）編碼改變通知，表示隨后的信息都將用雙方協(xié)商的加密方法和密鑰發(fā)送。
3）客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來供<u>服務(wù)器校驗(yàn)</u>。

**上面第一項(xiàng)的隨機(jī)數(shù)，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，又稱“pre-master key”。有了它以后，客戶端就同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把“會話密鑰”。

4. 服務(wù)器的最后回應(yīng)

1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用于供<u>客戶端校驗(yàn)</u>。

至此，整個(gè)握手階段全部結(jié)束。接下來，客戶端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過用“會話密鑰”加密內(nèi)容。

擴(kuò)展閱讀：

SSL/TLS協(xié)議運(yùn)行機(jī)制的概述

圖解SSL/TLS協(xié)議