一、簡(jiǎn)介

SSL，全稱(chēng)Secure Socket Layer，為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全。
SSL利用數(shù)據(jù)加密、身份驗(yàn)證和消息完整性驗(yàn)證機(jī)制，為網(wǎng)絡(luò)上數(shù)據(jù)的傳輸提供安全性保證。SSL支持各種應(yīng)用層協(xié)議。由于SSL位于應(yīng)用層和傳輸層之間，所以可以為任何基于TCP等可靠連接的應(yīng)用層協(xié)議提供安全性保證。

二、SSL安全機(jī)制

1.身份驗(yàn)證機(jī)制

基于證書(shū)利用數(shù)字簽名方法對(duì)服務(wù)器和客戶(hù)端進(jìn)行身份驗(yàn)證，其中客戶(hù)端的身份驗(yàn)證是可選的。

2.數(shù)據(jù)傳輸?shù)臋C(jī)密性

利用對(duì)稱(chēng)密鑰算法對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密。

3.消息完整性驗(yàn)證

消息傳輸過(guò)程中使用MAC算法來(lái)檢驗(yàn)消息的完整性。

三、SSL實(shí)現(xiàn)原理

1.身份驗(yàn)證機(jī)制

SSL利用數(shù)字簽名來(lái)驗(yàn)證通信對(duì)端的身份。

非對(duì)稱(chēng)密鑰算法可以用來(lái)實(shí)現(xiàn)數(shù)字簽名。由于通過(guò)私鑰加密后的數(shù)據(jù)只能利用對(duì)應(yīng)的公鑰進(jìn)行解密，因此根據(jù)解密是否成功，就可以判斷發(fā)送者的身份，如同發(fā)送者對(duì)數(shù)據(jù)進(jìn)行了“簽名”。

例如，Alice使用自己的私鑰對(duì)一段固定的信息加密后發(fā)給Bob，Bob利用Alice的公鑰解密，如果解密結(jié)果與固定信息相同，那么就能夠確認(rèn)信息的發(fā)送者為Alice，這個(gè)過(guò)程就稱(chēng)為數(shù)字簽名。

使用數(shù)字簽名驗(yàn)證身份時(shí)，需要確保被驗(yàn)證者的公鑰是真實(shí)的，否則，非法用戶(hù)可能會(huì)冒充被驗(yàn)證者與驗(yàn)證者通信。如下圖所示，Cindy冒充Bob，將自己的公鑰發(fā)給Alice，并利用自己的私鑰計(jì)算出簽名發(fā)送給Alice，Alice利用“Bob”的公鑰（實(shí)際上為Cindy的公鑰）成功驗(yàn)證該簽名，則Alice認(rèn)為Bob的身份驗(yàn)證成功，而實(shí)際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機(jī)制保證公鑰的真實(shí)性。

身份驗(yàn)證.png

2.數(shù)據(jù)傳輸?shù)臋C(jī)密性

SSL加密通道上的數(shù)據(jù)加解密使用對(duì)稱(chēng)密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數(shù)據(jù)被破解。

對(duì)稱(chēng)密鑰算法要求解密密鑰和加密密鑰完全一致。因此，利用對(duì)稱(chēng)密鑰算法加密傳輸數(shù)據(jù)之前，需要在通信兩端部署相同的密鑰。

3. 消息完整性驗(yàn)證

為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改，SSL利用基于MD5或SHA的MAC算法來(lái)保證消息的完整性。

MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和任意長(zhǎng)度的數(shù)據(jù)轉(zhuǎn)換為固定長(zhǎng)度的數(shù)據(jù)。利用MAC算法驗(yàn)證消息完整性的過(guò)程如下圖所示。

發(fā)送者在密鑰的參與下，利用MAC算法計(jì)算出消息的MAC值，并將其加在消息之后發(fā)送給接收者。接收者利用同樣的密鑰和MAC算法計(jì)算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報(bào)文沒(méi)有改變；否則，報(bào)文在傳輸過(guò)程中被修改，接收者將丟棄該報(bào)文。

消息完整性驗(yàn)證.png

MAC算法要求通信雙方具有相同的密鑰，否則MAC值驗(yàn)證將會(huì)失敗。因此，利用MAC算法驗(yàn)證消息完整性之前，需要在通信兩端部署相同的密鑰。

4.利用非對(duì)稱(chēng)密鑰算法保證密鑰本身的安全

對(duì)稱(chēng)密鑰算法和MAC算法要求通信雙方具有相同的密鑰，否則解密或MAC值驗(yàn)證將失敗。因此，要建立加密通道或驗(yàn)證消息完整性，必須先在通信雙方部署一致的密鑰。

