SSL協議原理SSL簡介SSL和TLSSSL(SecureSocketsLayer）安全套接層。是由Netscape公司于1990年開發(fā)，用于保障WordWideWeb（WWW）通訊的安全。主要任務是提供私密性、信息完整性和身份認證。1994年改版為SSLv2，1995年改版為SSLv3.TLS(TransportLayerSecurity）安全傳輸層協議，用于在兩個通信應用程序之間提供保密性和數據完整性。該標準協議是由IETF于1999年頒布，整體來說TLS非常類似SSLv3，只是對SSLv3做了些增加和修改。SSL協議介紹SSL是一個不依賴于平臺和運用程序的協議，位于TCP/IP協議與各種應用層協議之間，為數據通信提高安全支持。SSL加密知名協議HTTPoverSSL:簡寫https，加密網頁瀏覽是設計SSL的初衷，HTTP也是第一個使用SSL保障安全的應用層協議。?當Netscape在它的Navigator里面運用HTTPoverSSL的時候，使用https://來標識HTTPoverSSL，因此我常見的https的全稱就是HTTPoverSSL。后來HTTPS在RFC2818被標準化。HTTPS工作在443端口，而HTTP默認工作在80端口。EmailoverSSL類似于HTTPoverSSL，郵件協議例如：SMTP，POP3、IMAP也能支持SSL。SMTPoverTLS的標準文檔在RFC2487POP3和IMAPoverTLS的標準化文檔在RFC2595.SSL原理詳解SSL協議結構：圖SSL協議體系結構SSL的體系結構中包含兩個協議子層，其中底層是SSL記錄協議層（SSLRecordProtocolLayer）；高層是SSL握手協議層（SSLHandShakeProtocolLayer）。SSL協議主要分為兩層：SSL記錄協議層的作用是為高層協議提供基本的安全服務。SSL紀錄協議針對HTTP協議進行了特別的設計，使得超文本的傳輸協議HTTP能夠在SSL運行。紀錄封裝各種高層協議，具體實施壓縮解壓縮、加密解密、計算和校驗MAC等與安全有關的操作。SSL握手協議層包括SSL握手協議（SSLHandShakeProtocol）、SSL密碼參數修改協議（SSLChangeCipherSpecProtocol）和SSL告警協議（SSLAlertProtocol）。握手層的這些協議用于SSL管理信息的交換，允許應用協議傳送數據之間相互驗證，協商加密算法和生成密鑰等。SSL握手協議的作用是協調客戶和服務器的狀態(tài)，使雙方能夠達到狀態(tài)的同步。其中最重要的是記錄協議和握手協議：SSL記錄協議：它建立在可靠的傳輸（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能。SSL握手協議：它建立在SSL記錄協議之上，用于在實際的數據傳輸開始之前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。SSL建立階段與IPSec類比的話：可以分為兩個大階段：（1）SSL建立的第一階段：Handshakephase（握手階段）：協商加密算法認證服務器建立用于加密和MAC（MessageAuthenticationCode）用的密鑰該階段類似于IPSecIKE的作用。（2）SSL建立第二階段：Securedatatransferphase（安全的數據傳輸階段）：在已經建立的SSL連接里安全的傳輸數據。該階段類似于IPSecESP的作用SSL原理（SSL建立）握手協議總過程：圖：SSL建立總過程在用SSL進行通信之前，首先要使用SSL的Handshake協議在通信兩端握手，協商數據傳輸中要用到的相關安全參數（如加密算法、共享密鑰、產生密鑰所要的材料等），并對對端的身份進行驗證。SSL的建立過程總共有13個包，第一次建立至少需要9個包。SSL建立第一階段：客戶端首先發(fā)送ClientHello消息到服務端，服務端收到ClientHello消息后，再發(fā)送ServerHello消息回應客戶端。ClientHello握手第一步是客戶端向服務端發(fā)送ClientHello消息，這個消息里包含了一個客戶端生成的隨機數

Random1、客戶端支持的加密套件（SupportCiphers）和SSLVersion等信息。 圖：ClientHello報文抓包示例ClientHello中涉及到的消息具體如下：客戶端版本按優(yōu)先級列出客戶端支持的協議版本，首選客戶端希望支持的最新協議版本。客戶端隨機數Random會話ID（Sessionid）如果客戶端第一次連接到服務器，那么這個字段就會保持為空。上圖中該字段為空，說明這是第一次連接到服務器。如果該字段不為空，說明以前是與服務器有連接的，在此期間，服務器將使用SessionID映射對稱密鑰，并將SessionID存儲在客戶端瀏覽器中，為映射設置一個時間限。如果瀏覽器將來連接到同一臺服務器（在時間到期之前），它將發(fā)送SessionID，服務器將對映射的SessionID進行驗證，并使用以前用過的對稱密鑰來恢復Session，這種情況下不需要完全握手。也叫作SSL會話恢復。后面會有介紹。加密套件：客戶端會給服務器發(fā)送自己已經知道的密碼套件列表，這是由客戶按優(yōu)先級排列的，但完全由服務器來決定發(fā)送與否。TLS中使用的密碼套件有一種標準格式。上面的報文中，客戶端發(fā)送了74套加密套件。服務端會從中選出一種來作為雙方共同的加密套件。壓縮方法：為了減少帶寬，可以進行壓縮。但從成功攻擊TLS的事例中來看，其中使用壓縮時的攻擊可以捕獲到用HTTP頭發(fā)送的參數，這個攻擊可以劫持Cookie，這個漏洞我們稱為CRIME。從TLS1.3開始，協議就禁用了TLS壓縮。擴展包：其他參數（如服務器名稱，填充，支持的簽名算法等）可以作為擴展名使用。這些是客戶端問候的一部分，如果已收到客戶端問候，接下來就是服務器的確認，服務器將發(fā)送服務器問候。ServerHello收到客戶端問候之后服務器必須發(fā)送服務器問候信息，服務器會檢查指定諸如TLS版本和算法的客戶端問候的條件，如果服務器接受并支持所有條件，它將發(fā)送其證書以及其他詳細信息，否則，服務器將發(fā)送握手失敗消息。如果接受，第二步是服務端向客戶端發(fā)送ServerHello消息，這個消息會從ClientHello傳過來的SupportCiphers里確定一份加密套件，這個套件決定了后續(xù)加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數

Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+Random2），這兩個隨機數會在后續(xù)生成對稱秘鑰時用到。 圖：ServerHello報文抓包ServerHello中涉及到的具體參數：服務器版本Version：服務器會選擇客戶端支持的最新版本。服務器隨機數Random：服務器和客戶端都會生成32字節(jié)的隨機數。用來創(chuàng)建加密密鑰。加密套件：服務器會從客戶端發(fā)送的加密套件列表中選出一個加密套件。會話ID（SessionID）：服務器將約定的Session參數存儲在TLS緩存中，并生成與其對應的Sessionid。它與ServerHello一起發(fā)送到客戶端?？蛻舳丝梢詫懭爰s定的參數到此Sessionid，并給定到期時間?？蛻舳藢⒃贑lientHello中包含此id。如果客戶端在此到期時間之前再次連接到服務器，則服務器可以檢查與Sessionid對應的緩存參數，并重用它們而無需完全握手。這非常有用，因為服務器和客戶端都可以節(jié)省大量的計算成本。在涉及亞馬遜和谷歌等流量巨大的應用程序時，這種方法存在缺點。每天都有數百萬人連接到服務器，服務器必須使用Session密鑰保留所有Session參數的TLS緩存。這是一個巨大的開銷。為了解決這個問題，在擴展包里加入了SessionTickets,在這里，客戶端可以在clienthello中指定它是否支持SessionTicket。然后，服務器將創(chuàng)建一個新的會話票證(SessionTicket)，并使用只有服務器知道的經過私鑰加密的Session參數。它將存儲在客戶端上，因此所有Session數據僅存儲在客戶端計算機上，但Ticket仍然是安全的，因為該密鑰只有服務器知道。此數據可以作為名為SessionTicket的擴展包含在ClientHello中。壓縮算法：如果支持，服務器將同意客戶端的首選壓縮方法。擴展包這個階段之后，客戶端服務端知道了下列內容：SSL版本密鑰交換、信息驗證和加密算法壓縮方法有關密鑰生成的兩個隨機數。SSL建立第二階段：服務器向客戶端發(fā)送消息。圖：SSL建立第二階段報文交換示意圖服務器啟動SSL握手第2階段，是本階段所有消息的唯一發(fā)送方，客戶機是所有消息的唯一接收方。該階段分為4步：證書：服務器將數字證書和到根CA整個鏈發(fā)給客戶端，使客戶端能用服務器證書中的服務器公鑰認證服務器。服務器密鑰交換（可選）：這里視密鑰交換算法而定證書請求：服務端可能會要求客戶自身進行驗證。服務器握手完成：第二階段的結束，第三階段開始的信號Certificate消息（可選）—第一次建立必須要有證書一般情況下，除了會話恢復時不需要發(fā)送該消息，在SSL握手的全流程中，都需要包含該消息。消息包含一個X.509證書，證書中包含公鑰，發(fā)給客戶端用來驗證簽名或在密鑰交換的時候給消息加密。這一步是服務端將自己的證書下發(fā)給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過后取出證書中的公鑰。圖：服務器給客戶端發(fā)送的證書報文ServerKeyExchange（可選）根據之前在ClientHello消息中包含的CipherSuite信息，決定了密鑰交換方式（例如RSA或者DH），因此在ServerKeyExchange消息中便會包含完成密鑰交換所需的一系列參數。圖：ServerKeyExchange報文因為這里是DH算法，所以需要發(fā)送服務器使用的DH參數。RSA算法不需要這一步。在Diffie-Hellman中，客戶端無法自行計算預主密鑰;雙方都有助于計算它，因此客戶端需要從服務器獲取Diffie-Hellman公鑰。由上圖可知，此時密鑰交換也由簽名保護。CertificateRequest（可選）------可以是單向的身份認證，也可以雙向認證這一步是可選的，如果在對安全性要求高的常見可能用到。服務器用來驗證客戶端。服務器端發(fā)出CertificateRequest消息，要求客戶端發(fā)他自己的證書過來進行驗證。該消息中包含服務器端支持的證書類型（RSA、DSA、ECDSA等）和服務器端所信任的所有證書發(fā)行機構的CA列表，客戶端會用這些信息來篩選證書。ServerHelloDone該消息表示服務器已經將所有信息發(fā)送完畢，接下來等待客戶端的消息。圖；ServerHelloDone報文SSL建立第三階段：客戶端收到服務器發(fā)送的一系列消息并解析后，將本端相應的消息發(fā)送給服務器。圖：SSL建立第三階段報文交換示意圖客戶機啟動SSL握手第3階段，是本階段所有消息的唯一發(fā)送方，服務器是所有消息的唯一接收方。該階段分為3步：證書（可選）：為了對服務器證明自身，客戶要發(fā)送一個證書信息，這是可選的，在IIS中可以配置強制客戶端證書認證?？蛻魴C密鑰交換（Pre-master-secret）：這里客戶端將預備主密鑰發(fā)送給服務端，注意這里會使用服務端的公鑰進行加密。證書驗證（可選），對預備秘密和隨機數進行簽名，證明擁有（a）證書的公鑰。Certificate（可選）如果在第二階段服務器端要求發(fā)送客戶端證書，客戶端便會在該階段將自己的證書發(fā)送過去。服務器端在之前發(fā)送的CertificateRequest消息中包含了服務器端所支持的證書類型和CA列表，因此客戶端會在自己的證書中選擇滿足這兩個條件的第一個證書發(fā)送過去。若客戶端沒有證書，則發(fā)送一個no_certificate警告。ClientKeyexchange根據之前從服務器端收到的隨機數，按照不同的密鑰交換算法，算出一個pre-master，發(fā)送給服務器，服務器端收到pre-master算出mainmaster。而客戶端當然也能自己通過pre-master算出mainmaster。如此以來雙方就算出了對稱密鑰。如果是RSA算法，會生成一個48字節(jié)的隨機數，然后用server的公鑰加密后再放入報文中。如果是DH算法，這是發(fā)送的就是客戶端的DH參數，之后服務器和客戶端根據DH算法，各自計算出相同的pre-mastersecret.圖：ClinetKeyexchange報文本消息在給服務器發(fā)送的過程中，使用了服務器的公鑰加密。服務器用自己的私鑰解密后才能得到pre-masterkey.（向服務器證明自己的確持有客戶端證書私鑰。）Certificateverify（可選）只有在客戶端發(fā)送了自己證書到服務器端，這個消息才需要發(fā)送。其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值（用master_secret）進行簽名。SSL建立第四階段：完成握手協議，建立SSL連接。圖：SSL建立第四階段報文交換示意圖客戶機啟動SSL握手第4階段，使服務器結束。該階段分為4步，前2個消息來自客戶機，后2個消息來自服務器。建立起一個安全的連接，客戶端發(fā)送一個ChangeCipherSpec消息，并且把協商得到的CipherSuite拷貝到當前連接的狀態(tài)之中。然后，客戶端用新的算法、密鑰參數發(fā)送一個Finished消息，這條消息可以檢查密鑰交換和認證過程是否已經成功。其中包括一個校驗值，對客戶端整個握手過程的消息進行校驗。服務器同樣發(fā)送ChangeCipherSpec消息和Finished消息。握手過程完成，客戶端和服務器可以交換應用層數據進行通信。ChangeCipherSpec

：編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送（ChangeCipherSpec是一個獨立的協議，體現在數據包中就是一個字節(jié)的數據，用于告知服務端，客戶端已經切換到之前協商好的加密套件（CipherSuite）的狀態(tài)，準備使用之前協商好的加密套件加密數據并傳輸了）。圖：CipherSpecMessage報文是一條事件消息。ClientFinished:客戶端握手結束通知,表示客戶端的握手階段已經結束。這一項同時也是前面發(fā)送的所有內容的hash值，用來供服務器校驗（使用HMAC算法計算收到和發(fā)送的所有握手消息的摘要，然后通過RFC5246中定義的一個偽函數PRF計算出結果，加密后發(fā)送。此數據是為了在正式傳輸應用數據之前對剛剛握手建立起來的加解密通道進行驗證。）ServerFinished:服務端握手結束通知。使用私鑰解密加密的Pre-master數據，基于之前(ClientHello和ServerHello)交換的兩個明文隨機數random_C和random_S，計算得到協商密鑰:enc_key=Fuc(random_C,random_S,Pre-Master);計算之前所有接收信息的hash值，然后解密客戶端發(fā)送的encrypted_handshake_message，驗證數據和密鑰正確性;發(fā)送一個ChangeCipherSpec（告知客戶端已經切換到協商過的加密套件狀態(tài)，準備使用加密套件和SessionSecret加密數據了）服務端也會使用SessionSecret加密一段Finish消息發(fā)送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。根據之前的握手信息，如果客戶端和服務端都能對Finish信息進行正常加解密且消息正確的被驗證，則說明握手通道已經建立成功，接下來，雙方可以使用上面產生的SessionSecret對數據進行加密傳輸了。消息驗證代碼（HMAC）和TLS數據完整性：當服務器或客戶端使用主密鑰加密數據時，它還會計算明文數據的校驗和（哈希值），這個校驗和稱為消息驗證代碼（MAC）。然后在發(fā)送之前將MAC包含在加密數據中。密鑰用于從數據中生成MAC，以確保傳輸過程中攻擊者無法從數據中生成相同的MAC，故而MAC被稱為HMAC（哈希消息認證碼）。另一方面，在接收到消息時，解密器將MAC與明文分開，然后用它的密鑰計算明文的校驗和，并將其與接收到的MAC進行比較，如果匹配，那我們就可以得出結論：數據在傳輸過程中沒有被篡改。幾個重要的secretkey:PreMastersecretPreMasterSecret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的。它將用來跟服務端和客戶端在Hello階段產生的隨機數結合在一起生成MasterSecret。PreMastersecret前兩個字節(jié)是TLS的版本號，這是一個比較重要的用來核對握手數據的版本號。服務端需要對密文中解密出來對的PreMaster版本號跟之前ClientHello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發(fā)送任何消息。Mastersecret由于最后通過交換，客戶端和服務端都會有Pre-master和隨機數，這個隨機數將作為后面產生Mastersecret的種子，結合PreMastersecret，客戶端和服務端將計算出同樣的Mastersecret。為了保證信息的完整性和機密性，SSL需要有六個加密密鑰：四個密鑰和兩個IV。為了信息的可信性，客戶端需要一個密鑰（HMAC），為了加密要有一個密鑰，為了分組加密要一個IV，服務器也是如此。SSL需要的密鑰是單向的，不同于那些在其他方向的密鑰。如果在一個方向上有攻擊，這種攻擊在其他方向是沒影響的。生成過程如下：

主密鑰是由一系列的Hash值組成。master_secret=PRF（pre_master_secret，“mastersecret”，ClientHello.random+ServerHello.random）[0..47];1根據要求，有4個密鑰用于加密和驗證每個消息的完整性，他們是：客戶端寫入加密密鑰：客戶端用來加密數據，服務器用來解密數據。服務器寫入加密密鑰：服務器用來加密數據，客戶端用來解密數據?？蛻舳藢懭隡AC密鑰：客戶端用來創(chuàng)建MAC，服務器用來驗證MAC。服務器寫入MAC密鑰：服務器用來創(chuàng)建MAC，客戶端用來驗證MAC。SSL會話恢復：會話恢復是指只要客戶端和服務器已經通信過一次，它們就可以通過會話恢復的方式來跳過整個握手階段二直接進行數據傳輸。圖：SSL會話恢復過程SSL采用會話恢復的方式來減少SSL握手過程中造成的巨大開銷。為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗(具體分析在后文)，TLS協議有兩類會話緩存機制：會話標識sessionID:由服務器端支持，協議中的標準字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，Nginx中1M內存約可以保存4000個sessionID機器相關信息，占用服務器資源較多;會話記錄sessionticket:t需要服務器和客戶端都支持，屬于一個擴展字段，支持范圍約60%(無可靠統(tǒng)計與來源)，將協商的通信信息加密之后發(fā)送給客戶端保存，密鑰只有服務器知道，占用服務器資源很少。二者對比，主要是保存協商信息的位置與方式不同，類似與http中的session與cookie。二者都存在的情況下，(nginx實現)優(yōu)先使用session_ticket。會話恢復具體過程（SessionID機制）：如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功后返回sessionID，并保存對應的通信參數在服務器中;如果客戶端再次需要和該服務器建立連接，則在client_hello中sessionID中攜帶記錄的信息，發(fā)送給服務器;服務器根據收到的sessionID檢索緩存記錄，如果沒有檢索到貨緩存過期，則按照正常的握手過程進行;如果檢索到對應的緩存記錄，則返回change_cipher_spec與encrypted_handshake_message信息，兩個信息作用類似，encrypted_handshake_message是到當前的通信參數與master_secret的hash值;如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發(fā)送change_cipher_spec與encrypted_handshake