[SSL/TLS] SSL/TLS協議綜合總結

密碼技術

要了解SSL協議，首先要了解：加密演算法、訊息摘要演算法（又稱為雜湊演算法Hash），數字簽名等概念。這些技術每個都可以寫出一整本的書，它們結合在一起，提供了保密性、完整性和身份驗證的功能。

加密演算法

設想：ALICE想發訊息給她的銀行要匯出一筆款。ALICE希望這些訊息是保密的，因為這裡麵包括她的帳戶資料和匯款金額。一種辦法是使用加密演算法，這種技術將她要傳遞的訊息變成經過加密的密文，直接銀行解密才可以被讀取。如果採用這種形式，訊息只能被一個金鑰所加密。沒有這個金鑰，訊息就是無用的。一個良好的加密演算法，可以使入侵者面臨無法克服困難來解密原文。

有兩種加密演算法系列：傳統加密演算法（對稱加密）和公鑰加密演算法（非對稱加密）

傳統加密演算法

也稱為對稱加密，需要傳送者和接收者共享一個金鑰：同時用於加密和解密的資訊。只要金鑰是保密的，除了收件人和發件人外沒有人可以閱讀該訊息。如果Alice和銀行知道這個金鑰，那麼他們可以給對方傳送的經過此金鑰加密的訊息。這種演算法的主要任務在於傳送者和接收者如何共享一個金鑰，同時確保沒有第三方知道這個金鑰，如果多人之間傳遞訊息，如何保證這麼多金鑰的安全，就是一個棘手的問題。

公鑰加密演算法

也被稱為非對稱加密技術，通過使用2個金鑰（其中一個可以解密另外一個加密的訊息），解決了加密金鑰交換的問題。 如果用其中的一個金鑰用於加密資訊，必須使用另外一個金鑰來解密。這樣就有可能獲得簡單地釋出一個金鑰（公鑰），並使用未釋出的金鑰（私鑰）來接受經過公鑰加密的訊息。

任何人都可以使用公共金鑰加密訊息，但只有私鑰擁有者將能夠讀取它。這樣，ALICE可以在傳送需要保密的匯款訊息給銀行的時候，可以使用銀行的金鑰對中的公鑰來對這個訊息進行加密，而只有銀行可以使用他們自己保管的私鑰來進行解密。

訊息摘要演算法

雖然ALICE可以加密她的訊息，但仍然有一個問題，就是有人可能會修改她發給銀行的訊息，並將ALICE的錢轉移到自己的帳戶上。為了保證ALICE訊息在傳遞過程中沒有被人篡改，可以讓她建立一個訊息的摘要和加密的訊息一起寄到銀行，銀行收到訊息後，將訊息和訊息的摘要做一個比較，如果訊息內容和摘要匹配，則就可以證明訊息傳遞過程中，沒有別人篡改。

像這樣的摘要被稱為訊息摘要， 單向函式或雜湊函式。訊息摘要用於建立一個簡短的固定長度，或可變長度的訊息。訊息摘要演算法被設計成為每個訊息產生一條獨立的資訊摘要。訊息摘要演算法的目的，就是讓人無法為兩條不同的訊息找到相同的訊息摘要，從而消除了使用一條摘要相同的訊息替換另外一條訊息的可能性。

另一個愛麗絲面臨的挑戰是找到一種方法，即使安全地將訊息摘要傳送到銀行;如果訊息摘要傳送過程不安全，銀行將無法判斷訊息是否就是來自ALICE。只有在訊息摘要能安全地傳送，才能夠使訊息的完整性被確定。

一個安全傳送訊息摘要的方式是使用數字簽名。

數字簽名

當Alice將訊息傳送給銀行，銀行需要確保訊息真正地是從她這裡發出的，以確保入侵者不能使用她的帳戶進行交易。簽名就是由ALICE為實現這一目的而建立的一個專門訊息。

數字簽名主要使用私鑰來加密訊息摘要和其他資訊，譬如一個序列號,雖然任何人都可以使用公鑰解密數字簽名，只有傳送方知道私鑰。這意味著，只有發件人可以簽署了該訊息。包含了資訊摘要的簽名表示這個簽名只對這個訊息有效，而且它確保了訊息的完整性，即這個訊息的傳送過程中沒人可以改變摘要並另外對它做簽名。