SSL利用非對(duì)稱(chēng)密鑰算法加密密鑰的方法實(shí)現(xiàn)密鑰交換，保證第三方無(wú)法獲取該密鑰。如下圖所示，SSL客戶(hù)端（如Web瀏覽器）利用SSL服務(wù)器（如Web服務(wù)器）的公鑰加密密鑰，將加密后的密鑰發(fā)送給SSL服務(wù)器，只有擁有對(duì)應(yīng)私鑰的SSL服務(wù)器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。（Server端公鑰加密密鑰，私鑰解密密鑰）

利用非對(duì)稱(chēng)密鑰算法保證密鑰本身的安全.png

實(shí)際上，SSL客戶(hù)端發(fā)送給SSL服務(wù)器的密鑰不能直接用來(lái)加密數(shù)據(jù)或計(jì)算MAC值，該密鑰是用來(lái)計(jì)算對(duì)稱(chēng)密鑰和MAC密鑰的信息，稱(chēng)為premaster secret。

SSL客戶(hù)端和SSL服務(wù)器利用premaster secret計(jì)算出相同的主密鑰（master secret），再利用master secret生成用于對(duì)稱(chēng)密鑰算法、MAC算法等的密鑰。

premaster secret是計(jì)算對(duì)稱(chēng)密鑰、MAC算法密鑰的關(guān)鍵。

5.利用PKI保證公鑰的真實(shí)性

PKI通過(guò)數(shù)字證書(shū)來(lái)發(fā)布用戶(hù)的公鑰，并提供了驗(yàn)證公鑰真實(shí)性的機(jī)制。數(shù)字證書(shū)（簡(jiǎn)稱(chēng)證書(shū)）是一個(gè)包含用戶(hù)的公鑰及其身份信息的文件，證明了用戶(hù)與公鑰的關(guān)聯(lián)。數(shù)字證書(shū)由權(quán)威機(jī)構(gòu)——CA簽發(fā)，并由CA保證數(shù)字證書(shū)的真實(shí)性。

SSL客戶(hù)端把密鑰加密傳遞給SSL服務(wù)器之前，SSL服務(wù)器需要將從CA獲取的證書(shū)發(fā)送給SSL客戶(hù)端，SSL客戶(hù)端通過(guò)PKI判斷該證書(shū)的真實(shí)性。如果該證書(shū)確實(shí)屬于SSL服務(wù)器，則利用該證書(shū)中的公鑰加密密鑰，發(fā)送給SSL服務(wù)器。
驗(yàn)證SSL服務(wù)器/SSL客戶(hù)端的身份之前，SSL服務(wù)器/SSL客戶(hù)端需要將從CA獲取的證書(shū)發(fā)送給對(duì)端，對(duì)端通過(guò)PKI判斷該證書(shū)的真實(shí)性。如果該證書(shū)確實(shí)屬于SSL服務(wù)器/SSL客戶(hù)端，則對(duì)端利用該證書(shū)中的公鑰驗(yàn)證SSL服務(wù)器/SSL客戶(hù)端的身份。

四、SSL協(xié)議基本運(yùn)行過(guò)程

1.分層結(jié)構(gòu)

SSL位于應(yīng)用層和傳輸層之間，它可以為任何基于TCP等可靠連接的應(yīng)用層協(xié)議提供安全性保證。SSL協(xié)議本身分為兩層：

• 上層為SSL握手協(xié)議（SSL handshake protocol）、SSL密碼變化協(xié)議（SSL change cipher spec protocol）和SSL警告協(xié)議（SSL alert protocol）；
• 底層為SSL記錄協(xié)議（SSL record protocol）。

SSL協(xié)議分層結(jié)構(gòu).png

其中：

• SSL握手協(xié)議：是SSL協(xié)議非常重要的組成部分，用來(lái)協(xié)商通信過(guò)程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在服務(wù)器和客戶(hù)端之間安全地交換密鑰、實(shí)現(xiàn)服務(wù)器和客戶(hù)端的身份驗(yàn)證。
• SSL密碼變化協(xié)議：客戶(hù)端和服務(wù)器端通過(guò)密碼變化協(xié)議通知對(duì)端，隨后的報(bào)文都將使用新協(xié)商的加密套件和密鑰進(jìn)行保護(hù)和傳輸。
• SSL警告協(xié)議：用來(lái)向通信對(duì)端報(bào)告告警信息，消息中包含告警的嚴(yán)重級(jí)別和描述。
• SSL記錄協(xié)議：主要負(fù)責(zé)對(duì)上層的數(shù)據(jù)（SSL握手協(xié)議、SSL密碼變化協(xié)議、SSL警告協(xié)議和應(yīng)用層協(xié)議報(bào)文）進(jìn)行分塊、計(jì)算并添加MAC值、加密，并把處理后的記錄塊傳輸給對(duì)端。

