本文參考

tls執行機制，這裡不細說，建議細看

ssl/tls基礎介紹

SSL(Secure Sockets Layer 安全套接層)，及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通訊提供安全及資料完整性的一種安全協議。TLS與SSL在傳輸層對網路連線進行加密。

1. 認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器。

2. 加密資料以防止資料中途被竊取。

3. 維護資料的完整性，確保資料在傳輸過程中不被改變。

ssl協議結構體

SSL位於應用層和傳輸層之間，它可以為任何基於TCP等可靠連線的應用層協議提供安全性保證。

1. SSL握手協議：是SSL協議非常重要的組成部分，用來協商通訊過程中使用的加密套件（加密演算法、金鑰交換演算法和MAC演算法等）、在伺服器和客戶端之間安全地交換金鑰、實現伺服器和客戶端的身份驗證。

2. SSL密碼變化協議：客戶端和伺服器端通過密碼變化協議通知對端，隨後的報文都將使用新協商的加密套件和金鑰進行保護和傳輸。

3. SSL警告協議：用來向通訊對端報告告警資訊，訊息中包含告警的嚴重級別和描述。

4. SSL記錄協議：主要負責對上層的資料（SSL握手協議、SSL密碼變化協議、SSL警告協議和應用層協議報文）進行分塊、計算並新增MAC值、加密，並把處理後的記錄塊傳輸給對端
 

加密演算法

1. 雜湊（Hash）
把任意大小的文件變成一個 固定大小（MD5是32個字元）的字串，過程不可逆。MD5，SHA1等。

2. 對稱加密（Symmetric Cryptography）
使用同一個金鑰加密和解密，優點是速度快，缺點是金鑰管理不方便，要求共享金鑰。 DES，AES等。

3. 非對稱加密（Asymmetric Cryptography）
使用公鑰和私鑰來加密和解密，優點是金鑰管理很方便，缺點是速度慢。RSA，DSA等。

4. 數字簽名（Digital Signature）
使用雜湊和非對稱加密驗證文件的真實性。先為要簽名的資訊生成一個Hash字串，Hash1，然後用你的私鑰加密得到Encrypted(Hash1)，這就是你對這個文件的數字簽名。
當別人需要驗證某個文件是否是你簽名的時候，只需要用你的公鑰解密你的簽名得到Hash1，並和該文件計算出來的Hash2對比，檢視是否一致。如果一致則說明你確實對該文件簽過名，否則就是沒有。
 

認證方式

單向認證

客戶端向伺服器傳送訊息，伺服器接到訊息後，用伺服器端的金鑰庫中的私鑰對資料進行加密，然後把加密後的資料和伺服器端的公鑰一起傳送到客戶端，客戶端用伺服器傳送來的公鑰對資料解密，然後在用傳到客戶端的伺服器公鑰對資料加密傳給伺服器端，伺服器用私鑰對資料進行解密，這就完成了客戶端和伺服器之間通訊的安全問題，但是單向認證沒有驗證客戶端的合法性。

雙向認證

（1）客戶端向伺服器傳送訊息，首先把訊息用客戶端證書加密然後連同時把客戶端證書一起傳送到伺服器端

（2）伺服器接到訊息後用首先用客戶端證書把訊息解密，然後用伺服器私鑰把訊息加密，把伺服器證書和訊息一起傳送到客戶端

（3）客戶端用發來的伺服器證書對訊息進行解密，然後用伺服器的證書對訊息加密，然後在用客戶端的證書對訊息在進行一次加密，連同加密訊息和客戶端證書一起傳送到伺服器端，

（4）到伺服器端首先用客戶端傳來的證書對訊息進行解密，確保訊息是這個客戶發來的，然後用伺服器端的私鑰對訊息在進行解密這個便得到了明文資料。

一、下圖為客戶端和服務端的通訊流程

圖中包括服務端和客戶端電子證書請求認證，下面我們分析的例子不包含請求客戶端證書認證

二、後臺程式https tls/1.2驗證測試

