網路安全總結
1、前言
當前，網際網路以及移動網際網路高速發展，人們需要在網路中傳遞的資訊越來越多，進行的網路行為也越來越多。這裡面就包括很多涉及私密資訊的行為，比如用網上銀行支付網購的物品等。這些資訊相比普通的上網瀏覽網頁等產生的資訊來說需要提供安全可靠的傳輸方式。而且，安全、可靠和有效的傳遞這些資訊無論是對於使用者還是服務提供商來說都是非常重要的。2、一些基礎知識
這部分內容主要解釋一些網路安全方面重要的概念和術語，最好是先理解這部分內容。2.1、公鑰密碼體制(public-key cryptography)
公鑰密碼體制分為三個部分，公鑰、私鑰、加密解密演算法，它的加密解密過程如下：
- 加密：通過加密演算法和公鑰對內容(或者說明文)進行加密，得到密文。加密過程需要用到公鑰。
- 解密：通過解密演算法和私鑰對密文進行解密，得到明文。解密過程需要用到解密演算法和私鑰。注意，由公鑰加密的內容，只能由私鑰進行解密，也就是說，由公鑰加密的內容，如果不知道私鑰，是無法解密的。
公鑰密碼體制的公鑰和演算法都是公開的(這是為什麼叫公鑰密碼體制的原因)，私鑰是保密的。大家都以使用公鑰進行加密，但是隻有私鑰的持有者才能解密。在實際的使用中，有需要的人會生成一對公鑰和私鑰，把公鑰釋出出去給別人使用，自己保留私鑰。
2.2、對稱加密演算法(symmetric key algorithms)
在對稱加密演算法中，加密使用的金鑰和解密使用的金鑰是相同的。也就是說，加密和解密都是使用的同一個金鑰。因此對稱加密演算法要保證安全性的話，金鑰要做好保密，只能讓使用的人知道，不能對外公開。這個和上面的公鑰密碼體制有所不同，公鑰密碼體制中加密是用公鑰，解密使用私鑰，而對稱加密演算法中，加密和解密都是使用同一個金鑰，不區分公鑰和私鑰。
註解：
金鑰，一般就是一個字串或數字，在加密或者解密時傳遞給加密/解密演算法。前面在公鑰密碼體制中說到的公鑰、私鑰就是金鑰，公鑰是加密使用的金鑰，私鑰是解密使用的金鑰。
2.3、非對稱加密演算法(asymmetric key algorithms)
在非對稱加密演算法中，加密使用的金鑰和解密使用的金鑰是不相同的。前面所說的公鑰密碼體制就是一種非對稱加密演算法，他的公鑰和是私鑰是不能相同的，也就是說加密使用的金鑰和解密使用的金鑰不同，因此它是一個非對稱加密演算法。
2.4、RSA簡介
RSA是一種公鑰密碼體制，現在使用得很廣泛。如果對RSA本身有興趣的，後面看我有沒有時間寫個RSA的具體介紹。
RSA密碼體制是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密演算法是公開的。 由公鑰加密的內容可以並且只能由私鑰進行解密，並且由私鑰加密的內容可以並且只能由公鑰進行解密。也就是說，RSA的這一對公鑰、私鑰都可以用來加密和解密，並且一方加密的內容可以由並且只能由對方進行解密。
2.5、MAC（Message Authentication Code）
訊息認證碼（帶金鑰的Hash函式）:密碼學中，通訊實體雙方使用的一種驗證機制，保證訊息資料完整性的一種工具。構造方法由M.Bellare提出，安全性依賴於Hash函式，故也稱帶金鑰的Hash函式。訊息認證碼是基於金鑰和訊息摘要所獲得的一個值，可用於資料來源發認證和完整性校驗。在傳送資料之前，傳送方首先使用通訊雙方協商好的雜湊函式計算其摘要值。在雙方共享的會話金鑰作用下，由摘要值獲得訊息驗證碼。之後，它和資料一起被髮送。接收方收到報文後，首先利用會話金鑰還原摘要值，同時利用雜湊函式在本地計算所收到資料的摘要值，並將這兩個資料進行比對。若兩者相等，則報文通過認證。訊息驗證碼有兩種計算方式，一種是利用已有的加密演算法，如DES等直接對摘要值進行加密處理；另一種是使用專門的MAC演算法。目前，資訊保安領域普遍認同的演算法是HMAC，它基於MD5或者SHA-1，在計算雜湊值時將金鑰和資料同時作為輸入，並採用了二次雜湊迭代的方式。
2.6、簽名和加密
我們說加密，是指對某個內容加密，加密後的內容還可以通過解密進行還原。 比如我們把一封郵件進行加密，加密後的內容在網路上進行傳輸，接收者在收到後，通過解密可以還原郵件的真實內容。
這裡主要解釋一下簽名，簽名就是在資訊的後面再加上一段內容，可以證明資訊沒有被修改過，怎麼樣可以達到這個效果呢？一般是對資訊做一個hash計算得到一個hash值，注意，這個過程是不可逆的，也就是說無法通過hash值得出原來的資訊內容。在把資訊傳送出去時，把這個hash值加密後做為一個簽名和資訊一起發出去。 接收方在收到資訊後，會重新計算資訊的hash值，並和資訊所附帶的hash值(解密後)進行對比，如果一致，就說明資訊的內容沒有被修改過，因為這裡hash計算可以保證不同的內容一定會得到不同的hash值，所以只要內容一被修改，根據資訊內容計算的hash值就會變化。當然，不懷好意的人也可以修改資訊內容的同時也修改hash值，從而讓它們可以相匹配，為了防止這種情況，hash值一般都會加密後(也就是簽名)再和資訊一起傳送，以保證這個hash值不被修改。至於如何讓別人可以解密這個簽名，這個過程涉及到數字證書等概念，我們後面在說到數字證書時再詳細說明，這裡您先只需先理解簽名的這個概念。
3、http協議
通常，人們上網獲取資訊交換資訊是使用的是全球資訊網。這裡面涉及的應用的層的網際網路協議大多是http協議。http協議當初設計的時候主要考慮的是如何讓使用者更有效的獲得網路中的資源。它被設計為是RESTful( REpresentational State Transfer，表現層狀態轉化 )架構，這種架構方便開放人員開發和使用者使用。但是，它沒有把安全問題也考慮進去。 註解： 要理解RESTful架構，最好的方法就是去理解Representational State Transfer這個片語到底是什麼意思，它的每一個詞代表了什麼涵義。如果你把這個名稱搞懂了，也就不難體會REST是一種什麼樣的設計。資源（Resources）
REST的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（Resources）的"表現層"。
所謂"資源"，就是網路上的一個實體，或者說是網路上的一個具體資訊。它可以是一段文字、一張圖片、一首歌曲、一種服務，總之就是一個具體的實體。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
所謂"上網"，就是與網際網路上一系列的"資源"互動，呼叫它的URI。
表現層（Representation）
"資源"是一種資訊實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。
比如，文字可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進位制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。
URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最後的".html"字尾名是不必要的，因為這個字尾名錶示格式，屬於"表現層"範疇，而URI應該只代表"資源"的位置。它的具體表現形式，應該在HTTP請求的頭資訊中用Accept和Content-Type欄位指定，這兩個欄位才是對"表現層"的描述。
狀態轉化（State Transfer）
訪問一個網站，就代表了客戶端和伺服器的一個互動過程。在這個過程中，勢必涉及到資料和狀態的變化。
網際網路通訊協議HTTP協議，是一個無狀態協議。這意味著，所有的狀態都儲存在伺服器端。因此，如果客戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。
客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裡面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。
綜述
綜合上面的解釋，我們總結一下什麼是RESTful架構：
（1）每一個URI代表一種資源；
（2）客戶端和伺服器之間，傳遞這種資源的某種表現層（Representation）；
（3）客戶端通過四個HTTP動詞，對伺服器端資源進行操作，實現"表現層狀態轉化"。
4、https
https(Hypertext Transfer Protocol over Secure Socket Layer)就是http的安全版本，它在http所在的應用層與傳輸層之間加入了一層安全層SSL(Secure Sockets Layer)。它最初是由Netscape開發並內置於其瀏覽器中，用於對資料進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全套接字層（SSL）作為HTTP應用層的子層。SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業資訊的加密是合適的。 它的主要作用可以分為兩種：一種是建立一個資訊保安通道，來保證資料傳輸的安全；另一種就是確認網站的真實性。 註解：https與http的區別 一、https協議需要到ca申請證書，一般免費證書很少，需要交費。 二、http是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。 三、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。 四、http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。 https的一般流程如下圖所示：
5、SSL/TSL
https的關鍵技術就是加入了SSL協議，現在詳細介紹一下SSL協議。SSL(Secure Sockets Layer ，安全套接層)，是為網路通訊提供安全及資料完整性的一種安全協議。由Netscape研發，用以保障在Internet上資料傳輸的安，提供兩個基本的安全服務：鑑別與保密。當前幾乎所有瀏覽器都支援SSL，但是支援的版本有所不同。當前主要版本V3。在SSL標準化過程中又出現了對SSL增強的版本TSL，可以說是SSL的繼任者。到SSL Version3，提交作為IFTF草案，已經廣泛的應用Intetnet通訊。之後IETF對SSLv3稍作改動並更名為TLS1.0，對應RFC2246，之後的TLS1.1、TLS1.2先後被接受為RFC4346，RFC5246，另外由於TLS是基於TCP協議設計，導致其不能處理獨立紀錄，不允許SSL時有資料丟失，在RFC4347中提出了一種“Datagram TLS”---DTLS，可以理解為TLS1.1的分支。 註解：
TLS與SSL的差異 1）版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不同，TLS的版本1.0使用的版本號為SSLv3.1。 2）報文鑑別碼：SSLv3.0和TLS的MAC演算法及MAC計算的範圍不同。TLS使用了RFC-2104定義的HMAC演算法。SSLv3.0使用了相似的演算法，兩者差別在於SSLv3.0中，填充位元組與金鑰之間採用的是連線運算，而HMAC演算法採用的是異或運算。但是兩者的安全程度是相同的。 3）偽隨機函式：TLS使用了稱為PRF的偽隨機函式來將金鑰擴充套件成資料塊，是更安全的方式。 4）報警程式碼：TLS支援幾乎所有的SSLv3.0報警程式碼，而且TLS還補充定義了很多報警程式碼，如解密失敗（decryption_failed）、記錄溢位（record_overflow）、未知CA（unknown_ca）、拒絕訪問（access_denied）等。 5）密文族和客戶證書：SSLv3.0和TLS存在少量差別，即TLS不支援Fortezza金鑰交換、加密演算法和客戶證書。 6）certificate_verify和finished訊息：SSLv3.0和TLS在用certificate_verify和finished訊息計算MD5和SHA-1雜湊碼時，計算的輸入有少許差別，但安全性相當。 7）加密計算：TLS與SSLv3.0在計算主密值（master secret）時採用的方式不同。 8）填充：使用者資料加密之前需要增加的填充位元組。在SSL中，填充後的資料長度要達到密文塊長度的最小整數倍。而在TLS中，填充後的資料長度可以是密文塊長度的任意整數倍（但填充的最大長度為255位元組），這種方式可以防止基於對報文長度進行分析的攻擊。
TLS的主要增強內容
TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。TLS 在SSL v3.0 的基礎上，提供了以下增強內容：
1）更安全的MAC演算法；
2）更嚴密的警報；
3）“灰色區域”規範的更明確的定義；
TLS對於安全性的改進
1）對於訊息認證使用金鑰雜湊法：TLS 使用“訊息認證程式碼的金鑰雜湊法”（HMAC），當記錄在開放的網路（如因特網）上傳送時，該程式碼確保記錄不會被變更。SSLv3.0還提供鍵控訊息認證，但HMAC比SSLv3.0使用的（訊息認證程式碼）MAC 功能更安全。
2）增強的偽隨機功能（PRF）：PRF生成金鑰資料。在TLS中，HMAC定義PRF。PRF使用兩種雜湊演算法保證其安全性。如果任一演算法暴露了，只要第二種演算法未暴露，則資料仍然是安全的。
3）改進的已完成訊息驗證：TLS和SSLv3.0都對兩個端點提供已完成的訊息，該訊息認證交換的訊息沒有被變更。然而，TLS將此已完成訊息基於PRF和HMAC值之上，這也比SSLv3.0更安全。
4）一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現交換的證書型別。
5）特定警報訊息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應該傳送某些警報進行記錄。
SSL/TSL協議體系結構如下圖所示。
從圖中可以看出，SSL協議可分為兩層：
- SSL/TSL 握手協議（SSL Handshake Protocol）：建立在 SSL/TSL 記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。 SSL/TSL 協議實際上是 SSL/TSL 握手協議、 SSL/TSL 修改密文協議、 SSL/TSL 警告協議和SSL記錄協議組成的一個協議族。
- SSL/TSL 記錄協議（SSL Record Protocol）：建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。
其中SSL握手協議最複雜，下面先從SSL握手協議開始講解SSL。
SSL/TSL握手協議
SSL/TSL握手協議被封裝在記錄協議中，該協議允許伺服器與客戶機在應用程式傳輸和接收資料之前互相認證、協商加密演算法和金鑰。在初次建立SSL連線時，伺服器與客戶機交換一系列訊息。
這些訊息交換能夠實現如下操作：
- 客戶機認證伺服器
- 允許客戶機與伺服器選擇雙方都支援的密碼演算法
- 可選擇的伺服器認證客戶
- 使用公鑰加密技術生成共享金鑰
- 建立加密SSL連線
每個握手協議包含以下3個欄位
（1）Type：表示10種訊息型別之一 （2）Length：表示訊息長度位元組數 （3）Content：與訊息相關的引數
SSL/TSL握手協議的報文型別如下表所示。
表 SSL握手協議報文型別
|
報文型別 |
引數 |
|
hello_request |
空 |
|
client_hello |
版本、隨機數、會話ID、密文族、壓縮方法 |
|
server_hello |
版本、隨機數、會話ID、密文族、壓縮方法 |
|
certificate |
x.509V3證書鏈 |
|
server_key_exchange |
引數、簽名 |
|
certificate_request |
型別、授權 |
|
server_done |
空 |
|
certificate_verify |
簽名 |
|
client_key_exchange |
引數、簽名 |
|
finished |
Hash值 |
SSL/TSL握手協議過程如下圖所示。
SSL握手協議的過程（帶*的傳輸是可選的，或者與站點相關的，並不總是傳送的報文）
現在看圖，分步說明 SSL/TSL 握手協議的全過程：
步驟1 建立安全能力。
ClientHello 客戶傳送CilentHello資訊，包含如下內容：
（1）客戶端可以支援的SSL最高版本號 （2）一個用於生成主祕密的32位元組的隨機數。（用於計算產生主金鑰，主金鑰用於資料傳輸中加密資料） （3）一個確定會話的會話ID。 （4）一個客戶端可以支援的密碼套件列表。 （5）一個客戶端可以支援的壓縮演算法列表。 其中第(4)步中，在密文族(cipher suites)中指明自己支援的對稱加密、非對稱加密和數字簽名演算法。如下圖所示，密文族格式：每個套件都以“TSL”開頭，緊跟著的是金鑰交換演算法。用“With”這個詞把金鑰交換演算法、加密演算法、雜湊演算法分開，例如：TSL_RSA_WITH_RC4_128_MD5, 表示把RSA定義為金鑰交換演算法；把 RC4_128定義為加密演算法；把MD5定義為雜湊演算法。密文族引數包括金鑰交換方法（Deffie-Hellman金鑰交換演算法、基於RSA的金鑰交換和另一種實現在Fortezza chip上的金鑰交換）、加密演算法（DES、RC4、RC2、3DES等）、MAC演算法（MD5或SHA-1）、加密型別（流或分組）等內容。
ServerHello伺服器用ServerHello資訊應答客戶，包括下列內容
（1）一個SSL版本號。取客戶端支援的最高版本號和服務端支援的最高版本號中的較低者。 （2）一個用於生成主祕密的32位元組的隨機數。（客戶端一個、服務端一個） （3）會話ID （4）從客戶端的密碼套件列表中選擇的一個密碼套件 （5）從客戶端的壓縮方法的列表中選擇的壓縮方法 這個階段之後，客戶端服務端知道了下列內容： （1）SSL版本 （2）金鑰交換、資訊驗證和加密演算法 （3）壓縮方法 （4）有關金鑰生成的兩個隨機數。步驟2 認證伺服器和金鑰交換。
在hello報文之後，如果伺服器需要被認證，伺服器將傳送其證書。如果需要，伺服器還要傳送server_key_exchange；然後，伺服器可以向客戶傳送certificate_request請求證書。伺服器總是傳送server_hello_done報文，指示伺服器的hello階段結束。
伺服器啟動SSL握手第2階段，是本階段所有訊息的唯一發送方，客戶機是所有訊息的唯一接收方。該階段分為4步： （a）證書：伺服器將數字證書和到根CA整個鏈發給客戶端，使客戶端能用伺服器證書中的伺服器公鑰認證伺服器。 （b）伺服器金鑰交換（可選）：這裡視金鑰交換演算法而定 （c）證書請求：服務端可能會要求客戶自身進行驗證。 （d）伺服器握手完成：第二階段的結束，第三階段開始的訊號 這裡重點介紹一下服務端的驗證和金鑰交換。這個階段的前面的（a）證書 和（b）伺服器金鑰交換是基於金鑰交換方法的。而在SSL中金鑰交換演算法有6種：無效（沒有金鑰交換）、RSA、匿名Diffie-Hellman、暫時Diffie-Hellman、固定Diffie-Hellman、Fortezza。 在階段1過程客戶端與服務端協商的過程中已經確定使哪種金鑰交換演算法。 如果協商過程中確定使用RSA交換金鑰，那麼過程如下圖：
這個方法中，伺服器在它的第一個資訊中，傳送了RSA加密/解密公鑰證書。不過，因為預備主祕密是由客戶端在下一個階段生成併發送的，所以第二個資訊是空的。注意，公鑰證書會進行從伺服器到客戶端的驗證。當伺服器收到預備主祕密時，它使用私鑰進行解密。服務端擁有私鑰是一個證據，可以證明伺服器是一個它在第一個資訊傳送的公鑰證書中要求的實體。
步驟3 認證客戶和金鑰交換。
客戶一旦收到伺服器的server_hello_done報文，客戶將檢查伺服器證書的合法性（如果伺服器要求），如果伺服器向客戶請求了證書，客戶必須傳送客戶證書，然後傳送client_key_exchange報文，報文的內容依賴於client_hello與server_hello定義的金鑰交換的型別。最後，客戶可能傳送client_verify 報文來校驗客戶傳送的證書，這個報文只能在具有簽名作用的客戶證書之後傳送。
客戶機啟動SSL握手第3階段，是本階段所有訊息的唯一發送方，伺服器是所有訊息的唯一接收方。該階段分為3步： （a）證書（可選）：為了對伺服器證明自身，客戶要傳送一個證書資訊，這是可選的，在IIS中可以配置強制客戶端證書認證。 （b）客戶機金鑰交換（Pre-master-secret）：這裡客戶端將預備主金鑰傳送給服務端，注意這裡會使用服務端的公鑰進行加密。 （c）證書驗證（可選），對預備祕密和隨機數進行簽名，證明擁有（a）證書的公鑰。 下面也重點介紹一下RSA方式的客戶端驗證和金鑰交換。 這種情況，除非伺服器在階段II明確請求，否則沒有證書資訊。客戶端金鑰交換方法包括階段II收到的由RSA公鑰加密的預備主金鑰。 階段III之後，客戶要有伺服器進行驗證，客戶和伺服器都知道預備主金鑰。步驟4 結束
客戶傳送change_cipher_spec報文並將掛起的CipherSpec複製到當前的CipherSpec。這個報文使用的是修改密文協議。然後，客戶在新的演算法、對稱金鑰和MAC祕密之下立即傳送finished報文。finished報文驗證金鑰交換和鑑別過程是成功的。伺服器對這兩個報文響應，傳送自己的change_cipher_spec報文、finished報文。握手結束，客戶與伺服器可以傳送應用層資料了。
客戶機啟動SSL握手第4階段，使伺服器結束。該階段分為4步，前2個訊息來自客戶機，後2個訊息來自伺服器。當客戶從伺服器端傳送的證書中獲得相關資訊時，需要檢查以下內容來完成對伺服器的認證：
- 時間是否在證書的合法期限內；
- 簽發證書的機關是否客戶端信任的；
- 簽發證書的公鑰是否符合簽發者的數字簽名；
- 證書中的伺服器域名是否符合伺服器自己真正的域名。
伺服器被驗證成功後，客戶繼續進行握手過程。
同樣地，伺服器從客戶傳送的證書中獲得相關資訊認證客戶的身份，需要檢查：
- 使用者的公鑰是否符合使用者的數字簽名；
- 時間是否在證書的合法期限內；
- 簽發證書的機關是否伺服器信任的；
- 使用者的證書是否被列在伺服器的LDAP裡使用者的資訊中；
- 得到驗證的使用者是否仍然有許可權訪問請求的伺服器資源。
SSL記錄協議
SSL記錄協議為SSL連線提供兩種服務：機密性和報文完整性。
在SSL協議中，所有的傳輸資料都被封裝在記錄中。記錄是由記錄頭和記錄資料（長度不為0）組成的。所有的SSL通訊都使用SSL記錄層，記錄協議封裝上層的握手協議、報警協議、修改密文協議。SSL記錄協議包括記錄頭和記錄資料格式的規定。
SSL記錄協議定義了要傳輸資料的格式，它位於一些可靠的傳輸協議之上（如TCP），用於各種更高層協議的封裝。主要完成分組和組合、壓縮和解壓縮，以及訊息認證和加密等。
SSL記錄協議主要操作流程如下圖所示。
SSL記錄協議的操作流程
圖中的五個操作簡單介紹如下：
1）每個上層應用資料被分成214位元組或更小的資料塊。記錄中包含型別、版本號、長度和資料欄位。
2）壓縮是可選的，並且是無失真壓縮，壓縮後內容長度的增加不能超過1024位元組。
3）在壓縮資料上計算訊息認證MAC。
4）對壓縮資料及MAC進行加密。
5）增加SSL記錄。
SSL記錄協議欄位的結構如下圖所示。
SSL記錄協議欄位的結構
如圖 SSL記錄協議欄位結構主要由內容型別、主要版本、次要版本、壓縮長度組成，簡介如下：
1) 內容型別（8位）：封裝的高層協議。
2) 主要版本（8位）：使用的SSL主要版本。對於SSL v3已經定義的內容型別是握手協議、警告協議、改變密碼格式協議和應用資料協議。
3) 次要版本（8位）：使用的SSL次要版本。對於SSL v3.0，值為0。
4) 壓縮長度（16位）：明文資料（如果選用壓縮則是壓縮資料）以位元組為單位的長度。
SSL報警協議
SSL報警協議是用來為對等實體傳遞SSL的相關警告。如果在通訊過程中某一方發現任何異常,就需要給對方傳送一條警示訊息通告。警示訊息有兩種：
- Fatal錯誤,如傳遞資料過程中發現錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩衝區相應的會話記錄。
- Warning訊息,這種情況,通訊雙方通常都只是記錄日誌,而對通訊過程不造成任何影響。SSL握手協議可以使得伺服器和客戶能夠相互鑑別對方,協商具體的加密演算法和MAC演算法以及保密金鑰,用來保護在SSL記錄中傳送的資料。
SSL修改密文協議
為了保障SSL傳輸過程的安全性,客戶端和伺服器雙方應該每隔一段時間改變加密規範。所以有了SSL修改密文協議。SSL修改密文協議是3個高層的特定協議之一,也是其中最簡單的一個。在客服端和伺服器完成握手協議之後,它需要向對方傳送相關訊息(該訊息只包含一個值為1的單位元組)，通知對方隨後的資料將用剛剛協商的密碼規範演算法和關聯的金鑰處理，並負責協調本方模組按照協商的演算法和金鑰工作。
5、數字證書
上面講到了有關數字證書的東西，現在詳細介紹一下數字證書。
數字證書是數字憑據，它提供有關實體標識的資訊以及其他支援資訊。數字證書是由稱為證書頒發機構 (CA) 的權威機構頒發的。由於數字證書由證書權威機構頒發，因此由該權威機構擔保證書資訊的有效性。此外，數字證書只在特定的時間段內有效。
數字證書是用來證明網路實體身份以及傳遞其公鑰的電子媒介。所以說數字證書主要有兩個作用，第一個是證明其真實有效的身份，類似於電子的網路“身份證”，第二個是向對方釋出其公鑰，以便後續進行加密的通訊。
X.509 標準規定數字證書應包含標準化資訊。具體地說，X.509 版本 3 證書包含下列欄位：
- 版本號 證書所遵循的 X.509 標準的版本。
- 序列號 唯一標識證書且由證書頒發機構頒發的編號。
- 證書演算法標識 證書頒發機構用來對數字證書進行簽名的特定公鑰演算法的名稱。
- 頒發者名稱 實際頒發該證書的證書頒發機構的標識。
- 有效期 數字證書保持有效的時間段，幷包含起始日期和過期日期。
- 使用者名稱 數字證書所有者的姓名。
- 使用者公鑰資訊 與數字證書所有者關聯的公鑰以及與該公鑰關聯的特定公鑰演算法。
- 頒發者唯一識別符號 可以用來唯一標識數字證書頒發者的資訊。
- 使用者唯一識別符號 可以用來唯一標識數字證書所有者的資訊。
- 擴充資訊 與證書的使用和處理有關的其他資訊。
- 證書頒發機構的數字簽名 使用證書演算法識別符號欄位中指定的演算法以及證書頒發機構的私鑰進行的實際數字簽名。
公鑰加密的優勢之一是，由於用一個金鑰對取代了大量的對稱金鑰，因此減少了金鑰管理的工作量。數字證書進一步增強了這一優勢，它解決了公鑰的分發和管理問題。但是，數字證書無法進行自我管理。由於數字證書固有的廣為分發的特點，因此，設計這些證書的管理方案時，必須考慮到數字證書的分發性這一特點。數字證書需要一種有效的基礎結構，以便在證書的使用環境中管理證書。公鑰基礎結構 (PKI) 與數字證書是不可分割的。PKI 負責頒發證書，它通過目錄確保這些證書的分發，並驗證證書。PKI 負責基礎工作，其中包括支援數字證書，並使它們可以提供 S/MIME 等服務所依賴的功能。
由於 PKI 的規模大，而且很複雜，這裡所提供的資訊著重講述 PKI 和數字簽名如何配合工作。有許多很優秀的資源講述了 PKI。您可以從 PKI 供應商的文件以及其他專門涉及 PKI 的資訊源中獲取有關 PKI 的詳細資訊。
6、PKI的內容
一個完整的PKI系統必須具備權威認證機構（CA）、數字證書庫、金鑰備份及恢復系統、證書作廢系統和應用介面（API）等基本組成部分。 1、權威認證機構（Certificate Authority）：權威認證機構簡稱CA，是PKI的核心組成部分，也稱作認證中心。它是數字證書的簽發機構。CA是PKI的核心，是PKI應用中權威的、可信任的、公正的第三方機構。 2、數字證書庫：在使用公鑰體制的網路環境中，必須向公鑰的使用者證明公鑰的真實合法性。因此，在公鑰體制環境中，必須有一個可信的機構來對任何一個主體的公鑰進行公證，證明主體的身份以及它與公鑰的匹配關係。目前較好的解決方案是引進證書(Certificate)機制。（1）證書。證書是公開金鑰體制的一種金鑰管理媒介。它是一種權威性的電子文件，形同網路環境中的一種身份證，用於證明某一主體的身份以及其公開金鑰的合法性。（2）證書庫。證書庫是證書的集中存放地，是網上的一種公共資訊庫，供廣大公眾進行開放式查詢。到證書庫訪問查詢，可以得到想與之通訊實體的公鑰。證書庫是擴充套件PKI系統的一個組成部分，CA的數字簽名保證了證書的合法性和權威性。 3、金鑰備份及恢復系統：如果使用者丟失了金鑰，會造成已經加密的檔案無法解密，引起資料丟失，為了避免這種情況，PKI提供金鑰備份及恢復機制。 4、證書作廢系統：有時因為使用者身份變更或者金鑰遺失，需要將證書停止使用，所以提供證書作廢機制。 5、PKI應用介面系統： PKI應用介面系統是為各種各樣的應用提供安全、一致、可信任的方式與PKI互動，確保所建立起來的網路環境安全可信，並降低管理成本。沒有PKI應用介面系統，PKI就無法有效地提供服務。 總結來說，PKI就是管理髮布證書以及金鑰的一套系統。7、USBkey
上面講到的https/ssl協議，在SSL協議握手協議中，如果伺服器要求認證客戶端，需要客戶端傳送其數字證書。這裡就有一個問題，客戶端的證書該如何儲存才能安全。USB可以就是解決這個問題的，它安全有效的儲存了客戶端的數字證書。 USB Key是一種USB介面的硬體裝置。它內建微控制器或智慧卡晶片，有一定的儲存空間，可以儲存使用者的私鑰以及數字證書，利用USB Key內建的公鑰演算法實現對使用者身份的認證。由於使用者私鑰儲存在密碼鎖中，理論上使用任何方式都無法讀取，因此保證了使用者認證的安全性。 USB Key產品最早是由加密鎖廠商提出來的，原先的USB加密鎖主要用於防止軟體破解和複製，保護軟體不被盜版，而USB Key的目的不同，USB Key主要用於網路認證，鎖內主要儲存數字證書和使用者私鑰。 USB Key廠家將USB Key與PKI技術相結合，開發出了符合PKI標準的安全中介軟體，利用USB Key來儲存數字證書和使用者私鑰，並對應用開發商提供符合PKI標準的程式設計介面如PKCS#11和MSCAPI，以便於開發基於PKI的應用程式。由於USB Key 本身作為金鑰儲存器，其自身的硬體結構決定了使用者只能通過廠商程式設計介面訪問資料，這就保證了儲存在USB Key中的數字證書無法被複制，並且每一個USB Key都帶有PIN碼保護，這樣USB Key的硬體和PIN碼構成了可以使用證書的兩個必要因子。如果使用者PIN碼被洩漏，只要儲存好USB Key的硬體就可以保護自己的證書不被盜用，如果使用者的USB Key丟失，獲得者由於不知道該硬體的PIN碼，也無法盜用使用者存在USB Key中的證書。與PKI技術的結合使USB Key的應用領域從僅確認使用者身份，到可以使用數字證書的所有領域。後記：由於涉及的內容比較多，筆者知識和能力有限，就先寫這些，後面根據能力再繼續補充，請大家多提出寶貴意見。文中參考了很多網上的好文章，有問題請留言。
參考文獻：