SSL/TLS高強度加密：緒論

文章目錄

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

SSL/TLS高強度加密：緒論

標準的好處就是你有充足的選擇。如果確實不喜歡現存的標準，你只需等待來年發布一個你喜歡的新標準。

-- A. Tanenbaum, "Introduction to Computer Networks"

作為緒論，本文針對的是熟悉Web、HTTP、Apache的讀者而不是安全方面的專家，它不是SSL協議的權威性指南，不討論在一個組織中管理憑證的特殊技術，也沒有重要的法定專利聲明及摘錄和引用限制。但是，本文會通過綜合講述各種概念、定義和例子，給mod_ssl的使用者提供背景資料，作為更深入探索的起點。

這裡的內容主要是來源於Introducing SSL and Certificates using SSLeay並經過作者Frederick J. Hirsch許可。此文由 Open Group Research Institute於1997年夏，發表在Web Security: A Matter of Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997，肯定意見請反饋給Frederick Hirsch(原作者)，反對意見請反饋給Ralf S. Engelschall(mod_ssl的作者)。

密碼技術

要理解SSL就必須理解密碼系統、訊息摘要函數(單向或散列函數)和數位簽章，這些技術是許多文獻所討論的主題(比如[AC96)，提供了保密性、完整性和認證的基礎。

密碼系統

假
設Alice想給她的銀行發一個訊息以劃轉資金，並希望這個訊息是保密的，因為其中含有她的帳號和劃轉金額等資訊。一種方案是使用密碼系統，將要傳輸的信
息轉變為加密形式，從而只能為希望他讀懂的人讀懂。一旦加密為這種形式，這條訊息也許只能用一個密鑰來破譯，如果沒有，那麼這條資訊毫無用處，因為好的密
碼系統可以使破譯難度高到入侵者認為原文不值得他們花費那麼大的努力。

密碼系統有兩大類：常規的和公用密鑰。

常規密碼

又
稱為對稱密碼，需要寄件者和接收者共同持有一個密鑰：一小段用來加密和解密的秘密資訊。如果這個密鑰是保密的，那麼這條訊息除了寄件者和接受者以外可能沒
有人可以閱讀。如果Alice和銀行共同持有一個密鑰，則可以互相發送保密資訊。但是，私人通訊密鑰的選擇行為本身，卻可能不是無懈可擊的。

公用密鑰密碼

又稱為不對稱密碼，定義了一種使用兩個密鑰的演算法以解決金鑰交換問題，一個密鑰用於加密，另一個用於解密，從而使簡單公布一個密鑰(公用的密鑰，簡稱：公開金鑰)而保留其他的(私人的密鑰，簡稱：私密金鑰)以接收保密訊息成為可能。

任何人都可以用公開金鑰加密一條訊息，而僅允許私密金鑰的持有人閱讀。如此，Alice就可能使用公開金鑰加密其保密訊息，發送給私密金鑰的持有人(銀行)，只有銀行能夠對它解密。

訊息摘要

雖然Alice可能加密其訊息使它稱為私人的，但仍應注意到某些人可能會篡改或替換其原始訊息，以劃轉資金到他們自己的帳戶。一種保證Alice訊息完整性的方法是同時發一個其訊息的簡單摘要給銀行，供銀行與訊息本身比對，如果相符則訊息正確。

這樣的方法被稱為訊息摘要、單向函數或散列函數。訊息摘要用於對較大而且變長的訊息建立較短而且等長的一種表述，其設計使將摘要還原成訊息極其困難，而且對兩個不同的訊息幾乎不可能產生相同的摘要，從而排除了替換一個訊息為另一個而維持相同摘要的可能性。

Alice面臨的另一個挑戰是要保證摘要發送到銀行的安全，如此，才能確保訊息的完整性。

一種解決方案是在摘要中包含數位簽章。

數位簽章

當Alice發送訊息到銀行，銀行需要確認此訊息的確是她發送的，而不是入侵者盜用其帳號。為此，可以在訊息中包含一個由Alice建立的數位簽章。

數位簽章是以加密的訊息摘要和其他資訊(比如一個流水號)以及寄件者的私人密鑰建立的。雖然任何人都可能用公用密鑰解密簽名，但是只有簽發者知道其私人密鑰，也就是，只有密鑰的持有人才能簽發。包含在簽名中的摘要只對該訊息有效，以確保沒有人可以改變摘要而保持簽名不變。

為了避免簽名日後被入侵者破譯和再利用，簽名包含有一個流水號。如此，萬一(只是假設)Alice並沒有發送此訊息，雖然她可能真的簽發過，銀行可以免遭其欺詐性指控。

認證

雖然Alice可能已經發送了一個保密的訊息給銀行，簽了名，並可以保證訊息的完整性，但是她仍然需要確認她的確是在和那個銀行通訊，也就是說，她需要確認她用的公用密鑰的確對應於銀行用的私人密鑰。同樣，銀行也需要驗證此訊息的簽名的確對應於Alice的簽名。

如果各部分有驗證其餘部分一致性的認證，以確認公用密鑰，並是由一個可以信任的代理所簽發的，那麼他們雙方都可以肯定其通訊對象的身份。這個可以信任的代理稱為認證機構(Certificate Authority)，其認證用於認證。

認證的內容

與一個公用密鑰關聯的認證有一個主題，即一個個體或者伺服器或者其他實體的真實身份，如表1所示。主題中的資訊包含身份資訊(識別名[Distinguished Name])和公用密鑰，還包括髮布此認證的認證機構的名稱和簽名以及認證的有效期間限，還可能會有認證機構監管者資訊和流水號等附加資訊。

表 1: Certificate Information

Subject	Distinguished Name, Public Key
Issuer	Distinguished Name, Signature
Period of Validity	Not Before Date, Not After Date
Administrative Information	Version, Serial Number
Extended Information	Basic Constraints, Netscape Flags, etc.

識別名用於在一個特定的上下文中指明身份，比如，一個個體可能有一個個人認證，同時還有一個其僱傭者的認證。X.509標準[X509]中定義了識別名的各個項及其名稱和縮寫(見表2)。

表 2: Distinguished Name Information

DN Field	Abbrev.	Description	Example
Common Name	CN	Name being certified	CN=Joe Average
Organization or Company	O	Name is associated with this organization	O=Snake Oil, Ltd.
Organizational Unit	OU	Name is associated with this organization unit, such as a department	OU=Research Institute
City/Locality	L	Name is located in this City	L=Snake City
State/Province	ST	Name is located in this State/Province	ST=Desert
Country	C	Name is located in this Country (ISO code)	C=XZ

認證機構可能會定義規定哪些識別名是可選的，而哪些是必須的一個規範，還可能對項的內容和認證使用人數有所要求。比如，一個Netscape瀏覽器要求認證中的Common Name項必須是伺服器名稱，此名稱可以是伺服器網域名稱的通配模式，形如：*.snakeoil.com 。

認證的二進位形式用ASN.1記號法[X208] [PKCS]
表示，記號法定義了如何表示內容，編碼規則定義了如何將資訊轉變成二進位形式。認證的二進位編碼使用了基於更通用的基本編碼規則(Basic
Encoding Rules[BER])的識別名編碼規則(Distinguished Encoding
Rules[DER])。為了在不能處理二進位的情況下進行傳輸，二進位形式用Base64編碼方式[MIME]轉換成ASCII形式，其編碼結果是以開始和結束符號分隔的若干的行，稱為PEM形式(其名稱來源於"Privacy Enhanced Mail")，如下所示：

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-----

認證機構

認證機構在授予認證前會驗證認證的申請資訊，以確認金鑰組中私人密鑰的持有實體。比如：如果Alice申請一個個人認證，則認證機構首先會確認Alice的確是申請認證的那個人。

憑證鏈結

一個認證機構也可能給另一個認證機構授予認證。所以，Alice可能需要檢查認證的授予者，及其父授予者，直到找到一個她所信任的。她可以只信任由一個有限的授予者鏈所授予的認證，以減小這個鏈中"劣質"認證帶來的風險。

建立頂級CA

如
前所述，每個認證要求其授予者指定認證主題中實體的有效性，直到最高一級的認證機構。這樣就產生一個問題：最高一級的認證機構沒有授予者，那麼誰為它的證
書作擔保呢？僅在這種情況下，此認證是"自簽名的"，即認證的授予者和主題中的一樣，所以，必須對自簽名的認證備加註意。頂級機構廣泛發布的公用密鑰可以
減小信任這個密鑰所帶來的風險--這顯然比其他某個人發布密鑰並宣稱他是認證機構要安全一些。瀏覽器被預設地配置為信任著名的認證機構。

許多公司是專業認證機構，如Thawte和VeriSign，提供如下服務：

• 驗證認證的申請
• 處理認證的申請
• 授予和管理憑證

自己建立一個認證機構也是可能的，雖然在Internet環境中有風險，但在驗證個體或伺服器較容易的Intranet環境中，會很有用。

認證的管理

建
立一個認證機構需要一個堅強的監管、技術和管理體系。認證機構不僅僅是授予認證，還必須管理憑證的有效期間和更新，並維護一個已授予的但已經失效的認證列表
(作廢認證列表[Certificate Revocation
Lists，或CRL])。比如，Alice作為公司僱員有資格申請認證，又如，Alice離開公司後需要作廢此認證等。由於憑認證可以到處通行無阻，所
以不可能從認證本身看出已經作廢，因此，驗證認證的有效性就必須查作廢認證列表(而這通常不是自動處理的一部分)。

說明

如果使用了一個瀏覽器沒有預設配置的認證機構，則必須載入這個認證機構的認證進入瀏覽器，使瀏覽器可以驗證由這個認證機構簽發的伺服器憑證。這樣做是有風險的，因為一旦載入，瀏覽器會接受由這個認證機構簽發的所有認證。

安全通訊端層(SSL)

安全通訊端層協議是位於可靠的連線導向的網路層協議(如TCP/IP)和應用程式協議層(如HTTP)之間的一種協議層。SSL通過互相認證、使用數位簽章確保完整性、使用加密確保私密性，以實現用戶端和伺服器之間的安全通訊。

這個協議被設計為支援許多用於密碼、摘要和簽名的特定演算法，允許因各種目的對特定的伺服器選擇演算法，並允許採用新演算法以得其利。其選擇的協商操作發生在客戶和伺服器建立協議對話的開始階段。

表 4: Versions of the SSL protocol

Version	Source	Description	Browser Support
SSL v2.0	Vendor Standard (from Netscape Corp.) [SSL2]	First SSL protocol for which implementations exists	- NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL
SSL v3.0	Expired Internet Draft (from Netscape Corp.) [SSL3]	Revisions to prevent specific security attacks, add non-RSA ciphers, and support for certificate chains	- NS Navigator 2.x/3.x/4.x - MS IE 3.x/4.x - Lynx/2.8+OpenSSL
TLS v1.0	Proposed Internet Standard (from IETF) [TLS1]	Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.	- Lynx/2.8+OpenSSL

如表4所
示，SSL協議有多種版本。SSL3.0的一個優點是增加了對載入憑證鏈結的支援，以允許伺服器在發給瀏覽器的授予者認證上附加一個伺服器憑證。鏈的載入也
允許瀏覽器驗證伺服器憑證，即使對此授予者的認證機構認證並沒有安裝，因為它已經包含在這個憑證鏈結中了。SSL3.0目前正由Internet
Engineering Task Force(IETF)研發，是傳輸層安全[TLS]協議標準的基礎。

會話的建立

SSL會話在用戶端和伺服器的握手過程之後建立，如Figure 1所示，其過程可能因伺服器是否配置為支援伺服器憑證和是否要求有客戶認證有所不同。雖然存在密碼資訊管理需要額外握手操作的情況，本文只說明其中有共性的部分，參見所有可能情況下的SSL規範。

說明

SSL會話一旦建立就可能是可重用的，以避免在初始會話時的效能損失和許多步驟的重複。為此，伺服器為其後的串連緩衝了為每個SSL會話設定的唯一的會話標誌，以減少握手操作(直到伺服器緩衝中的會話標誌到期為止)。

Figure 1: Simplified SSL
Handshake Sequence

用戶端和伺服器的握手過程如下所示：

1. 協商用於資料轉送的密碼組
2. 建立並共用用戶端和伺服器的工作階段金鑰
3. 可選的用戶端對伺服器的認證
4. 可選的伺服器對用戶端的認證

第一步的密碼組協商，允許用戶端和伺服器選擇一個共同支援的密碼組。SSL3.0協議規範定義了31個密碼組。密碼組由以下各部分組成：

• 金鑰交換法
• 資料轉送密碼
• 建立訊息認證代碼(Message Authentication Code[MAC])的訊息摘要

此三個組成部分說明如下。

金鑰交換方法

金鑰交換法指明如何在用戶端和伺服器的資料轉送中使用共用的對稱金鑰。SSL2.0僅使用RSA金鑰交換，而SSL3.0可以在啟用認證時，選擇使用包括RSA的多種金鑰交換演算法，以及無須認證和用戶端-伺服器先期通訊的Diffie-Hellman金鑰交換法。

金鑰交換法的一個變數是數位簽章(可用可不用)，如果用，用哪一種。私人密鑰配合簽名可以確保在產生共用密鑰[AC96, p516]的資訊交換過程中抵禦攻擊。

資料轉送密碼

SSL使用在前面加密對話訊息中有所講述的常規密碼演算法(對稱密碼)，可以有包括不加密在內的九種選擇：

• 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[AC96, ch12]，有多個變種(包括DES40和3DES_EDE)；"Idea"是現有最好的最堅強的密碼編譯演算法之一；"RC2"是RSADSI[AC96,
ch13]的專屬的演算法。

摘要函數

摘要函數指明對一個記錄單元如何建立摘要。SSL有如下支援：

• No digest (Null choice)
• MD5, a 128-bit hash
• Secure Hash Algorithm (SHA-1), a 160-bit hash

訊息摘要用於建立加密的訊息認證碼(MAC)，與訊息本身一同發送，以確保訊息完整性並抵禦還原攻擊。

握手序列協議

握手序列使用三個協議：

• SSL Handshake Protocol ，以完成用戶端和伺服器之間對話的建立。
• SSL Change Cipher Spec Protocol ，以實際建立對話用密碼組的約定。
• SSL Alert Protocol ，在用戶端和伺服器之間傳輸SSL出錯訊息。

這些協議和應用協議的資料用 SSL Record Protocol 進行封裝，如Figure 2所示，在不檢查資料的較底層的協議中傳輸。封裝協議對其底層協議來說是未知的。

Figure 2: SSL Protocol Stack

SSL控制協議對記錄協議的封裝，使一個進行中的對話在重協商其控制協議後得以安全地進行傳輸。如果事先沒有建立對話，則會使用Null密碼組，也就是說，在建立對話以前，不使用密碼，且訊息沒有完整性摘要。

資料轉送

SSL記錄協議，如Figure 3所
示，用於用戶端和伺服器之間的傳輸應用和SSL控制資料，可能把資料分割成較小的單元，或者組合多個較高層協議資料為一個單元。在使用底層可靠傳輸協議傳
輸資料單元之前，它可能會對這些單元進行壓縮、附著摘要簽名和加密(注意：目前所有主要SSL的實現都缺乏對壓縮的支援)。

Figure 3: SSL Record Protocol

保護HTTP通訊

SSL的一個常見的用途是保護瀏覽器和網路伺服器之間的網路HTTP通訊，但這並排除應用於不加保護的HTTP。其方法主要是，對普通HTTP加以SSL保護(稱為HTTPS)，但有一個重要的區別：它使用URL類型https而不是http ，而且使用不同的伺服器連接埠(預設的是443)。mod_ssl為Apache網路伺服器提供的功能主要就是這些了...

References

[AC96]

Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley,
1996. See http://www.counterpane.com/ for various other materials by Bruce
Schneier.

[X208]

ITU-T Recommendation X.208, Specification of Abstract Syntax Notation
One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I.

[X509]

ITU-T Recommendation X.509, The Directory - Authentication
Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.

[PKCS]

Public Key Cryptography Standards (PKCS),
RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.

[MIME]

N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies, RFC2045.
See for instance http://ietf.org/rfc/rfc2045.txt.

[SSL2]

Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.

[SSL3]

Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol
Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.

[TLS1]

Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0,
1999. See http://ietf.org/rfc/rfc2246.txt