為了防止入侵者攔截，並在以後再次使用這個簽名，簽名包含一個唯一的序列號。這樣可以保證ALICE無法否認她曾經傳送過這條訊息，因為只有她可以簽名這條訊息（不可抵賴性）。

 

證書

雖然ALICE給銀行發出一條經過她個人私鑰簽名的訊息，並且可以確保她傳送的訊息是真實可靠的，但她依然要確保她的確是和銀行在通訊。這意味著她必須確保她使用的公鑰是銀行金鑰對中的公鑰，而不是入侵者的。同樣道理，銀行業也需要核實用於簽名該訊息的私鑰是屬於ALICE的。如何使銀行和ALICE能否核實對方的身份呢？

如果每個人的證書都由一個大家都信任的機構簽名，那麼每個人都可以驗證其他有該證書的人的身份。這種被大家都信任的機構，稱為認證中心（CA)，他們負責認證證書。

證書的內容

證書內容包括：公鑰和真實身份識別資訊，包括個人，伺服器或其他實體。如表1所示，主題資訊包括身份識別資訊（DN）和公鑰。它還包括認證和簽發的CA簽發這個證書的有效期，還可能有一些其他的資訊（或者成為擴充套件資訊），一般由CA自行定義使用的管理資訊，譬如序列號等。

表一：證書資訊

識別名DN是用來提供對某個特定背景下的身份，例如：某個人作為公司的一個僱員而擁有一個證書。識別名DN有X.509標準定義，包括它的欄位，欄位名和相應的縮寫表示。（如表2所示）

表二：識別名(DN)資訊

DN欄位	縮寫	說明	舉例
Common Name 通用名	CN	證書頒發物件名稱	CN=Joe Average
Organization or Company 組織或公司	O	頒發物件所屬單位	O=Snake Oil, Ltd.
Organizational Unit 部門	OU	所在單位部門	OU=Research Institute
City/Locality 城市	L	所在城市	L=Snake City
State/Province 省份	ST	所在省份	ST=Desert
Country 國家	C	國家程式碼，見ISO 3166-1 A2	C=XZ

證書頒發機構可以定義一個策略，指明哪些識別名欄位名是可選的，哪些是必需的。很多證書還對某些欄位的內容做出要求。例如，Netsacpe瀏覽器要求一個伺服器證書的CN能夠匹配萬用字元樣式的域名，例如：*.snakeoil.com。

證書的二進位制格式是使用了ASN.1（抽象語法標記）定義[X208] [ PKCS]。 這種表示法定義瞭如何指定編碼規則的內容和如何將資訊轉換成二進位制形式。證書的二進位制編碼使用了區分編碼規則Distinguished Encoding Rules (DER)，它是基本編碼規則Basic Encoding Rules (BER)的一個子集。對於那些不能採用二進位制的資訊傳遞，二進位制形式可以轉化為一個ASCII形式使用Base64編碼[MIME]。當證書放置在Begin和End分割線中的時候，這種編碼被稱為增強型安全私人郵件格式(PEM -"Privacy Enhanced Mail") 編碼的證書。

PEM編碼證書的樣例（snakioil.crt)

Example of a PEM-encoded certificate (snakeoil.crt)

-----BEGIN CERTIFICATE-----

MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx

FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG

A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv

cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz

bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL

MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h

a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl

cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN

AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB

gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b

vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa

lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV

HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB

gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt

2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7

dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==

-----END CERTIFICATE-----

證書頒發機構CA

通過在批准證書之前核實證書請求中的資訊，CA可以保證金鑰對的私鑰所有人的身份。舉例，如果Alice請求一個個人證書，證書頒發機構必須首先核實ALICE在證書申請中所提交的個人資訊和資料。

證書鏈

CA機構有時也會為另外一家CA機構頒發證書。當檢查證書的時候，ALICE可能需要檢查每一級證書的父親證書，一直找到一個她所能信任的證書為止。為了降低她在檢查證書鏈中遇到一個“壞”證書的風險，ALICE可能會設定可信證書鏈的深度。

