背景介紹
最近在看《密碼學與網絡安全》相關的書籍，這篇文章主要詳細介紹一下著名的網絡安全協定SSL。
在開始SSl介紹之前，先給大家介紹幾個密碼學的概念和相關的知識。
1、密碼學的相關概念
密碼學(cryptography)：目的是通過将資訊編碼使其不可讀，進而達到安全性。
明文(plain text)：發送人、接受人和任何通路消息的人都能了解的消息。
密文(cipher text)：明文消息經過某種編碼後，得到密文消息。
加密(encryption)：将明文消息變成密文消息。
解密(decryption)：将密文消息變成明文消息。
算法：取一個輸入文本，産生一個輸出文本。
加密算法：發送方進行加密的算法。
解密算法：接收方進行解密的算法。
密鑰(key)：隻有發送方和接收方了解的消息
對稱密鑰加密(Symmetric Key Cryptography)：加密與解密使用相同密鑰。
非對稱密鑰加密(Asymmetric Key Cryptography)：加密與解密使用不同密鑰。
2、相關的加密算法介紹
DES算法即資料加密标準，也稱為資料加密算法。加密過程如下：
在SSL中會用到分組DES、三重DES算法等加密算法對資料進行加密。當然可以選用其他非DES加密算法，視情況而定，後面會詳細介紹。
3、密鑰交換算法
使用對稱加密算法時，密鑰交換是個大難題，是以Diffie和Hellman提出了著名的Diffie-Hellman密鑰交換算法。
Diffie-Hellman密鑰交換算法原理：
RSA加密算法是基于這樣的數學事實：兩個大素數相乘容易，而對得到的乘積求因子則很難。加密過程如下：
3、雜湊演算法：
主要用于驗證資料的完整性，即保證時消息在發送之後和接收之前沒有被篡改對于SSL中使用到的雜湊演算法有MD5、SHA-1。
4、數字證書：
數字證書其實就是一個小的計算機檔案，其作用類似于我們的身份證、護照，用于證明身份，在SSL中，使用數字證書來證明自己的身份，而不是僞造的。
5、簡單的總結：
在SSL中會使用密鑰交換算法交換密鑰；使用密鑰對資料進行加密；使用雜湊演算法對資料的完整性進行驗證，使用數字證書證明自己的身份。好了，下面開始介紹SSL協定。
SSL介紹：
安全套接字（Secure Socket Layer，SSL）協定是Web浏覽器與Web伺服器之間安全交換資訊的協定，提供兩個基本的安全服務：鑒别與保密。
SSL是Netscape于1994年開發的，後來成為了世界上最著名的web安全機制，所有主要的浏覽器都支援SSL協定
目前有三個版本：2、3、3.1，最常用的是第3版，是1995年釋出的。
SSL協定的三個特性
① 保密：在握手協定中定義了會話密鑰後，所有的消息都被加密。
② 鑒别：可選的用戶端認證，和強制的伺服器端認證。
③ 完整性：傳送的消息包括消息完整性檢查（使用MAC）。
SSL的位置
SSL介于應用層和TCP層之間。應用層資料不再直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的資料進行加密，并增加自己的SSL頭。
SSL的工作原理
握手協定（Handshake protocol）
記錄協定（Record protocol）
警報協定（Alert protocol）
1、握手協定
握手協定是客戶機和伺服器用SSL連接配接通信時使用的第一個子協定，握手協定包括客戶機與伺服器之間的一系列消息。SSL中最複雜的協定就是握手協定。該協定允許伺服器和客戶機互相驗證，協商加密和MAC算法以及保密密鑰，用來保護在SSL記錄中發送的資料。握手協定是在應用程式的資料傳輸之前使用的。
每個握手協定包含以下3個字段
（1）Type：表示10種消息類型之一
（2）Length：表示消息長度位元組數
（3）Content：與消息相關的參數
握手協定的4個階段
1.1建立安全能力
SSL握手的第一階段啟動邏輯連接配接，建立這個連接配接的安全能力。首先客戶機向伺服器發出client hello消息并等待伺服器響應，随後伺服器向客戶機傳回server hello消息，對client hello消息中的資訊進行确認。
Client hello消息包括Version，Random，Session id，Cipher suite，Compression method等資訊。
ClientHello 客戶發送CilentHello資訊，包含如下内容：
（1）用戶端可以支援的SSL最高版本号
（2）一個用于生成主秘密的32位元組的随機數。（等會介紹主秘密是什麼）
（3）一個确定會話的會話ID。
（4）一個用戶端可以支援的密碼套件清單。
密碼套件格式：每個套件都以“SSL”開頭，緊跟着的是密鑰交換算法。用“With”這個詞把密鑰交換算法、加密算法、雜湊演算法分開，例如：SSL_DHE_RSA_WITH_DES_CBC_SHA,表示把DHE_RSA(帶有RSA數字簽名的暫時Diffie-HellMan)定義為密鑰交換算法；把DES_CBC定義為加密算法；把SHA定義為雜湊演算法。
（5）一個用戶端可以支援的壓縮算法清單。
ServerHello 伺服器用ServerHello資訊應答客戶，包括下列内容
（1）一個SSL版本号。取用戶端支援的最高版本号和服務端支援的最高版本号中的較低者。
（2）一個用于生成主秘密的32位元組的随機數。（用戶端一個、服務端一個）
（3）會話ID
（4）從用戶端的密碼套件清單中選擇的一個密碼套件
（5）從用戶端的壓縮方法的清單中選擇的壓縮方法
這個階段之後，用戶端服務端知道了下列内容：
（1）SSL版本
（2）密鑰交換、資訊驗證和加密算法
（3）壓縮方法
（4）有關密鑰生成的兩個随機數。
1.2 伺服器鑒别與密鑰交換
伺服器啟動SSL握手第2階段，是本階段所有消息的唯一發送方，客戶機是所有消息的唯一接收方。該階段分為4步：
（a）證書：伺服器将數字證書和到根CA整個鍊發給用戶端，使用戶端能用伺服器證書中的伺服器公鑰認證伺服器。
（b）伺服器密鑰交換（可選）：這裡視密鑰交換算法而定
（c）證書請求：服務端可能會要求客戶自身進行驗證。
（d）伺服器握手完成：第二階段的結束，第三階段開始的信号
這裡重點介紹一下服務端的驗證和密鑰交換。這個階段的前面的（a）證書 和（b）伺服器密鑰交換是基于密鑰交換方法的。而在SSL中密鑰交換算法有6種：無效（沒有密鑰交換）、RSA、匿名Diffie-Hellman、暫時Diffie-Hellman、固定Diffie-Hellman、Fortezza。
在階段1過程用戶端與服務端協商的過程中已經确定使哪種密鑰交換算法。
如果協商過程中确定使用RSA交換密鑰，那麼過程如下圖：
這個方法中，伺服器在它的第一個資訊中，發送了RSA加密/解密公鑰證書。不過，因為預備主秘密是由用戶端在下一個階段生成并發送的，是以第二個資訊是空的。注意，公鑰證書會進行從伺服器到用戶端的驗證。當伺服器收到預備主秘密時，它使用私鑰進行解密。服務端擁有私鑰是一個證據，可以證明伺服器是一個它在第一個資訊發送的公鑰證書中要求的實體。
其他的幾種密鑰交換算法這裡就不介紹了。可以參考Behrouz A.Forouzan著的《密碼學與網絡安全》。
1.3 客戶機鑒别與密鑰交換：
客戶機啟動SSL握手第3階段，是本階段所有消息的唯一發送方，伺服器是所有消息的唯一接收方。該階段分為3步：
（a）證書（可選）：為了對伺服器證明自身，客戶要發送一個證書資訊，這是可選的，在IIS中可以配置強制用戶端證書認證。
（b）客戶機密鑰交換（Pre-master-secret）：這裡用戶端将預備主密鑰發送給服務端，注意這裡會使用服務端的公鑰進行加密。
（c）證書驗證（可選），對預備秘密和随機數進行簽名，證明擁有（a）證書的公鑰。
下面也重點介紹一下RSA方式的用戶端驗證和密鑰交換。
這種情況，除非伺服器在階段II明确請求，否則沒有證書資訊。用戶端密鑰交換方法包括階段II收到的由RSA公鑰加密的預備主密鑰。
階段III之後，客戶要有伺服器進行驗證，客戶和伺服器都知道預備主密鑰。
1.4 完成
客戶機啟動SSL握手第4階段，使伺服器結束。該階段分為4步，前2個消息來自客戶機，後2個消息來自伺服器。
1.5密鑰生成的過程
這樣握手協定完成，下面看下什麼是預備主密鑰，主密鑰是怎麼生成的。為了保證資訊的完整性和機密性，SSL需要有六個加密秘密：四個密鑰和兩個IV。為了資訊的可信性，用戶端需要一個密鑰（HMAC），為了加密要有一個密鑰，為了分組加密要一個IV，服務也是如此。SSL需要的密鑰是單向的，不同于那些在其他方向的密鑰。如果在一個方向上有攻擊，這種攻擊在其他方向是沒影響的。生成過程如下：
2、記錄協定
記錄協定在客戶機和伺服器握手成功後使用，即客戶機和伺服器鑒别對方和确定安全資訊交換使用的算法後，進入SSL記錄協定，記錄協定向SSL連接配接提供兩個服務：
（1）保密性：使用握手協定定義的秘密密鑰實作
（2）完整性：握手協定定義了MAC，用于保證消息完整性
記錄協定的過程：
3、警報協定
客戶機和伺服器發現錯誤時，向對方發送一個警報消息。如果是緻命錯誤，則算法立即關閉SSL連接配接，雙方還會先删除相關的會話号，秘密和密鑰。每個警報消息共2個位元組，第1個位元組表示錯誤類型，如果是警報，則值為1，如果是緻命錯誤，則值為2；第2個位元組制定實際錯誤類型。
總結
SSL中，使用握手協定協商加密和MAC算法以及保密密鑰 ，使用握手協定對交換的資料進行加密和簽名，使用警報協定定義資料傳輸過程中，出現問題如何去解決。
整個過程比較複雜，如果大家有不了解和我叙述不周的地方，歡迎大家指正出來！
本文轉自麒麟部落格園部落格，原文連結：http://www.cnblogs.com/zhuqil/archive/2012/10/06/ssl_detail.html，如需轉載請自行聯系原作者