【網絡與系統安全】關於SSL/TSL協議的分析
前言
TSL協議的前身是由網景（Netscape）公司於1994年研發的安全套接字（Secure Socket Layer）協議。它建立在TCP協議棧的傳輸層，用於保護面向連接的TCP通信。實際TSL1.0就是SSL3.1，因此文獻中常用SSL/TSL統稱它們，下文僅用TSL。
TSL工作在TCP之上，應用層之下。而在TSL中又分為上下兩層，所以用一個簡單的示意圖描述它們在協議棧中的位置如下圖，想要更了解SSL/TSL可以查看圖解SSL/TSL：
實驗
本次實驗是在windows7下完成，采用的工具是wireshark1.8，瀏覽器為IE10。
任意選擇一個采用https協議的網站，我這裏選擇的是www.baidu.com。
開啟wireshark抓包模式，然後再瀏覽器中輸入百度的url，等待百度首頁加載完成，停止抓包，篩選器的字段為ip.addr == 61.135.169.125 && tcp
首先是我們熟悉的TCP三次握手過程，綠框圈住的部分，之前分析過TCP三次握手過程，所以就不再仔細剖析它了：
然後就是TLS協議，先從整體上看一下TSL握手的整個過程。用五顏六色框住的就是跟TSL握手過程有關的數據包（右側有標註，由於wireshark數據包本身就有顏色，所以這裏標註的顏色難免有些受影響，仔細看還是可以看清楚的）。：
大體上看下來，得出的結論就是百度采用的TSL握手協議為單向認證的握手，即只驗證服務器端，而不驗證客戶端。百度肯定希望盡可能多的用戶使用，所以肯定不會采用雙向驗證，所以推測我們常用的網站都是采用單向驗證。
接下來我們把這6個包都來分析一下：
客戶端向服務器端say hello，當三次握手完成後，緊接著客戶端就向服務器端發送ClientHello消息，該消息包括客戶端推薦的密碼算法標識、參數和一個在密鑰協商中協議需要的一個隨機數。圖中被黃顏色框住的為重要信息。其中Random和Cipher Suites沒有被框出來，壓縮算法為空。
服務器端向客戶端say hello。一方面是為了回應客戶端發來的握手請求，另一方面也攜帶了一些必要的信息，比如：某個隨機數，服務器選定的加密算法等。圖中用紅色框住的就是關於該數據包的關鍵信息。密鑰交換算法為RSA，數據加密為128位密鑰的AES算法，數據校驗算法為SHA256（下面可以看到為什麽是256）。
服務器端向客戶端發送certificate消息，該消息包含服務器的公鑰證書。
接下來就是服務器端向服務端發送的ServerHelloDone消息，表示響應完畢。有一個問題就是在這個包中還包含一個ServerKeyExchange，在單向認證過程中應該沒有這條消息的，不知道為什麽會出現，還望老師幫忙解釋。
隨後就是ClientKeyExchange和ChangeCipherSpec消息，由客戶端在收到服務器端響應後，對服務器的公鑰證書進行驗證，驗證不通過就會出現TLS警告；驗證通過後向服務器端發送。其中ChangeCipherSpec表示客戶端已經按照商定的算法改變了加密策略。這裏密鑰交換算法為DH（Diffie-Hellman），如圖中被藍色框住的部分；紅色框住的為該數據包中包含的TSL握手消息。
最後是服務器端發送給客戶端的ChangeCipherSpec，表示確認。至此整個單向驗正的TLS握手過程完成，接下來雙方開始進行加密數據傳輸連接，即以後所有的數據都被加密傳輸。
總結：
上面的過程是采用單向認證的TLS握手協議過程，所以我想找一個采用雙向握手的，雙向認證需要使用客戶端的公鑰，而我接觸到要用到自己公鑰的網站和應用就只有git（國外和國內oschina都可以），而且公鑰還是自己生成的，而且而且只有使用git等命令推送或拷貝代碼時才會驗證公鑰，鑒於限制條件比較多，所以我就沒有測試。
TLS容易遭受某些 DoS 攻擊。例如，攻擊者創建很多TCP連接，就可以讓服務器忙於做 RSA 解密計算。其實TSL協議本身就需要很長的計算時間，由於現今服務器端的升級以及網速地提高正好可以彌補這些消耗帶來的不便。任何事情的發展都符合這個規律，沒有的時候，有就是發展的目標，有了之後質量更高就會成為新的目標。比如我們國家從“站起來”到“富起來”的轉變。盡管TLS有很大的不便，但相比HTTP協議，HTTPS協議更符合當下時代的要求。
【網絡與系統安全】關於SSL/TSL協議的分析