一、什么是SSL/TLS
SSL: (安全套接字層), 位於可靠的面向連接的網絡層協議和應用層協議之間的一種協議層. SSL通過互聯網互相認證、使用數字簽名確保
完整性、使用加密確保私密性,以實現客戶端和服務器之間的安全通訊. 該協議由兩層組成: SLL記錄協議和SSL握手協議.
TLS: (傳輸層安全協議), 用於兩個應用程序之間提供保密性和數據完整性. 該協議由兩層組成: TLS記錄協議和TLS握手協議.
SSL是TLS的前身, SSL 1.0沒有對外發布, SSL 2.0由於漏洞原因, 緊接着發布了SSL 3.0.
1999年基於SSL 3.0版本, 發布了TLS 1.0版本(雖然TLS 1.0在SSL 3.0基礎上的改動不太大,但是這些改動都是非常重要的).
目前TLS的版本為:TLS 1.0(1999年)、TLS 1.1(2006年)、TLS 1.2(2008年)、TLS 1.3(2018年).
目前TLS 1.3還尚不成熟. SSL 2.0和SSL 3.0分別在2011年和2015年被棄用.而TLS 1.0和TLS 1.1也被證明極不安全.
二、TLS1.0和TLS1.1協議版本為什么要廢棄
時間上, TLS 1.0協議已經有20年歷史了, 確實要退出歷史舞台.
目前TLS協議主流的版本是 TLS v1.2, 和TLS 1.0和TLS 1.1版本相比, 有一定優勢:
1、性能: TLS 1.2有更快的密碼學算法, 比如支持AEAD類的加密模式. 當然更重要的是安全性. TLS 1.0是SSL 3.0的一個簡單升級, TLS 1.1在安全性方面又了
很大的提升, 並且引入了TLS擴展, 這是非常重要的改革; TLS 1.2版本是比較大的一個改造, 加強了密碼套件的擴展性.
安全是相對的, 理論上TLS 1.0和TLS 1.1協議是安全的, 即使歷史上出現一些安全問題, 也已經被TLS實現(OpenSSL)或客戶端(比如瀏覽器)修復了, 但是在某種
程度上這二個版本仍然有安全風險, 主要原因在於某些密碼算法已經被認為是不安全了(比如SHA1, RC4算法).
從安全性角度看V1.0和v 1.1版本確實可以宣告死亡了, 但依然存活的原因是兼容性問題, 很多社保(比如XP/IE8)不支持現代化的密碼算法(比如GCM) ,所以HTTPS
服務器部署者不能強制使用V1.2版本, 這是在用戶體驗和安全性上的一個折中.
大部分瀏覽器使用V1.2版本連接我的網站, 為了兼容老設備, 服務器同時也支持V1.0和V1.1, 由於安全性,只要服務器存在該版本, 攻擊者就會強制降級到老版本,從而
帶來安全風險.
2、另外一個原因如果想支持HTTP/2協議, 必須構建於TLS 1.2協議, 它不支持TLS 1.0和TLS 1.1版本.
三、SSL/TLS協議介紹
SSL/TLS協議僅保障傳輸層安全. 同時, 由於協議自身特性(數字證書機制), SSL/TLS不能被用於保護多跳(multi-hop)端到端通信, 而只能保護點到點通信.
SSL/TLS協議能夠提供的安全目標主要包括:
(1) 認證性 ----- 借助數字證書認證服務器和客戶端身份, 防止身份偽造.
(2)機密性 ----- 借助加密防止第三方竊聽.
(3)完整性 ----- 借助消息認證碼(MAC)保障數據完整性, 防止消息篡改
(4)重放保護---- 通過使用隱式序列號防止重放攻擊
為了實現這些安全目標, SSL/TLS協議被設計為一個兩階段協議, 分為握手階段和應用階段.
握手階段: (也稱為協商階段), 在這一階段, 客戶端和服務器端會認證對方身份(依賴於PKI體系, 利用數字證書進行身份認證), 並協商
通信中使用的安全參數、密碼套件以及MasterSecret. 后續通信使用的所有密鑰都是通過MasterScecret生成.
握手階段完成后, 進入應用階段. 在應用階段通信雙方使用握手階段協商好的密鑰進行安全通信.
SSL/TLS協議有一個高度模塊化架構, 分為很多子協議:
Handshake協議: 包括協商安全參數和密碼套件、服務器身份認證(客戶端認證可選) 、密鑰交換;
ChangeCipherSpec協議: 一條消息表面握手協議已經完成.
Alert協議: 對握手協議中一些異常的錯誤提醒, 分為fatal和warning兩個級別, fatal類型的錯誤會直接中斷SSL連接, 而warning級別的錯誤SSL鏈接仍可
繼續, 只會給出錯誤警告.
Record協議: 包括對消息的分段、壓縮、消息認證和完整性保護、加密等.
四、SSL/TLS協議流程詳解
如下圖是典型的TLS 1.0協議交互流程:
(1) Client Hello: 客戶端向服務端打招呼, 攜帶各種信息(支持的密碼套件種類、最高SSL/TLS協議版本以及壓縮算法、隨機數)提供服務端選擇.
(2) Server Hello: 服務端回應客戶客戶端的招呼信息; 服務器從客戶端在ClientHello中提供的密碼套件、SSL/TLS版本、壓縮算法列表里選擇它所支持
的項,並把選擇告知客戶端. 另外ServerHello也包含一個隨機數.
(3) Certificate: 客戶端和服務器都可以發送證書來證明自己的身份, 但是通常客戶端不被使用. 服務端向客戶端發送自己的數字證書(此證書包含服務端的公鑰),
以實現客戶端驗證身份;
SSL中使用的證書通常是X.509類型證書, X.509證書內容, 如圖所示:
在用X.509證書包含Version 1和Version 3兩種版本, 其中V1版本的證書存在安全隱患, 同時不支持TLS擴展, 被逐漸棄用. 現在大多數在用是V3版本.
同時證書會附帶與協商好的密鑰交換算法對應的密鑰. 密鑰交換算法以及他們所要求的密鑰類型如下表所示:z
(4) Server Key Exchange: 服務端向客戶端發送基於選擇的加密套件生成的公鑰( 此公鑰是經過私鑰簽名認證的); 該消息僅當以下密鑰交換算法被使用時
由服務器發出:
RSA_EXPORT(僅當服務器公鑰大於512bit時)、DHE_DSS、DHE_DSS_EXPORT、DHE_RSA、DHE_RSA_EXPORT、DH_anon. 使用其他密鑰交換算法時,
服務器不能發送消息.
ServerKeyExchange消息會攜帶這些密鑰交換算法所需要的額外參數, 以在后續步驟中協商PreMasterSecret. 這些參數需要被簽過名.
(5) Server Hello Done: 服務端向客戶端表示響應結束.
(6) Client Key Exchange: 客戶端向服務端發送經過公鑰加密的Pre-Master.
如果選擇的密鑰交換算法是RSA，那么消息包含的參數為用服務器RSA公鑰(包含在之前證書中的或者是ServerKeyExchange中的)加密過的PreMasterSecret，
它有48個字節，前2個字節表示客戶端支持的最高協議版本，后46個字節是隨機選擇的。
如果選擇的密鑰交換算法是DH或者DHE，則可能有兩種情況：
隱式DH公開值：包含在Certificate消息里;
顯示DH公開值：公開值是本消息的一部分.
(7) CertificateVerify: 這條消息用來證明客戶端擁有之前提交的客戶端證書的私鑰.
(8) Finished: 基於協商生成的密鑰, 加密握手信息讓服務端/客戶端進行認證, 雙方認證無誤開始通信; 這是一條用協商的算法和密鑰保護的消息.
同時Finished消息包含一個verify_data域, 可以用來校驗之前發送和接收的信息.
Verify_data域是一個PRF函數的輸出, 這個偽隨機函數的輸入為: 1、兩個hash值: 一個SHA-1, 一個MD5, 對之前握手過程中交換的所有消息做
哈希 ; 2、the MasterSecret, 由預備主密鑰生成; 3、finished_label, 如果客戶端發送的則是“client finished", 服務器發送的則是“server fininshed",
此外finished消息不能夠在ChangeCipherSpec前發送.
五：從SSL到TLS
本節介紹SSL/TLS協議的版本變遷，不同版本的區別以及安全特性等。
SSL 1.0由於從來沒有被公開過，並且存在嚴重安全漏洞，我們就不討論了。
SSL 2.0：SSL 2.0於1995年4月被發布。SSL 2.0中主要存在的問題如下：
MAC不能覆蓋填充長度域，攻擊者可能利用這點破壞消息完整性;
缺乏握手認證，攻擊者可以篡改密碼套件列表，誘騙通信雙方使用較弱的密碼套件;
使用較弱的或有問題的密碼算法(如MD5，RC4等)，或者使用不安全的分組模式(如CBC模式);
對於不同的密碼學基元使用相同的密鑰，違背基本安全常識。
由於以上安全問題，RFC 6176已經明確提出避免使用SSL 2.0，但是現實生活中還有少量客戶端和服務器支持SSL 2.0.
SSL 3.0：SSL 3.0引入了一些新的特性和機制解決了很多之前版本存在的漏洞。此外，SSL 3.0中引入了ChangeCipherSpec子協議。SSL 3.0向后兼容SSL 2.0，相對於SSL 2.0，它的主要改變包括以下幾點：
支持更多的密碼套件(支持更多的密碼算法如DSS，SHA-1)
在握手階段支持密鑰協商(DH和FORTEZZA)
支持密碼學參數的重協商
增加了消息壓縮選項
MAC能夠覆蓋填充長度域了，同時MAC可以使用MD5或者SHA-1
不同的密碼學基元使用不同的key
Alert子協議能對任何錯誤給出兩種提示：Warning和Fatal
中止鏈接的時候會用一個close_notify警告通知通信雙方
支持證書鏈，而非單個證書
通過Finished消息認證所有發送和接收的消息
加密了的PreMasterSecret包含當前使用的協議版本，防止協議回滾
TLS 1.0：TLS 1.0和SSL 3.0差別非常小。實際上，TLS 1.0是SSL 3.1，在IETF接手后改名為TLS。TLS 1.0版本是目前使用最廣泛的SSL/TLS協議版本。
TLS 1.0不再支持使用FORTEZZA的密碼套件。
TLS 1.0中MAC被替換成HMAC。
之前提到ChangeCipherSpec消息必須在Finished消息前發送，在TLS 1.0中，如果消息序列不符合這個要求，會產生FATAL警告並終止鏈接。
TLS 1.1：這個版本相比之前改動也很小。最重要的改動是預防了針對CBC分組模式的一些攻擊。現在的填充錯誤變的和非法MAC錯誤不可區分了，防止攻擊者利用可區分錯誤
響應建立解密預言機對密文進行攻擊。
在每次加密過程中，使用CBC分組模式時，都需要顯示給出IV，而不用再密鑰生成時使用PRF生成IV。
此外，TLS 1.1禁止為適應之前出口限制而使用弱化的密碼套件。
TLS 1.2：這是最新的版本，部署的還比較少。這個版本禁用了PRF中的MD5和SHA-1，而用一個可配置的hash函數取代了它們，這樣的修改簡化了計算過程。修改后的PRF風格如下：
此外，TLS 1.2的一個重要變化是支持認證加密模式(支持GCM等)。但是由於一些AEAD(Authenticated Encryption with Associated Data)密碼算法要求IV為隱式的，所以IV又恢復到由MasterSecret生成，即TLS 1.0以前的風格。
TLS 1.2支持使用GCM、CCM的新密碼套件。
同時SSL 2.0被宣布放棄，不再向后兼容SSL 2.0.
六、SSL/TLS流行實現庫
常見的SSL/TLS實現:
OpenSSL: 這是非常流行的開源SSL/TLS實現.
OpenSSLim完全用C語言實現, 支持SSL 2.0/3.0, TLS 1.0/1.1/1.2以及DTLS 1.0
OpenSSL近年來出現了很多的安全漏洞. 比如2014年的Heartbleed漏洞.
OpenSSL包括三方面組件: (1)openssl :多用途的命令行工具包 (2)libcrypto: 加密算法庫, 包括openssl-libs (3)libssl: 加密算法實現模塊庫, 包括nss
JSSE : 這是用java實現的, 支持SSL 3.0, TLS1.0, TLS1.1, TLS 1.2
Bouncy Castle：它不僅僅支持SSL/TLS，它是一個完整的密碼學庫，支持各種密碼學算法和協議。不過它僅僅支持TLS 1.0版本。安卓平台主要使用這個密碼庫.
GnuTLS：這是另一個用C語言實現的庫，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0。主要在Unix世界被使用。同時以各種安全漏洞多而聞名。
其他還有一些常用的SSL實現庫, 如cryptlib、CyaSSL、MatrixSSL、PolarSSL等. 市場占用率不高.