一、實驗目的
1.訪問一個https://....的網站，捕TLS包並分析報文序列。
2.分析連接建立的完整過程，如：TCP三次握手、SSL安全連接，使用TLS協議連接、協商過程，加密傳送的狀態、TCP揮手等。
3.分析包中handshake握手、協商過程，說明完成了什么功能。
二、實驗准備
1.筆記本電腦一台，安裝wireshark軟件。
2.實驗參考了幾篇csdn博客：https://www.cnblogs.com/Anker/p/6082966.html；http://m.blog.csdn.net/liangyihuai/article/details/53098482；http://m.blog.csdn.net/ppdyhappy/article/details/68061238。
三、實驗原理
1.基本概念
（1）SSL（Secure Socket Layer，安全套接字層）
位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層。SSL通過互相認證、使用數字簽名確保完整性、使用加密確保私密性，以實現客戶端和服務器之間的安全通訊。該協議由兩層組成：SSL記錄協議和SSL握手協議。
（2）TLS(Transport Layer Security，傳輸層安全協議)
用於兩個應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS記錄協議和TLS握手協議。
（3）TLS是在SSL的基礎上標准化的產物，目前SSL3.0與TLS1.0保持一致，二者是並列關系。SSL/TLS位於傳輸層和應用層之間，應用層數據不再直接傳遞給傳輸層，而是傳遞給TLS層，TLS層對從應用層收到的數據進行加密，並增加自己的TLS頭。
2.TLS設計目標
TLS的設計目標是構建一個安全傳輸層（Transport Layer Security ），在基於連接的傳輸層（如tcp）上提供：
（1）保密性，message privacy (保密通過加密encryption實現，所有信息都加密傳輸，第三方無法竊聽 )
（2）完整性，message integrity（ 通過MAC校驗機制，一旦被篡改，通信雙方會立刻發現 ）
（3）認證， mutual authentication （雙方認證，雙方都可以配備證書，防止身份被冒充 ）
（4）互操作、通用性 （ 根據公開的rfc，任何符合rfc的軟件實現都可以互操作，不受限於任何專利技術）
（5）可擴展性 ( 通過擴展機制 tls_ext可以添加功能，有大量的新功能，都是通過擴展添加的)
（6）高效率 （通過session cache，恰當部署cache之后，tls的效率很高）
3.TLS發展歷史
1995: SSL 2.0, 由Netscape提出，這個版本由於設計缺陷，並不安全，很快被發現有嚴重漏洞，已經廢棄。
1996: SSL 3.0. 寫成RFC，開始流行。目前(2015年)已經不安全，必須禁用。
1999: TLS 1.0. 互聯網標准化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版。
2006: TLS 1.1. 作為 RFC 4346 發布。主要fix了CBC模式相關的如BEAST攻擊等漏洞。
2008: TLS 1.2. 作為RFC 5246 發布 。增進安全性。目前(2015年)應該主要部署的版本。
2015之后: TLS 1.3，還在制訂中，支持0-rtt，大幅增進安全性，砍掉了aead之外的加密方式。
由於SSL的2個版本都已經退出歷史舞台了，所以本文后面只用TLS這個名字。 一般所說的SSL就是TLS。
4.握手原理
（1）為了在握手協議解決降級攻擊的問題，TLS協議規定：client發送ClientHello消息，server必須回復ServerHello消息，否則就是fatal error，當成連接失敗處理。ClientHello和ServerHello消息用於建立client和server之間的安全增強能力，ClientHello和ServerHello消息建立如下屬性：
Protocol Version
Session ID
Cipher Suite
Compression Method
（2）另外，產生並交換兩個random值 ClientHello.random 和 ServerHello.random
（3）密鑰協商使用四條： server的Certificate，ServerKeyExchange，client的Certificate，ClientKeyExchange 。TLS規定以后如果要新增密鑰協商方法，可以訂制這4條消息的數據格式，並且指定這4條消息的使用方法。密鑰協商得出的共享密鑰必須足夠長，當前定義的密鑰協商算法生成的密鑰長度必須大於46字節。
（4）原理類似下圖（實驗步驟中會詳細介紹）
四、實驗步驟
（一）wireshark捕包
1.選擇https://www.baidu.com/網站，首先通過ping語句獲得百度ip地址61.135.169.125。
2.wireshark捕包，使用ip.src==61.135.169.125&&ssl過濾包。在瀏覽器中訪問https://www.baidu.com/，結果如下圖所示：
（二）握手過程
首先我們了解一下建立握手連接的目的：（1）身份的驗證，client與server確認對方是它相連接的，而不是第三方冒充的，通過證書實現；（2）client與server交換session key，用於連接后數據的傳輸加密和hash校驗。
其次分析簡單的SSL握手連接過程(僅Server端交換證書給client)：
1.Client發送ClientHello，指定版本，隨機數random，所有支持的密碼套件(CipherSuites)。
（1）ContentType指示SSL通信處於握手階段。除此之外，還有開始加密傳輸(ChangeCipherSpec)還是正常通信(Application)等，如圖：
（2）Version是TLS的版本1.2。其他版本見下表：
（3）Handshake Type是在handshake階段中的client hello。其它具體階段見下表：
（4）ClientHello附帶的數據隨機數據random，會在生成session key時使用(會話密鑰)。
（5）Cipher suite列出了client支持的所有加密算法組合，不同的cipher 決定了握手的交互過程。
cipher的格式為：認證算法_密鑰交換算法_加密算法_ 摘要算法。可以看出每一組包含3種算法，一個是非對稱算法，如RSA，一個是對稱算法如AES，3DES等，一個是Hash算法，如SHA等。server會從這些算法組合中選取一組，作為本次SSL連接中使用。
2.Server回應ServerHello。指定版本，random，選擇CipherSuites，會話ID(Session ID)，確認使用的加密方法（RSA公鑰加密），如圖所示：
3.Server發送Certificate。
（1）服務器發一個證書給客戶端，該證書用於向客戶端確認服務器的身份。如果配置服務器的SSL需要驗證服務器的身份，會發送該消息（多數電子商務應用都需要服務器端身份驗證。（服務器如果需要驗證客戶端的身份，那么服務器會發一個“Certificate Request”給瀏覽器，而在很多實現中，服務器一般不需要驗證客戶端的身份）。
（2）server的證書信息，只包含public key，server將該public key對應的private key保存好，用於證明server是該證書的實際擁有者，驗證原理很簡單：client隨機生成一串數，用server這里的public key加密(RSA算法)，發給server，server用private key解密后返回給client，client與原文比較，如果一致，則說明server擁有private key，也就說明與client通信的正是證書的擁有者，因為public key加密的數據，只有private key才能解密。利用這個原理，也能實現session key的交換，加密前的隨機數就可用作session key，因為除了client和server，沒有第三方能獲得該數據。但在實際使用時會復雜很多，數據經過多次hash，偽隨機等的運算，前面提到的client和server端的RN都會參與計算。
4.Server發送ServerKeyExchange。
（1）這個包告訴我們服務器和客戶端是通過Diffie-Hellman算法來生成最終的密鑰（也就是Sessionkey會話密鑰），pubkey是Diffie-Hellman算法中的一個參數，這個參數需要通過網絡傳給客戶端，即使它被截取也沒有影響安全性。
（2）此外，在網上一些資料中沒有ServerKeyExchange這個過程，在certificate后就是ServerHelloDone過程，我認為是將ServerKeyExchange包含在certificate過程中了。
5.Server發送ServerHelloDone。
6.Client發送ClientKeyExchange,change cipher spec, encrypted handshake message(Finishd)，用於與server交換session key。
（1）客戶端收到服務器發來的ServerKeyExchange包來之后，運行Diffie-Hellman算法生成一個pubkey，然后發送給服務器。通過這一步和上面ServerKeyExchange兩個步驟，服務器和客戶端分別交換了pubkey，這樣他們就可以分別生成了一個一樣的sessionkey（具體的實現過程可以參考Diffie-Hellman算法的實現）。服務器和客戶端向對方發送了pubkey之后，雙方就可以計算出相同的密鑰了，並且這個過程沒有安全問題。
（2）發送ChangeCipherSpec，指示Server從現在開始發送的消息都是加密過的。
（3）client發送的encrypted handshake message加密數據非常關鍵，一是能證明握手數據沒有被篡改過，二也能證明自己確實是密鑰的擁有者(這里是單邊驗證，只有server有certificate，server發送的Finished能證明自己含有private key，原理是一樣的)。client將之前發送的所有握手消息存入handshake message緩存。
完成上面的步驟，可以說TLS的握手階段已經完成了。但是，服務器還會發送一個Session Ticket給瀏覽器。
7.server發送Session Ticket給client。
這個sessionticket包含了這個ticket的生命周期、長度、id等等信息。sessionticket包的作用是：握手階段用來建立TLS連接。如果出於某種原因，對話中斷，就需要重新握手。客戶端只需發送一個服務器在上一次對話中發送過來的sessionticket。這個sessionticket是加密的，只有服務器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法。當服務器收到sessionticket以后，解密后就不必重新生成對話密鑰而是可以繼續使用上一次的連接。
8.server發送ChangeCipherSpec給client。
Server指示client從現在開始發送的消息都是加密過的。
9.server發送encrypted handshake message（Finishd）給client。
與client發送Finished方法一致，server發送的Finished里包含hash給client，client會進行校驗，如果通過，說明握手過程中的數據沒有被第三方篡改過，也說明server是之前交換證書的擁有者。現在雙方就可以開始后續通信，進入Application data了。
五、實驗補充
當前TLS安全問題：
2016年1月，Computer Science and Automation (INRIA)的安全研究人員在TLS 1.2協議的實現過程中發現一個新漏洞，並將該新型攻擊命名為“SLOTH”。中間人攻擊者可利用SLOTH以下列方法攻擊加密流量：解密加密的流量、冒充合法的客戶端、冒充合法的服務器。之所以稱之為SLOTH，是因為攻擊者強迫目標使用弱的哈希算法，這是首例公開的針對TLS、IKE和SSH協議的原像/碰撞攻擊。
SLOTH攻擊揭示了TLS協議的最新版本中的一些安全問題。即使在安全協議棧中禁用弱密碼套件，該攻擊仍能發生。在TLS 1.2以后的版本中，TLS協議實現中的許多響應都會刪除MD5支持。因此，在大多數情況下，更新現有的TLS棧可以有效的解決此類問題。但是，該更新操作不能僅限於TLS協議，因為SSH和VPN服務也會受到SLOTH攻擊的影響。安全人員可以檢查TLS、SSH和VPN相關的所有配置，並禁用MD5支持。同時，如果使用的是第三方通信設備，那么應該檢查當前配置和供應商更新信息。