建立一個根CA

如前所述，每個證書需要發行者來宣告證書擁有者身份的有效性，一直到最頂層CA。 這就產生了一個問題：誰來保證最頂層CA的權威性，而這個CA是沒有發行者。在這個獨特的情況下，證書採用一種“自簽名”的方式，所以證書的發行者就是證書擁有者自己。瀏覽器會將一些知名的CA配置成可信，將他們的根證書安裝到自己的受信根證書列表中，但如果要自己新增信任的自簽名證書，就需要特別當心。

一些公司，例如GeoTrust 和 Verisign已經建立了他們自己的證書頒發機構。這些公司提供以下服務：

• 驗證證書請求
• 處理證書申請
• 發行和管理證書

使用者也可以建立自己的證書頒發機構。雖然在網際網路上存在比較大的風險，但它在企業內網中是很有用的，可以輕鬆地驗證個人和伺服器的身份。

證書管理

建立一個證書機構需要有堅實的行政，技術和管理框架。證書頒發機構不僅頒發證書，他們還要管理好證書，也就是說，他們確定證書在多久的時間內仍然有效，他們有一個列表，裡面列舉了過去頒發的，但已經不再有效的證書，並且不斷更新這個列表（證書吊銷清單，或CRL）。

例如：ALICE曾經作為公司的僱員獲得一個證書，但她現在已經離開公司了，她的證書就需要被吊銷。由於證書只在稽核完當事人身份後被簽發，並且被傳遞給需要和當事人溝通的同事，從證書本身告訴去告知它已經被吊銷了是不可能的。因此要檢查一個證書是否有效，就必須聯絡CA機構獲取證書吊銷清單CRL，而這通常是無法自動完成的。

注意：

如果你需要使用一個不是瀏覽器預設信任的CA機構，就必須將這個CA的根證書裝入瀏覽器的可信根證書列表，使瀏覽器可以識別這個CA頒發的伺服器證書，但這樣做是非常危險的，因為一旦載入了這個CA的根證書，瀏覽器將接受所有由這個根證書籤發的伺服器證書。

Secure Sockets Layer(SSL) 安全套接字層

SSL是工作在面對連線網路層（如TCP層）和應用層（HTTP層）之間的協議層。SSL層協議通過為客戶端和伺服器提供雙向認證，對隱私資料的加密，和用數字簽名來保證資料完整性，從而提供了一個安全的通訊通道。

本協議被設計為支援一系列制定的演算法用於加密，資料摘要和簽名。這允許對特定伺服器的演算法選擇建立在法律、出口和其他問題的基礎上，並且使協議能夠利用新的演算法。在客戶機和伺服器試圖建立一個對話的時候，會協商演算法。

表4：SSL協議的版本

如表4所示，有多個SSL協議的版本，其中SSL3.0的一個優勢就是它增加了對證書鏈載入的支援。這項功能使伺服器可以將自己的伺服器證書和發行者的證書一起傳給瀏覽器。證書鏈的載入，使得客戶機即使沒有安裝過伺服器的中間證書，也可以來驗證伺服器證書的有效性，因為伺服器的中間證書被放在證書鏈中一起傳送給了客戶機。SSL 3.0是安全傳輸層TLS協議的基礎，這項協議正由IETF負責制訂開發。

建立會話

客戶機和伺服器同構一種“握手”次序來建立SSL會話，如圖1.這個握手次序可能會有所不同，這取決於伺服器是否配置成提供伺服器證書，或者需要客戶機提供客戶證書。雖然在其他情況下存在因對密碼管理要求不同而不同的“握手”步驟，詳見各種SSL協議規範，但本文總結了一個基本的握手次序。

 

圖1：基本握手次序

注意：

伺服器為每個SSL會話分配一個唯一的會話識別符號並快取在伺服器和客戶端（直到會話識別符號過期），使客戶在下次連線的時候減少了握手的時間。

在握手序列中的被客戶端和伺服器使用的各項要素，如下列所示：

1. 協商資料傳輸中使用的加密套接字。
2. 在客戶機和伺服器中建立並共享一個會話金鑰。
3. 可選的伺服器端身份認證
4. 可選的客戶端身份認證