下面為程式中的客戶端和服務端具體互動資訊。通過curl命令訪問api介面：

[email protected]:~# curl -1 --tlsv1.2 --cacert /root/ca.crt -X 'GET'  -v https://192.168.30.145:9131/v2.0/networks | python -mjson.tool
* Hostname was NOT found in DNS cache
*   Trying 192.168.30.145...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 192.168.30.145 (192.168.30.145) port 9131 (#0)
* successfully set certificate verify locations:
*   CAfile: /root/ca.crt
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server key exchange (12):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*    subject: C=cn; ST=hb; O=fiberhome; OU=fitos; CN=192.168.30.145
*    start date: 2017-09-21 09:29:38 GMT
*    expire date: 2018-09-21 09:29:38 GMT
*    common name: 192.168.30.145 (matched)
*    issuer: C=cn; ST=hb; L=wh; O=fiberhome; OU=fitos; CN=192.168.30.145
*    SSL certificate verify ok.
> GET /v2.0/networks HTTP/1.1
> User-Agent: curl/7.35.0
> Host: 192.168.30.145:9131
> Accept: */*
>
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/1.1 200 OK
< Content-Length: 399
< Content-Type: application/json; charset=UTF-8
< Vimid: 10a24b40-90ce-43c9-a225-edde2587ff39
< Date: Thu, 28 Sep 2017 04:06:50 GMT
<
{ [data not shown]
100   399  100   399    0     0    893      0 --:--:-- --:--:-- --:--:--   892
* Connection #0 to host 192.168.30.145 left intact
{
    "networks": [
        {
            "NetID": "a851428d-e500-4d11-b266-364035d36e28",
            "adminStateUp": true,
            "external": false,
            "netName": "net1",
            "networkType": "vxlan",
            "physicalNetwork": null,
            "segmentationID": "1057",
            "self": "/v1/networks/a851428d-e500-4d11-b266-364035d36e28",
            "shared": false,
            "status": "ACTIVE",
            "subnets": [
                "2119c378-435f-473c-a59a-d99f79c8dccf"
            ],
            "tenentId": "8c967359b4bd4be2b7989bb0d9524f56"
        }
    ]
}

同時在傳送端網絡卡抓包檢視客戶端和服務端tls加密互動過程：

[email protected]:~# ssldump -i br-ex
New TCP connection #1: 192.168.30.26(43449) <-> 192.168.30.145(9131) 
1 1  0.0016 (0.0016)  C>S  Handshake
      ClientHello
        Version 3.3
        cipher suites
        Unknown value 0xc030
        Unknown value 0xc02c
        Unknown value 0xc028
        Unknown value 0xc024
        Unknown value 0xc014
        Unknown value 0xc00a
        Unknown value 0xa3
        Unknown value 0x9f
        Unknown value 0x6b
        Unknown value 0x6a
        TLS_DHE_RSA_WITH_AES_256_CBC_SHA
        TLS_DHE_DSS_WITH_AES_256_CBC_SHA
        Unknown value 0x88
        Unknown value 0x87
        Unknown value 0xc032
        Unknown value 0xc02e
        Unknown value 0xc02a
        Unknown value 0xc026
        Unknown value 0xc00f
        Unknown value 0xc005
        Unknown value 0x9d
        Unknown value 0x3d
        TLS_RSA_WITH_AES_256_CBC_SHA
        Unknown value 0x84
        Unknown value 0xc012
        Unknown value 0xc008
        TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xc00d
        Unknown value 0xc003
        TLS_RSA_WITH_3DES_EDE_CBC_SHA
        Unknown value 0xc02f
        Unknown value 0xc02b
        Unknown value 0xc027
        Unknown value 0xc023
        Unknown value 0xc013
        Unknown value 0xc009
        Unknown value 0xa2
        Unknown value 0x9e
        TLS_DHE_DSS_WITH_NULL_SHA
        Unknown value 0x40
        TLS_DHE_RSA_WITH_AES_128_CBC_SHA
        TLS_DHE_DSS_WITH_AES_128_CBC_SHA
        Unknown value 0x9a
        Unknown value 0x99
        Unknown value 0x45
        Unknown value 0x44
        Unknown value 0xc031
        Unknown value 0xc02d
        Unknown value 0xc029
        Unknown value 0xc025
        Unknown value 0xc00e
        Unknown value 0xc004
        Unknown value 0x9c
        Unknown value 0x3c
        TLS_RSA_WITH_AES_128_CBC_SHA
        Unknown value 0x96
        Unknown value 0x41
        Unknown value 0xff
        compression methods
                  NULL
1 2  0.0148 (0.0131)  S>C  Handshake
      ServerHello
        Version 3.3
        session_id[32]=
          08 2d cc a8 1a 4a ac 41 d9 74 94 11 20 49 4a da
          23 7e 21 0f 32 98 96 14 c1 a9 88 d3 78 00 6c b4
        cipherSuite         Unknown value 0xc030
        compressionMethod                   NULL
1 3  0.0148 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0148 (0.0000)  S>C  Handshake
      ServerKeyExchange
1 5  0.0148 (0.0000)  S>C  Handshake
      ServerHelloDone
1 6  0.0171 (0.0023)  C>S  Handshake
      ClientKeyExchange
1 7  0.0171 (0.0000)  C>S  ChangeCipherSpec
1 8  0.0171 (0.0000)  C>S  Handshake
1 9  0.0209 (0.0037)  S>C  ChangeCipherSpec
1 10 0.0209 (0.0000)  S>C  Handshake
1 11 0.0213 (0.0003)  C>S  application_data
1 12 0.8137 (0.7924)  S>C  application_data
1 13 0.8142 (0.0004)  C>S  Alert
1    0.8143 (0.0000)  C>S  TCP FIN
1    0.8149 (0.0006)  S>C  TCP FIN

上面過程伺服器就沒有要求客戶端傳送客戶端電子證書進行身份認證。從認證過程看，https協商採用TLS1.2/SSL3.3版本，整個握手互動流程都有，加密成功後，客戶端和服務端的http報文就進行加密傳輸，然後通過公共金鑰計算私有金鑰進行解密。這裡就可以驗證後臺程序可以支援https tls1.2

三、tls 1.2執行互動訊息分析

下面我們對比分析訪問https://www.baidu.com的互動過程，抓包分析詳細的訊息體內容，抓包資訊如下：

如上圖，前面第一個紅框即為客戶端和服務端的通過tcp標誌位中的syn/ack的進行三次tcp握手連線，後面紅框為http請求結束後，通過fin/ack關閉tcp連線，中間為採用tls協議建立加密通訊的過程，並完成http請求的接受和響應。

具體加密通道的協商過程如下：

3.1 客戶端發出請求（ClientHello)

客戶端與服務端通過tcp三次握手建立tcp連線後，客戶端首先向伺服器發出建立加密通訊的請求，傳送ClientHello請求，從訊息體結構看，tls/ssl是基於tcp連線之上，應用層之下的協議，封裝的訊息體內容如下:

(1) 此時握手協議(handshake protocol)的訊息型別為:client hello
(2) 支援的TLS協議版本，比如TLS 1.0版。握手協議的版本為TLS 1.2
(3) 一個客戶端生成的隨機數，稍後用於生成"對話金鑰"。
(4) 支援的加密套件，如Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
(5) 支援的壓縮方法。
(6) 擴充套件屬性如：伺服器名稱（例子中為baidu.com)，支援的簽名演算法等
 2006年，TLS協議加入了一個Server Name Indication擴充套件，允許客戶端向伺服器提供它所請求的域名。

3.2 伺服器響應（SeverHello）

伺服器收到客戶端請求後，向客戶端發出響應，叫做Sever Hello。

從訊息體中，可以看到伺服器的響應包含以下內容：

(1) 確認使用的加密通訊協議版本，這裡確認使用tls1.2，而不是client hello中的tls1.1。響應握手協議訊息 server hello。如果瀏覽器與伺服器支援的版本不一致，伺服器關閉加密通訊。
(2) 一個伺服器生成的隨機數，稍後用於生成"對話金鑰"。
(3) 確認使用的加密套件,這裡為rsa+aes128+sha256
(4) 壓縮方法為空。
(5) 一些列擴充套件資訊

除了上面這些資訊，如果伺服器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供”客戶端證書”。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB金鑰，裡面就包含了一張客戶端證書。

3.3 服務端傳送服務端電子證書（CA），金鑰交換（server key exchange），及server hello done三個握手訊息

客戶端接收到server hello握手訊息後，及時反饋ack訊息。服務端接收客戶端ack訊息後，傳送服務端電子證書，金鑰交換，及server hello done三個握手訊息

從封裝內容看，包含兩層ssl協議體資訊，頭一個為服務端證書，後面跟著公共金鑰交換和hello done訊息體，具體如下：

（1）詳細的電子證書資訊和CA認證機構資訊
（2）金鑰交換資訊，包括DH演算法計算出的pubkey公鑰，電子簽名的hash演算法值
（3）server hello done訊息體

涉及到兩個問題：

(1）如何保證公鑰不被篡改？
解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。所以上面報文中就將服務端CA證書和公共金鑰交換訊息放在同一個tcp連線進行傳輸。

(2）公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和伺服器端都生成一個"對話金鑰"（session key），整個對話金鑰是通過公共金鑰和生成的3個隨機數計算得到，用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

3.4 客戶端傳送金鑰交換資訊（client key exchange）、編碼改變協議訊息(change cipher spec)

客戶端傳送ack訊息給服務端，確認收到server hello done訊息，然後傳送客戶端的金鑰交換資訊和修改金鑰的協議訊息

主要內容如下：

(1) 傳送DH演算法計算的pubkey，用於服務端計算生成解密私鑰
(2) 傳送編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
(3) 傳送加密後的握手訊息，一個隨機數。該隨機數用伺服器公鑰加密，防止被竊聽
(4) 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供伺服器校驗。（可能在加密訊息中，未確認）

客戶端收到伺服器所有響應訊息後，首先驗證伺服器證書。如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。
如果證書沒有問題，客戶端就會從證書中取出伺服器的公鑰，即server key exchange訊息中攜帶的pubkey值。然後，根據根據已經收到的三個隨機數計算書加密金鑰，對握手資訊進行加密通訊，然後向伺服器傳送上面抓包中三項資訊內容。

該步驟中的隨機數，是整個握手階段出現的第三個隨機數，又稱”pre-master key”。有了它以後，客戶端和伺服器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把”會話金鑰”。

至於為什麼一定要用三個隨機數，來生成"會話金鑰"，dog250解釋得很好：
"不管是客戶端還是伺服器，都需要隨機數，這樣生成的金鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的金鑰的隨機性。
對於RSA金鑰交換演算法來說，pre-master-key本身就是一個隨機數，再加上hello訊息中的隨機，三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為金鑰就不合適了，因此必須引入新的隨機因素。
那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的金鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"

此外，如果前一步，伺服器要求客戶端證書，客戶端會在這一步同樣也傳送證書及相關資訊。更加詳細資訊參考HTTPS與TLS

3.5 伺服器的最後迴應

伺服器收到客戶端的第三個隨機數pre-master key之後，計算生成本次會話所用的”會話金鑰”。然後，向客戶端最後傳送下面資訊。

（1）編碼改變協議，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
（2）伺服器握手結束通知，表示伺服器的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結束。接下來，客戶端與伺服器進入加密通訊，就完全是使用普通的HTTP協議，只不過用”會話金鑰”加密內容。

最後從抓包的報文我們可以看到：Http請求處理響應結束後，客戶端會發送加密的alert訊息給服務端，告知如果異常產生變化，就要發出告警。最後就是客戶和服務端傳送fin/ack tcp訊息關閉tcp連線