原文：https://www.cnblogs.com/bhlsheji/p/4586597.html
本文介紹了SSL后臺、安全機制、工作過程和典型網(wǎng)絡(luò)應(yīng)用铸敏。
縮略語：
1 概述
1.1 產(chǎn)生背景
基于萬維網(wǎng)的電子商務(wù)和網(wǎng)上銀行等新興應(yīng)用闰蛔，極大地方便了人們的日常生活。受到人們的青睞香到。
因為這些應(yīng)用都須要在網(wǎng)絡(luò)上進行在線交易鱼冀，它們對網(wǎng)絡(luò)通信的安全性提出了更高的要求。傳統(tǒng)的萬維網(wǎng)協(xié)議HTTP不具備安全機制——採用明文的形式數(shù)據(jù)傳輸悠就、不能驗證通信兩方的身份千绪、無法防止傳輸?shù)臄?shù)據(jù)被篡改等，導(dǎo)致HTTP無法滿足電子商務(wù)和網(wǎng)上銀行等應(yīng)用的安全性要求梗脾。
Netscape公司提出的安全協(xié)議SSL荸型，利用數(shù)據(jù)加密、身份驗證和消息完整性驗證機制藐唠，為網(wǎng)絡(luò)上數(shù)據(jù)的傳輸提供安全性保證帆疟。SSL能夠為HTTP提供安全連接，從而非常大程度上改善了萬維網(wǎng)的安全性問題宇立。
1.2 技術(shù)長處
SSL具有例如以下長處：
提供較高的安全性保證踪宠。
SSL利用數(shù)據(jù)加密、身份驗證和消息完整性驗證機制妈嘹。保證網(wǎng)絡(luò)上傳輸數(shù)據(jù)的安全性柳琢。支持各種應(yīng)用層協(xié)議。
盡管SSL設(shè)計的初衷是為了解決萬維網(wǎng)安全性問題润脸，可是因為SSL位于應(yīng)用層和傳輸層之間柬脸。它能夠為不論什么基于TCP等可靠連接的應(yīng)用層協(xié)議提供安全性保證。部署簡單毙驯。
眼下SSL已經(jīng)成為網(wǎng)絡(luò)中用來鑒別站點和網(wǎng)頁瀏覽者身份倒堕，在瀏覽器使用者及Webserver之間進行加密通信的全球化標(biāo)準(zhǔn)。SSL協(xié)議已被集成到大部分的瀏覽器中爆价，如IE垦巴、Netscape、Firefox等铭段。這就意味著差點兒隨意一臺裝有瀏覽器的計算機都支持SSL連接骤宣。不須要安裝額外的client軟件。
2 協(xié)議安全機制
SSL協(xié)議實現(xiàn)的安全機制包含：
- 傳輸數(shù)據(jù)的機密性：利用對稱密鑰算法對傳輸?shù)臄?shù)據(jù)進行加密序愚。
- 身份驗證機制：基于證書利用數(shù)字簽名方法對server和client進行身份驗證憔披，當(dāng)中client的身份驗證是可選的。
- 消息完整性驗證：消息傳輸過程中使用MAC算法來檢驗消息的完整性。
2.1 傳輸數(shù)據(jù)的機密性
網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)非常easy被非法用戶竊取芬膝，SSL採用在通信兩方之間建立加密通道的方法保證傳輸數(shù)據(jù)的機密性望门。
所謂加密通道，是指發(fā)送方在發(fā)送數(shù)據(jù)前蔗候，使用加密算法和加密密鑰對數(shù)據(jù)進行加密怒允，然后將數(shù)據(jù)發(fā)送給對方。接收方接收到數(shù)據(jù)后锈遥，利用解密算法和解密密鑰從密文中獲取明文纫事。沒有解密密鑰的第三方，無法將密文恢復(fù)為明文所灸，從而保證傳輸數(shù)據(jù)的機密性丽惶。
加解密算法分為兩類：
- 對稱密鑰算法：數(shù)據(jù)加密和解密時使用同樣的密鑰。
- 非對稱密鑰算法：數(shù)據(jù)加密和解密時使用不同的密鑰爬立，一個是公開的公鑰钾唬，一個是由用戶秘密保存的私鑰。
利用公鑰（或私鑰）加密的數(shù)據(jù)僅僅能用對應(yīng)的私鑰（或公鑰）才干解密侠驯。
與非對稱密鑰算法相比抡秆。對稱密鑰算法具有計算速度快的長處，通經(jīng)常使用于對大量信息進行加密（如對全部報文加密）吟策；而非對稱密鑰算法儒士，一般用于數(shù)字簽名和對較少的信息進行加密。
SSL加密通道上的數(shù)據(jù)加解密使用對稱密鑰算法檩坚。眼下主要支持的算法有DES着撩、3DES、AES等匾委，這些算法都能夠有效地防止交互數(shù)據(jù)被竊聽拖叙。
對稱密鑰算法要求解密密鑰和加密密鑰全然一致。因此赂乐，利用對稱密鑰算法加密數(shù)據(jù)傳輸之前薯鳍。須要在通信兩端部署同樣的密鑰。對稱密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”挨措。
2.2 身份驗證機制
電子商務(wù)和網(wǎng)上銀行等應(yīng)用中必須保證要登錄的Webserver是真實的辐啄，以免重要信息被非法竊取。SSL利用數(shù)字簽名來驗證通信對端的身份运嗜。
非對稱密鑰算法能夠用來實現(xiàn)數(shù)字簽名。因為通過私鑰加密后的數(shù)據(jù)僅僅能利用相應(yīng)的公鑰進行解密悯舟，因此依據(jù)解密是否成功担租，就能夠推斷發(fā)送者的身份。如同發(fā)送者對數(shù)據(jù)進行了“簽名”抵怎。比如奋救。Alice使用自己的私鑰對一段固定的信息加密后發(fā)給Bob岭参，Bob利用Alice的公鑰解密，假設(shè)解密結(jié)果與固定信息同樣尝艘。那么就能夠確認(rèn)信息的發(fā)送者為Alice演侯，這個過程就稱為數(shù)字簽名。
SSLclient必須驗證SSLserver的身份背亥，SSLserver是否驗證SSLclient的身份秒际。則由SSLserver決定。SSLclient和SSLserver的身份驗證過程狡汉。請參見“3.2 SSL握手過程”娄徊。
使用數(shù)字簽名驗證身份時。須要確保被驗證者的公鑰是真實的盾戴，否則寄锐。非法用戶可能會冒充被驗證者與驗證者通信。如圖1所看到的尖啡。Cindy冒充Bob橄仆，將自己的公鑰發(fā)給Alice，并利用自己的私鑰計算出簽名發(fā)送給Alice衅斩，Alice利用“Bob”的公鑰（實際上為Cindy的公鑰）成功驗證該簽名盆顾，則Alice覺得Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy矛渴。SSL利用PKI提供的機制保證公鑰的真實性椎扬，具體介紹請參見“2.5 利用PKI保證公鑰的真實性”。
2.3 消息完整性驗證
為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改具温，SSL利用基于MD5或SHA的MAC算法來保證消息的完整性蚕涤。
MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和隨意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)铣猩。利用MAC算法驗證消息完整性的過程如圖2所看到的揖铜。
發(fā)送者在密鑰的參與下，利用MAC算法計算出消息的MAC值达皿。并將其加在消息之后發(fā)送給接收者天吓。接收者利用相同的密鑰和MAC算法計算出消息的MAC值。并與接收到的MAC值比較峦椰。假設(shè)二者相同龄寞。則報文沒有改變；否則汤功，報文在傳輸過程中被改動物邑，接收者將丟棄該報文。
MAC算法具有例如以下特征，使其可以用來驗證消息的完整性：
消息的不論什么改變色解，都會引起輸出的固定長度數(shù)據(jù)產(chǎn)生變化茂嗓。通過比較MAC值，可以保證接收者可以發(fā)現(xiàn)消息的改變科阎。
MAC算法須要密鑰的參與述吸。因此沒有密鑰的非法用戶在改變消息的內(nèi)容后，無法加入正確的MAC值锣笨。從而保證非法用戶無法任意改動消息內(nèi)容蝌矛。
MAC算法要求通信兩方具有同樣的密鑰，否則MAC值驗證將會失敗票唆。因此朴读，利用MAC算法驗證消息完整性之前，須要在通信兩端部署同樣的密鑰走趋。MAC密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”衅金。
2.4 利用非對稱密鑰算法保證密鑰本身的安全
對稱密鑰算法和MAC算法要求通信兩方具有同樣的密鑰。否則解密或MAC值驗證將失敗簿煌。因此氮唯。要建立加密通道或驗證消息完整性，必須先在通信兩方部署一致的密鑰姨伟。
SSL利用非對稱密鑰算法加密密鑰的方法實現(xiàn)密鑰交換惩琉，保證第三方無法獲取該密鑰。如圖3所看到的夺荒，SSLclient（如Web瀏覽器）利用SSLserver（如Webserver）的公鑰加密密鑰瞒渠，將加密后的密鑰發(fā)送給SSLserver。僅僅有擁有相應(yīng)私鑰的SSLserver才干從密文中獲取原始的密鑰技扼。SSL通常採用RSA算法加密傳輸密鑰伍玖。
說明
- 實際上，SSLclient發(fā)送給SSLserver的密鑰不能直接用來加密數(shù)據(jù)或計算MAC值剿吻。該密鑰是用來計算對稱密鑰和MAC密鑰的信息窍箍，稱為premaster secret。SSLclient和SSLserver利用premaster secret計算出同樣的主密鑰（master secret）丽旅。再利用master secret生成用于對稱密鑰算法椰棘、MAC算法等的密鑰。
premaster secret是計算對稱密鑰榄笙、MAC算法密鑰的關(guān)鍵邪狞。
- 用來實現(xiàn)密鑰交換的算法稱為密鑰交換算法。非對稱密鑰算法RSA用于密鑰交換時茅撞，也能夠稱之為密鑰交換算法帆卓。
利用非對稱密鑰算法加密密鑰之前杆逗，發(fā)送者須要獲取接收者的公鑰，并保證該公鑰確實屬于接收者鳞疲。否則。密鑰可能會被非法用戶竊取蠕蚜。如圖1所看到的尚洽。Cindy冒充Bob，將自己的公鑰發(fā)給Alice靶累。Alice利用Cindy的公鑰加密發(fā)送給Bob的數(shù)據(jù)腺毫。Bob因為沒有相應(yīng)的私鑰無法解密該數(shù)據(jù)，而Cindy截取數(shù)據(jù)后挣柬，能夠利用自己的私鑰解密該數(shù)據(jù)潮酒。SSL利用PKI提供的機制保證公鑰的真實性，具體介紹請參見“2.5 利用PKI保證公鑰的真實性”邪蛔。
2.5 利用PKI保證公鑰的真實性
PKI通過數(shù)字證書來公布用戶的公鑰急黎，并提供了驗證公鑰真實性的機制。數(shù)字證書（簡稱證書）是一個包括用戶的公鑰及其身份信息的文件侧到，證明了用戶與公鑰的關(guān)聯(lián)勃教。
數(shù)字證書由權(quán)威機構(gòu)——CA簽發(fā)，并由CA保證數(shù)字證書的真實性匠抗。
SSLclient把密鑰加密傳遞給SSLserver之前故源，SSLserver須要將從CA獲取的證書發(fā)送給SSLclient，SSLclient通過PKI推斷該證書的真實性汞贸。假設(shè)該證書確實屬于SSLserver绳军，則利用該證書中的公鑰加密密鑰，發(fā)送給SSLserver矢腻。
驗證SSLserver/SSLclient的身份之前门驾，SSLserver/SSLclient須要將從CA獲取的證書發(fā)送給對端。對端通過PKI推斷該證書的真實性踏堡。
假設(shè)該證書確實屬于SSLserver/SSLclient猎唁，則對端利用該證書中的公鑰驗證SSLserver/SSLclient的身份。
3 協(xié)議工作過程
3.1 SSL的分層結(jié)構(gòu)
如圖4所看到的顷蟆，SSL位于應(yīng)用層和傳輸層之間诫隅，它能夠為不論什么基于TCP等可靠連接的應(yīng)用層協(xié)議提供安全性保證。SSL協(xié)議本身分為兩層：
上層為SSL握手協(xié)議（SSL handshake protocol）帐偎、SSLpassword變化協(xié)議（SSL change cipher spec protocol）和SSL警告協(xié)議（SSL alert protocol）逐纬。
底層為SSL記錄協(xié)議（SSL record protocol）。
當(dāng)中：
SSL握手協(xié)議：是SSL協(xié)議很重要的組成部分削樊。用來協(xié)商通信過程中使用的加密套件（加密算法豁生、密鑰交換算法和MAC算法等）兔毒、在server和client之間安全地交換密鑰、實現(xiàn)server和client的身份驗證甸箱。
SSLpassword變化協(xié)議：client和server端通過password變化協(xié)議通知對端育叁。隨后的報文都將使用新協(xié)商的加密套件和密鑰進行保護和傳輸。
SSL警告協(xié)議：用來向通信對端報告告警信息芍殖，消息中包括告警的嚴(yán)重級別和描寫敘述豪嗽。
SSL記錄協(xié)議：主要負(fù)責(zé)對上層的數(shù)據(jù)（SSL握手協(xié)議、SSLpassword變化協(xié)議豌骏、SSL警告協(xié)議和應(yīng)用層協(xié)議報文）進行分塊龟梦、計算并加入MAC值、加密窃躲。并把處理后的記錄塊傳輸給對端计贰。
3.2 SSL握手過程
SSL通過握手過程在client和server之間協(xié)商會話參數(shù)，并建立會話蒂窒。會話包括的主要參數(shù)有會話ID躁倒、對方的證書、加密套件（密鑰交換算法刘绣、數(shù)據(jù)加密算法和MAC算法等）以及主密鑰（master secret）樱溉。通過SSL會話傳輸?shù)臄?shù)據(jù)，都將採用該會話的主密鑰和加密套件進行加密纬凤、計算MAC等處理福贞。
不同情況下，SSL握手過程存在差異停士。
以下將分別描寫敘述以下三種情況下的握手過程：
僅僅驗證server的SSL握手過程
驗證server和client的SSL握手過程
恢復(fù)原有會話的SSL握手過程
3.2.1 僅僅驗證server的SSL握手過程
如圖5所看到的挖帘，僅僅須要驗證SSLserver身份，不須要驗證SSLclient身份時恋技，SSL的握手過程為：
(1) SSLclient通過Client Hello消息將它支持的SSL版本號拇舀、加密算法、密鑰交換算法蜻底、MAC算法等信息發(fā)送給SSLserver骄崩。
(2) SSLserver確定本次通信採用的SSL版本號和加密套件，并通過Server Hello消息通知給SSLclient薄辅。假設(shè)SSLserver同意SSLclient在以后的通信中重用本次會話要拂，則SSLserver會為本次會話分配會話ID。并通過Server Hello消息發(fā)送給SSLclient站楚。
(3) SSLserver將攜帶自己公鑰信息的數(shù)字證書通過Certificate消息發(fā)送給SSLclient脱惰。
(4) SSLserver發(fā)送Server Hello Done消息。通知SSLclient版本號和加密套件協(xié)商結(jié)束窿春。開始進行密鑰交換拉一。
(5) SSLclient驗證SSLserver的證書合法后采盒，利用證書中的公鑰加密SSLclient隨機生成的premaster secret，并通過Client Key Exchange消息發(fā)送給SSLserver蔚润。
(6) SSLclient發(fā)送Change Cipher Spec消息磅氨，通知SSLserver興許報文將採用協(xié)商好的密鑰和加密套件進行加密和MAC計算。
(7) SSLclient計算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值嫡纠，利用協(xié)商好的密鑰和加密套件處理Hash值（計算并加入MAC值悍赢、加密等），并通過Finished消息發(fā)送給SSLserver货徙。SSLserver利用相同的方法計算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較皮胡，假設(shè)二者相同痴颊，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功屡贺。
(8) 相同地蠢棱。SSLserver發(fā)送Change Cipher Spec消息，通知SSLclient興許報文將採用協(xié)商好的密鑰和加密套件進行加密和MAC計算甩栈。
(9) SSLserver計算已交互的握手消息的Hash值泻仙，利用協(xié)商好的密鑰和加密套件處理Hash值（計算并加入MAC值、加密等）量没，并通過Finished消息發(fā)送給SSLclient玉转。SSLclient利用相同的方法計算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較殴蹄，假設(shè)二者相同究抓。且MAC值驗證成功。則證明密鑰和加密套件協(xié)商成功袭灯。
SSLclient接收到SSLserver發(fā)送的Finished消息后刺下。假設(shè)解密成功，則能夠推斷SSLserver是數(shù)字證書的擁有者稽荧，即SSLserver身份驗證成功橘茉，由于僅僅有擁有私鑰的SSLserver才干從Client Key Exchange消息中解密得到premaster secret，從而間接地實現(xiàn)了SSLclient對SSLserver的身份驗證姨丈。
& 說明：
Change Cipher Spec消息屬于SSLpassword變化協(xié)議畅卓，其它握手過程交互的消息均屬于SSL握手協(xié)議，統(tǒng)稱為SSL握手消息构挤。
計算Hash值髓介。指的是利用Hash算法（MD5或SHA）將隨意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)。
3.2.2 驗證server和client的SSL握手過程
SSLclient的身份驗證是可選的筋现，由SSLserver決定是否驗證SSLclient的身份唐础。
如圖6中藍色部分標(biāo)識的內(nèi)容所看到的箱歧，假設(shè)SSLserver驗證SSLclient身份。則SSLserver和SSLclient除了交互“3.2.1 僅僅驗證server的SSL握手過程”中的消息協(xié)商密鑰和加密套件外一膨，還須要進行下面操作：
(1) SSLserver發(fā)送Certificate Request消息呀邢。請求SSLclient將其證書發(fā)送給SSLserver。
(2) SSLclient通過Certificate消息將攜帶自己公鑰的證書發(fā)送給SSLserver豹绪。SSLserver驗證該證書的合法性价淌。
(3) SSLclient計算已交互的握手消息、主密鑰的Hash值瞒津。利用自己的私鑰對其進行加密蝉衣，并通過Certificate Verify消息發(fā)送給SSLserver。
(4) SSLserver計算已交互的握手消息巷蚪、主密鑰的Hash值病毡。利用SSLclient證書中的公鑰解密Certificate Verify消息，并將解密結(jié)果與計算出的Hash值比較屁柏。假設(shè)二者同樣啦膜，則SSLclient身份驗證成功。
3.2.3 恢復(fù)原有會話的SSL握手過程
協(xié)商會話參數(shù)淌喻、建立會話的過程中僧家。須要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份裸删。計算量較大八拱，占用了大量的系統(tǒng)資源。
為了簡化SSL握手過程涯塔。SSL同意重用已經(jīng)協(xié)商過的會話乘粒，詳細過程為：
(1) SSLclient發(fā)送Client Hello消息，消息中的會話ID設(shè)置為計劃重用的會話的ID伤塌。
(2) SSLserver假設(shè)同意重用該會話灯萍，則通過在Server Hello消息中設(shè)置同樣的會話ID來應(yīng)答。這樣每聪，SSLclient和SSLserver就能夠利用原有會話的密鑰和加密套件旦棉。不必又一次協(xié)商。
(3) SSLclient發(fā)送Change Cipher Spec消息药薯，通知SSLserver興許報文將採用原有會話的密鑰和加密套件進行加密和MAC計算绑洛。
(4) SSLclient計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值童本，并通過Finished消息發(fā)送給SSLserver真屯，以便SSLserver推斷密鑰和加密套件是否正確。
(5) 相同地穷娱。SSLserver發(fā)送Change Cipher Spec消息绑蔫，通知SSLclient興許報文將採用原有會話的密鑰和加密套件進行加密和MAC計算运沦。
(6) SSLserver計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值配深，并通過Finished消息發(fā)送給SSLclient携添。以便SSLclient推斷密鑰和加密套件是否正確。
4 典型組網(wǎng)應(yīng)用
4.1 HTTPS
HTTPS是基于SSL安全連接的HTTP協(xié)議篓叶。HTTPS通過SSL提供的數(shù)據(jù)加密烈掠、身份驗證和消息完整性驗證等安全機制。為Web訪問提供了安全性保證缸托，廣泛應(yīng)用于網(wǎng)上銀行左敌、電子商務(wù)等領(lǐng)域。
圖8為HTTPS在網(wǎng)上銀行中的應(yīng)用俐镐。某銀行為了方便客戶母谎，提供了網(wǎng)上銀行業(yè)務(wù)，客戶能夠通過訪問銀行的Webserver進行帳戶查詢京革、轉(zhuǎn)帳等。
通過在客戶和銀行的Webserver之間建立SSL連接幸斥，能夠保證客戶的信息不被非法竊取匹摇。
4.2 SSL VPN
SSL VPN是以SSL為基礎(chǔ)的VPN技術(shù)。利用SSL提供的安全機制甲葬，為用戶遠程訪問公司內(nèi)部網(wǎng)絡(luò)提供了安全保證廊勃。如圖9所看到的。SSL VPN通過在遠程接入用戶和SSL VPN網(wǎng)關(guān)之間建立SSL安全連接经窖，同意用戶通過各種Web瀏覽器坡垫，各種網(wǎng)絡(luò)接入方式，在不論什么地方遠程訪問企業(yè)網(wǎng)絡(luò)資源画侣。并可以保證企業(yè)網(wǎng)絡(luò)的安全冰悠，保護企業(yè)內(nèi)部信息不被竊取。