2.基本運(yùn)行過(guò)程

• 客戶(hù)端向服務(wù)器端索要并驗(yàn)證公鑰。
• 雙方協(xié)商生成"對(duì)話(huà)密鑰"。
• 雙方采用"對(duì)話(huà)密鑰"進(jìn)行加密通信。
  其中，前兩個(gè)階段，被稱(chēng)為“握手階段”。

五、握手階段詳細(xì)過(guò)程

"握手階段"涉及四次通信，該階段的所有通信都是明文的。

1.客戶(hù)端發(fā)出請(qǐng)求（ClientHello）

• 支持的協(xié)議版本，比如TLS 1.0版。
• 一個(gè)客戶(hù)端生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話(huà)密鑰"。
• 支持的加密方法，比如RSA公鑰加密。
• 支持的壓縮方法。

2.服務(wù)器回應(yīng)（SeverHello）

• 確認(rèn)使用的加密通信協(xié)議版本，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致，服務(wù)器關(guān)閉加密通信。
• 一個(gè)服務(wù)器生成的隨機(jī)數(shù)，稍后用于生成"對(duì)話(huà)密鑰"。
• 確認(rèn)使用的加密方法，比如RSA公鑰加密。
• 服務(wù)器證書(shū)。

除了上面這些信息，如果服務(wù)器需要確認(rèn)客戶(hù)端的身份，就會(huì)再包含一項(xiàng)請(qǐng)求，要求客戶(hù)端提供"客戶(hù)端證書(shū)"。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶(hù)連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶(hù)提供USB密鑰，里面就包含了一張客戶(hù)端證書(shū)。

3.客戶(hù)端回應(yīng)

客戶(hù)端收到服務(wù)器回應(yīng)以后，首先驗(yàn)證服務(wù)器證書(shū)。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致、或者證書(shū)已經(jīng)過(guò)期，就會(huì)向訪(fǎng)問(wèn)者顯示一個(gè)警告，由其選擇是否還要繼續(xù)通信。如果證書(shū)沒(méi)有問(wèn)題，客戶(hù)端就會(huì)從證書(shū)中取出服務(wù)器的公鑰。然后，向服務(wù)器發(fā)送下面三項(xiàng)信息。

• 一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽(tīng)。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
• 客戶(hù)端握手結(jié)束通知，表示客戶(hù)端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供服務(wù)器校驗(yàn)。

上面第一項(xiàng)的隨機(jī)數(shù)，是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù)，又稱(chēng)"pre-master key"。有了它以后，客戶(hù)端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù)，接著雙方就用事先商定的加密方法，各自生成本次會(huì)話(huà)所用的同一把"會(huì)話(huà)密鑰"。

4.服務(wù)器的最后回應(yīng)

服務(wù)器收到客戶(hù)端的第三個(gè)隨機(jī)數(shù)pre-master key之后，計(jì)算生成本次會(huì)話(huà)所用的"會(huì)話(huà)密鑰"。然后，向客戶(hù)端最后發(fā)送下面信息。

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
• 服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值，用來(lái)供客戶(hù)端校驗(yàn)。

至此，整個(gè)握手階段全部結(jié)束。接下來(lái)，客戶(hù)端與服務(wù)器進(jìn)入加密通信，就完全是使用普通的HTTP協(xié)議，只不過(guò)用"會(huì)話(huà)密鑰"加密內(nèi)容。

六、問(wèn)題

1.SSL/TLS協(xié)議的基本思路

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說(shuō)，客戶(hù)端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密。

2.公鑰加密計(jì)算量太大，如何減少耗用的時(shí)間？

每一次對(duì)話(huà)（session），客戶(hù)端和服務(wù)器端都生成一個(gè)"對(duì)話(huà)密鑰"（session key），用它來(lái)加密信息。由于"對(duì)話(huà)密鑰"是對(duì)稱(chēng)加密，所以運(yùn)算速度非?？欤?wù)器公鑰只用于加密"對(duì)話(huà)密鑰"本身，這樣就減少了加密運(yùn)算的消耗時(shí)間。

3.為什么一定要用三個(gè)隨機(jī)數(shù)，來(lái)生成"會(huì)話(huà)密鑰"？

"不管是客戶(hù)端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。對(duì)于RSA密鑰交換算法來(lái)說(shuō)，pre-master-key本身就是一個(gè)隨機(jī)數(shù)，再加上hello消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱(chēng)密鑰。pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么pre master secret就有可能被猜出來(lái)，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶(hù)端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。"