首先，加密套接字協商，允許客戶端和伺服器選擇一個他們都是支援的加密套接字方式。SSL3.0協議定義了31種加密套接字方式，每一種安全套接字由下列部分組成：

• 金鑰交換方法
• 資料加密傳輸
• 建立訊息認證碼（MAC）的訊息摘要

這3個要素將在下面的幾節中詳細描述。

 

金鑰交換方法

金鑰交換方法定義在客戶端和伺服器之間共享雙方都同意的，被用於應用資料傳輸的對稱加密的金鑰。SSL2.0協議只適用RSA金鑰交換方式，而SSL3.0不僅支援RSA金鑰交換（在使用證書的情況下），還支援Diffie-Hellman金鑰交換（在沒有使用證書或者沒有客戶端和伺服器之間通訊金鑰之前的情況下。）

在決定金鑰交換方式中的變數是選擇是否需要數字簽名和使用什麼樣的簽名。使用私鑰簽名可以防止在交換共享金鑰的時候，遭受中間人攻擊。

資料加密傳輸

SSL在加密會話中的訊息時採用傳統的對稱加密方法，有9種加密方式可以選擇，包括也可以選擇不加密。

• No encryption
• Stream Ciphers
  • RC4 with 40-bit keys
  • RC4 with 128-bit keys
• CBC Block Ciphers
  • RC2 with 40 bit key
  • DES with 40 bit key
  • DES with 56 bit key
  • Triple-DES with 168 bit key
  • Idea (128 bit key)
  • Fortezza (96 bit key)

“CBC” 是Cipher Block Chaining的縮寫，意思為密碼分組連結，表示前一段加密後的密文被用當前段的加密中使用。

"DES" 是指Data Encryption Standard，有一系列不同的變數。包括DES40和3DES_EDE

"Idea" 是目前最好的，也是加密強度最高的演算法。

"RC2" 是RSA DSI專用的演算法。

摘要函式

對資訊摘要函式的選擇決定了如何從一個記錄單元建立一個摘要。SSL支援以下模式：

• 無摘要
• 128位雜湊的MD5
• 160位的安全雜湊演算法（SHA-1）

訊息摘要是用來建立一個訊息認證碼（MAC），MAC是與訊息加密，來核實訊息的完整性和保護訊息不受回放式攻擊。

握手次序協議

握手次序使用三個協議：

• SSL Handshake Protocol. SSL握手協議執行客戶端和伺服器SSL會話的建立過程。
• SSL Change Cipher Spec Protocol .SSL更改密碼協議負責協商會話用的密碼套接字。
• SSL Alert Protocol.SSL告警協議負責在客戶端和伺服器間傳遞SSL錯誤資訊。

這些協議以及應用協議資料，都被SSL記錄協議封裝，如圖2所示。封裝好的資料被不檢查資料的低一層的協議傳遞。下一層的協議對封裝協議來說是未知的。

 

圖2：SSL協議棧

SSL控制協議對記錄協議的封裝，使一個正在進行的會話在需要重新協商時，控制協議能夠被安全地傳輸。如果沒有前一個會話，則使用空的密碼套接字，也就是說，在會話建立以前，不會使用密碼也沒有驗證完整性的訊息摘要。

資料傳輸

SSL記錄協議,如圖3所示 , 用於在客戶端和伺服器之間傳遞SSL控制協議和應用層資料，必需將這些資料分割成較小的單元，或者將多個較高層協議資料合併為一個單元。它可能會在將這些資料傳遞到下一層可靠的傳遞協議前將這些資料壓縮、加密和附加一個摘要簽名。（注：目前主流的SSL都沒有對壓縮的支援）。

 

圖3：SSL記錄協議

安全HTTP通訊

SSL最常見的一項用途就是在瀏覽器和WEB伺服器之間加密安全的WEB HTTP通訊。使用加密的HTTP（稱為HTTPS），即在SSL協議上使用HTTP協議，並沒有排除HTTP協議，不過在URL地址中使用HTTPS來替換原來的HTTP，並使用另外一個伺服器埠（HTTPS預設使用443，HTTP使用80）。