本篇文章給大家分享的是有關(guān)如何進行SSL/TLS原理分析，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供大冶網(wǎng)站建設(shè)、大冶做網(wǎng)站、大冶網(wǎng)站設(shè)計、大冶網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、大冶企業(yè)網(wǎng)站模板建站服務(wù)，十多年大冶做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
SSL是一個介于HTTP協(xié)議與TCP之間的一個可選層，其位置大致如下:
SSL：（Secure Socket Layer，安全套接字層），為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會被截取。當(dāng)前版本為3.0。它已被廣泛地用于Web瀏覽器與服務(wù)器之間的身份認證和加密數(shù)據(jù)傳輸。
SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層： SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。
TLS：(Transport Layer Security，傳輸層安全協(xié)議)，用于兩個應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1，它是寫入了 RFC 的。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于某個可靠的傳輸協(xié)議（例如 TCP）上面。
SSL/TLS協(xié)議提供的服務(wù)主要有：
認證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；
加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊??；
維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。
版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不同，TLS的版本1.0使用的版本號為SSLv3.1。
報文鑒別碼：SSLv3.0和TLS的MAC算法及MAC計算的范圍不同。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了相似的算法，兩者差別在于SSLv3.0中，填充字節(jié)與密鑰之間采用的是連接運算，而HMAC算法采用的是異或運算。但是兩者的安全程度是相同的。
偽隨機函數(shù)：TLS使用了稱為PRF的偽隨機函數(shù)來將密鑰擴展成數(shù)據(jù)塊，是更安全的方式。
報警代碼：TLS支持幾乎所有的SSLv3.0報警代碼，而且TLS還補充定義了很多報警代碼，如解密失?。╠ecryption_failed）、記錄溢出（record_overflow）、未知CA（unknown_ca）、拒絕訪問（access_denied）等。
密文族和客戶證書：SSLv3.0和TLS存在少量差別，即TLS不支持Fortezza密鑰交換、加密算法和客戶證書。
certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時，計算的輸入有少許差別，但安全性相當(dāng)。
加密計算：TLS與SSLv3.0在計算主密值（master secret）時采用的方式不同。
填充：用戶數(shù)據(jù)加密之前需要增加的填充字節(jié)。在SSL中，填充后的數(shù)據(jù)長度要達到密文塊長度的最小整數(shù)倍。而在TLS中，填充后的數(shù)據(jù)長度可以是密文塊長度的任意整數(shù)倍（但填充的最大長度為255字節(jié)），這種方式可以防止基于對報文長度進行分析的攻擊。
TLS的主要增強內(nèi)容
TLS的主要目標(biāo)是使SSL更安全，并使協(xié)議的規(guī)范更精確和完善。TLS 在SSL v3.0 的基礎(chǔ)上，提供了以下增強內(nèi)容：
更安全的MAC算法
更嚴密的警報
“灰色區(qū)域”規(guī)范的更明確的定義
TLS對于安全性的改進
對于消息認證使用密鑰散列法：TLS 使用“消息認證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時，該代碼確保記錄不會被變更。SSLv3.0還提供鍵控消息認證，但HMAC比SSLv3.0使用的（消息認證代碼）MAC 功能更安全。
增強的偽隨機功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。
改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。
一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現(xiàn)交換的證書類型。
特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應(yīng)該發(fā)送某些警報進行記錄。
SSL協(xié)議分為兩部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用來協(xié)商密鑰，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來安全的協(xié)商出一份密鑰。 Record Protocol則定義了傳輸?shù)母袷健?/p>
由于非對稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過公鑰算法協(xié)商出一份密鑰，然后通過對稱加密來通信，當(dāng)然，為了保證數(shù)據(jù)的完整性，在加密前要先經(jīng)過HMAC的處理。
SSL缺省只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協(xié)議）。
由于客戶端(如瀏覽器)對一些加解密算法的支持程度不一樣，但是在TLS協(xié)議傳輸過程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務(wù)端，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務(wù)端。除此之外，客戶端還要產(chǎn)生一個隨機數(shù)，這個隨機數(shù)一方面需要在客戶端保存，另一方面需要傳送給服務(wù)端，客戶端的隨機數(shù)需要跟服務(wù)端產(chǎn)生的隨機數(shù)結(jié)合起來產(chǎn)生后面要講到的 Master Secret 。
綜上，在這一步，客戶端主要向服務(wù)器提供以下信息：
支持的協(xié)議版本，比如TLS 1.0版
一個客戶端生成的隨機數(shù)，稍后用于生成”對話密鑰”
支持的加密方法，比如RSA公鑰加密
支持的壓縮方法
上圖中，從Server Hello到Server Done，有些服務(wù)端的實現(xiàn)是每條單獨發(fā)送，有服務(wù)端實現(xiàn)是合并到一起發(fā)送。Sever Hello和Server Done都是只有頭沒有內(nèi)容的數(shù)據(jù)。
服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要將自己的證書發(fā)送給客戶端。這個證書是對于服務(wù)端的一種認證。例如，客戶端收到了一個來自于稱自己是www.alipay.com的數(shù)據(jù)，但是如何證明對方是合法的alipay支付寶呢？這就是證書的作用，支付寶的證書可以證明它是alipay，而不是財付通。證書是需要申請，并由專門的數(shù)字證書認證機構(gòu)(CA)通過非常嚴格的審核之后頒發(fā)的電子證書。頒發(fā)證書的同時會產(chǎn)生一個私鑰和公鑰。私鑰由服務(wù)端自己保存，不可泄漏。公鑰則是附帶在證書的信息中，可以公開的。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被串改。另外，證書還有個有效期。
在服務(wù)端向客戶端發(fā)送的證書中沒有提供足夠的信息（證書公鑰）的時候，還可以向客戶端發(fā)送一個 Server Key Exchange，
此外，對于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對客戶端進行驗證，以保證數(shù)據(jù)傳送給了安全的合法的客戶端。服務(wù)端可以向客戶端發(fā)出 Cerficate Request 消息，要求客戶端發(fā)送證書對客戶端的合法性進行驗證。比如，金融機構(gòu)往往只允許認證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
跟客戶端一樣，服務(wù)端也需要產(chǎn)生一個隨機數(shù)發(fā)送給客戶端。客戶端和服務(wù)端都需要使用這兩個隨機數(shù)來產(chǎn)生Master Secret。
最后服務(wù)端會發(fā)送一個Server Hello Done消息給客戶端，表示Server Hello消息結(jié)束了。
綜上，在這一步，服務(wù)器的回應(yīng)包含以下內(nèi)容：
確認使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信
一個服務(wù)器生成的隨機數(shù)，稍后用于生成”對話密鑰”
確認使用的加密方法，比如RSA公鑰加密
服務(wù)器證書
Client Key Exchange
如果服務(wù)端需要對客戶端進行驗證，在客戶端收到服務(wù)端的 Server Hello 消息之后，首先需要向服務(wù)端發(fā)送客戶端的證書，讓服務(wù)端來驗證客戶端的合法性。
Certificate Verify
接著，客戶端需要對服務(wù)端的證書進行檢查，如果證書不是可信機構(gòu)頒布、或者證書中的域名與實際域名不一致、或者證書已經(jīng)過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信。如果證書沒有問題，客戶端就會從服務(wù)器證書中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項信息：
一個隨機數(shù)。該隨機數(shù)用服務(wù)器公鑰加密，防止被竊聽
編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送
客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值，用來供服務(wù)器校驗
上面第一項的隨機數(shù)，是整個握手階段出現(xiàn)的第三個隨機數(shù)，它是客戶端使用一些加密算法(例如：RSA, Diffie-Hellman)產(chǎn)生一個48個字節(jié)的Key，這個Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。
ChangeCipherSpec
ChangeCipherSpec是一個獨立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。
在ChangecipherSpec傳輸完畢之后，客戶端會使用之前協(xié)商好的加密套件和Session Secret加密一段 Finish 的數(shù)據(jù)傳送給服務(wù)端，此數(shù)據(jù)是為了在正式傳輸應(yīng)用數(shù)據(jù)之前對剛剛握手建立起來的加解密通道進行驗證。
服務(wù)端在接收到客戶端傳過來的 PreMaster 加密數(shù)據(jù)之后，使用私鑰對這段加密數(shù)據(jù)進行解密，并對數(shù)據(jù)進行驗證，也會使用跟客戶端同樣的方式生成 Session Secret，一切準備好之后，會給客戶端發(fā)送一個 ChangeCipherSpec，告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài)，準備使用加密套件和 Session Secret加密數(shù)據(jù)了。之后，服務(wù)端也會使用 Session Secret 加密一段 Finish 消息發(fā)送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。
根據(jù)之前的握手信息，如果客戶端和服務(wù)端都能對Finish信息進行正常加解密且消息正確的被驗證，則說明握手通道已經(jīng)建立成功，接下來，雙方可以使用上面產(chǎn)生的Session Secret對數(shù)據(jù)進行加密傳輸了。
Secret Keys
上面的分析和講解主要是為了突出握手的過程，所以PreMaster secret，Master secret，session secret都是一代而過，但是對于Https，SSL/TLS深入的理解和掌握，這些Secret Keys是非常重要的部分。所以，準備把這些Secret Keys抽出來單獨分析和講解。
我們先來看看這些Secret Keys的生成過程以及作用流程圖：
PreMaster secret
PreMaster Secret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的。它將用來跟服務(wù)端和客戶端在Hello階段產(chǎn)生的隨機數(shù)結(jié)合在一起生成 Master Secret。在客戶端使用服務(wù)端的公鑰對PreMaster Secret進行加密之后傳送給服務(wù)端，服務(wù)端將使用私鑰進行解密得到PreMaster secret。也就是說服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機數(shù)。
PreMaster secret前兩個字節(jié)是TLS的版本號，這是一個比較重要的用來核對握手數(shù)據(jù)的版本號，因為在Client Hello階段，客戶端會發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個安全性較低的加密套件和版本給服務(wù)端，從而對數(shù)據(jù)進行破解。所以，服務(wù)端需要對密文中解密出來對的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發(fā)送任何消息。
關(guān)于PreMaster Secret(Key)的計算請參考 Https SSL/TLS PreMaster/Master Secret(Key)計算。
Master secret
上面已經(jīng)提到，由于服務(wù)端和客戶端都有一份相同的PreMaster secret和隨機數(shù)，這個隨機數(shù)將作為后面產(chǎn)生Master secret的種子，結(jié)合PreMaster secret，客戶端和服務(wù)端將計算出同樣的Master secret。
Master secret是有系列的hash值組成的，它將作為數(shù)據(jù)加解密相關(guān)的secret的 Key Material 的一部分。Key Material最終解析出來的數(shù)據(jù)如下：
其中，write MAC key，就是session secret或者說是session key。Client write MAC key是客戶端發(fā)數(shù)據(jù)的session secret，Server write MAC secret是服務(wù)端發(fā)送數(shù)據(jù)的session key。MAC(Message Authentication Code)，是一個數(shù)字簽名，用來驗證數(shù)據(jù)的完整性，可以檢測到數(shù)據(jù)是否被串改。
關(guān)于Session Secret(Key)的計算請參考 Https SSL/TLS Session Secret(Key)計算。
在所有的握手階段都完成之后，就可以開始傳送應(yīng)用數(shù)據(jù)了。應(yīng)用數(shù)據(jù)在傳輸之前，首先要附加上MAC secret，然后再對這個數(shù)據(jù)包使用write encryption key進行加密。在服務(wù)端收到密文之后，使用Client write encryption key進行解密，客戶端收到服務(wù)端的數(shù)據(jù)之后使用Server write encryption key進行解密，然后使用各自的write MAC key對數(shù)據(jù)的完整性包括是否被串改進行驗證。
SSL客戶端（也是TCP的客戶端）在TCP鏈接建立之后，發(fā)出一個ClientHello來發(fā)起握手，這個消息里面包含了自己可實現(xiàn)的算法列表和其它一些需要的消息，SSL的服務(wù)器端會回應(yīng)一個ServerHello，這里面確定了這次通信所需要的算法，然后發(fā)過去自己的證書（里面包含了身份和自己的公鑰）。Client在收到這個消息后會生成一個秘密消息，用SSL服務(wù)器的公鑰加密后傳過去，SSL服務(wù)器端用自己的私鑰解密后，會話密鑰協(xié)商成功，雙方可以用同一份會話密鑰來通信了。
如果上面的說明不夠清晰，這里我們用個形象的比喻，我們假設(shè)A與B通信，A是SSL客戶端，B是SSL服務(wù)器端，加密后的消息放在方括號[]里，以突出明文消息的區(qū)別。雙方的處理動作的說明用圓括號（）括起。
A：我想和你安全的通話，我這里的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發(fā)給A）。
目前沒有別的可說的了。
A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發(fā)出警告并斷開連接，這一步保證了B的公鑰的真實性）
（產(chǎn)生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量（IV）和hmac的密鑰。將這份秘密消息-協(xié)議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發(fā)給B）
注意，下面我就要用加密的辦法給你發(fā)消息了！
（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經(jīng)安全的協(xié)商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發(fā)消息了！
[我說完了]
A: [我的秘密是…]
B: [其它人不會聽到的…]
SecurityPortal在2000年底有一份文章《The End of SSL and SSH?》激起了很多的討論， 目前也有一些成熟的工具如dsniff（http://www.monkey.org/~dugsong/dsniff/）可以通過man in the middle攻擊來截獲https的消息。
從上面的原理可知，SSL的結(jié)構(gòu)是嚴謹?shù)?，問題一般出現(xiàn)在實際不嚴謹?shù)膽?yīng)用中。常見的攻擊就是middle in the middle攻擊，它是指在A和B通信的同時，有第三方C處于信道的中間，可以完全聽到A與B通信的消息，并可攔截，替換和添加這些消息。
SSL可以允許多種密鑰交換算法，而有些算法，如DH，沒有證書的概念，這樣A便無法驗證B的公鑰和身份的真實性，從而C可以輕易的冒充，用自己的密鑰與雙方通信，從而竊聽到別人談話的內(nèi)容。
而為了防止middle in the middle攻擊，應(yīng)該采用有證書的密鑰交換算法。
有了證書以后，如果C用自己的證書替換掉原有的證書之后，A的瀏覽器會彈出一個警告框進行警告，但又有多少人會注意這個警告呢？
由于美國密碼出口的限制，IE，netscape等瀏覽器所支持的加密強度是很弱的，如果只采用瀏覽器自帶的加密功能的話，理論上存在被破解可能。
下面探討一下SSL的代理是怎樣工作的
當(dāng)在瀏覽器里設(shè)置了https的代理，而且里輸入了https://www.example.com之后，瀏覽器會與proxy建立tcp鏈接，然后向其發(fā)出這么一段消息：
CONNECT server.example.com:443 HTTP/1.1 Host: server.example.com:443
然后proxy會向webserver端建立tcp連接,之后，這個代理便完全成了個內(nèi)容轉(zhuǎn)發(fā)裝置。瀏覽器與web server會建立一個安全通道，因此這個安全通道是端到端的，盡管所有的信息流過了proxy,但其內(nèi)容proxy是無法解密和改動的（當(dāng)然要由證書的支持，否則這個地方便是個man in the middle攻擊的好場所，見上面的安全部分）。
CA證書以及如何使用OpenSSL自簽署，見文章OpenSSL自簽署證書 。
以上就是如何進行SSL/TLS原理分析，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
