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
用戶端和伺服器的握手過程如下所示：
- 協商用于資料傳輸的密碼組
- 建立并共享用戶端和伺服器的會話密鑰
- 可選的用戶端對伺服器的認證
- 可選的伺服器對用戶端的認證
第一步的密碼組協商，允許用戶端和伺服器選擇一個共同支援的密碼組。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 [X509]
- ITU-T Recommendation X.509, The Directory - Authentication Framework. See for instance [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