Apache HTTP Server 版本2.2
Apache HTTP Server 版本2.2
標準的好處就是你有充足的選擇。如果確實不喜歡現(xiàn)存的標準，你只需等待來年發(fā)布一個你喜歡的新標準。
-- A. Tanenbaum, "Introduction to Computer Networks"
作為緒論，本文針對的是熟悉Web、HTTP、Apache的讀者而不是安全方面的專家，它不是SSL協(xié)議的權(quán)威性指南，不討論在一個組織中管理證書的特殊技術(shù)，也沒有重要的法定專利聲明及摘錄和引用限制。但是，本文會通過綜合講述各種概念、定義和例子，給mod_ssl的使用者提供背景資料，作為更深入探索的起點。
這里的內(nèi)容主要是來源于Introducing SSL and Certificates using SSLeay并經(jīng)過作者Frederick J. Hirsch許可。此文由 Open Group Research Institute于1997年夏，發(fā)表在Web Security: A Matter of Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997，肯定意見請反饋給Frederick Hirsch(原作者)，反對意見請反饋給Ralf S. Engelschall(mod_ssl的作者)。
要理解SSL就必須理解密碼系統(tǒng)、消息摘要函數(shù)(單向或散列函數(shù))和數(shù)字簽名，這些技術(shù)是許多文獻所討論的主題(比如[AC96)，提供了保密性、完整性和認證的基礎(chǔ)。
假設(shè)Alice想給她的銀行發(fā)一個消息以劃轉(zhuǎn)資金，并希望這個消息是保密的，因為其中含有她的帳號和劃轉(zhuǎn)金額等信息。一種方案是使用密碼系統(tǒng)，將要傳輸?shù)男畔⑥D(zhuǎn)變?yōu)榧用苄问剑瑥亩荒転橄Ｍx懂的人讀懂。一旦加密為這種形式，這條消息也許只能用一個密鑰來破譯，如果沒有，那么這條信息毫無用處，因為好的密碼系統(tǒng)可以使破譯難度高到入侵者認為原文不值得他們花費那么大的努力。
密碼系統(tǒng)有兩大類：常規(guī)的和公共密鑰。
任何人都可以用公鑰加密一條消息，而僅允許私鑰的持有者閱讀。如此，Alice就可能使用公鑰加密其保密消息，發(fā)送給私鑰的持有者(銀行)，只有銀行能夠?qū)λ饷堋?/p>
雖然Alice可能加密其消息使它稱為私有的，但仍應(yīng)注意到某些人可能會篡改或替換其原始消息，以劃轉(zhuǎn)資金到他們自己的帳戶。一種保證Alice消息完整性的方法是同時發(fā)一個其消息的簡單摘要給銀行，供銀行與消息本身比對，如果相符則消息正確。
這樣的方法被稱為消息摘要、單向函數(shù)或散列函數(shù)。消息摘要用于對較大而且變長的消息建立較短而且等長的一種表述，其設(shè)計使將摘要還原成消息極其困難，而且對兩個不同的消息幾乎不可能生成相同的摘要，從而排除了替換一個消息為另一個而維持相同摘要的可能性。
Alice面臨的另一個挑戰(zhàn)是要保證摘要發(fā)送到銀行的安全，如此，才能確保消息的完整性。
一種解決方法是在摘要中包含數(shù)字簽名。
當Alice發(fā)送消息到銀行，銀行需要確認此消息的確是她發(fā)送的，而不是入侵者盜用其帳號。為此，可以在消息中包含一個由Alice建立的數(shù)字簽名。
數(shù)字簽名是以加密的消息摘要和其他信息(比如一個流水號)以及發(fā)送者的私有密鑰建立的。雖然任何人都可能用公共密鑰解密簽名，但是只有簽發(fā)者知道其私有密鑰，也就是，只有密鑰的持有者才能簽發(fā)。包含在簽名中的摘要只對該消息有效，以確保沒有人可以改變摘要而保持簽名不變。
為了避免簽名日后被入侵者破譯和再利用，簽名包含有一個流水號。如此，萬一(只是假設(shè))Alice并沒有發(fā)送此消息，雖然她可能真的簽發(fā)過，銀行可以免遭其欺詐性指控。
雖然Alice可能已經(jīng)發(fā)送了一個保密的消息給銀行，簽了名，并可以保證消息的完整性，但是她仍然需要確認她的確是在和那個銀行通訊，也就是說，她需要確認她用的公共密鑰的確對應(yīng)于銀行用的私有密鑰。同樣，銀行也需要驗證此消息的簽名的確對應(yīng)于Alice的簽名。
如果各部分有驗證其余部分一致性的證書，以確認公共密鑰，并是由一個可以信任的代理所簽發(fā)的，那么他們雙方都可以肯定其通訊對象的身份。這個可以信任的代理稱為證書機構(gòu)(Certificate Authority)，其證書用于認證。
與一個公共密鑰關(guān)聯(lián)的證書有一個主題，即一個個體或者服務(wù)器或者其他實體的真實身份，如表1所示。主題中的信息包含身份信息(識別名[Distinguished Name])和公共密鑰，還包括發(fā)布此證書的證書機構(gòu)的名稱和簽名以及證書的有效期限，還可能會有證書機構(gòu)監(jiān)管者信息和流水號等附加信息。
| 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)。
| 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 |
證書機構(gòu)可能會定義規(guī)定哪些識別名是可選的，而哪些是必須的一個規(guī)范，還可能對項的內(nèi)容和證書使用人數(shù)有所要求。比如，一個Netscape瀏覽器要求證書中的Common Name項必須是服務(wù)器名稱，此名稱可以是服務(wù)器域名的通配模式，形如：*.snakeoil.com 。
證書的二進制形式用ASN.1記號法[X208] [PKCS]表示，記號法定義了如何表示內(nèi)容，編碼規(guī)則定義了如何將信息轉(zhuǎn)變成二進制形式。證書的二進制編碼使用了基于更通用的基本編碼規(guī)則(Basic Encoding Rules[BER])的識別名編碼規(guī)則(Distinguished Encoding Rules[DER])。為了在不能處理二進制的情況下進行傳輸，二進制形式用Base64編碼方式[MIME]轉(zhuǎn)換成ASCII形式，其編碼結(jié)果是以開始和結(jié)束符號分隔的若干的行，稱為PEM形式(其名稱來源于"Privacy Enhanced Mail")，如下所示：
-----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-----
證書機構(gòu)在授予證書前會驗證證書的申請信息，以確認密鑰對中私有密鑰的持有實體。比如：如果Alice申請一個個人證書，則證書機構(gòu)首先會確認Alice的確是申請證書的那個人。
一個證書機構(gòu)也可能給另一個證書機構(gòu)授予證書。所以，Alice可能需要檢查證書的授予者，及其父授予者，直到找到一個她所信任的。她可以只信任由一個有限的授予者鏈所授予的證書，以減小這個鏈中"劣質(zhì)"證書帶來的風險。
如前所述，每個證書要求其授予者指定證書主題中實體的有效性，直到最高一級的證書機構(gòu)。這樣就產(chǎn)生一個問題：最高一級的證書機構(gòu)沒有授予者，那么誰為它的證書作擔保呢？僅在這種情況下，此證書是"自簽名的"，即證書的授予者和主題中的一樣，所以，必須對自簽名的證書備加注意。頂級機構(gòu)廣泛發(fā)布的公共密鑰可以減小信任這個密鑰所帶來的風險--這顯然比其他某個人發(fā)布密鑰并宣稱他是證書機構(gòu)要安全一些。瀏覽器被默認地配置為信任著名的證書機構(gòu)。
許多公司是專業(yè)證書機構(gòu)，如Thawte和VeriSign，提供如下服務(wù)：
自己建立一個證書機構(gòu)也是可能的，雖然在Internet環(huán)境中有風險，但在驗證個體或服務(wù)器較容易的Intranet環(huán)境中，會很有用。
建立一個證書機構(gòu)需要一個堅強的監(jiān)管、技術(shù)和管理體系。證書機構(gòu)不僅僅是授予證書，還必須管理證書的有效期和更新，并維護一個已授予的但已經(jīng)失效的證書列表(作廢證書列表[Certificate Revocation Lists，或CRL])。比如，Alice作為公司雇員有資格申請證書，又如，Alice離開公司后需要作廢此證書等。由于憑證書可以到處通行無阻，所以不可能從證書本身看出已經(jīng)作廢，因此，驗證證書的有效性就必須查作廢證書列表(而這通常不是自動處理的一部分)。
如果使用了一個瀏覽器沒有默認配置的證書機構(gòu)，則必須加載這個證書機構(gòu)的證書進入瀏覽器，使瀏覽器可以驗證由這個證書機構(gòu)簽發(fā)的服務(wù)器證書。這樣做是有風險的，因為一旦加載，瀏覽器會接受由這個證書機構(gòu)簽發(fā)的所有證書。
安全套接字層協(xié)議是位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議(如TCP/IP)和應(yīng)用程序協(xié)議層(如HTTP)之間的一種協(xié)議層。SSL通過互相認證、使用數(shù)字簽名確保完整性、使用加密確保私密性，以實現(xiàn)客戶端和服務(wù)器之間的安全通訊。
這個協(xié)議被設(shè)計為支持許多用于密碼、摘要和簽名的特定算法，允許因各種目的對特定的服務(wù)器選擇算法，并允許采用新算法以得其利。其選擇的協(xié)商操作發(fā)生在客戶和服務(wù)器建立協(xié)議對話的開始階段。
| 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協(xié)議有多種版本。SSL3.0的一個優(yōu)點是增加了對加載證書鏈的支持，以允許服務(wù)器在發(fā)給瀏覽器的授予者證書上附加一個服務(wù)器證書。鏈的加載也允許瀏覽器驗證服務(wù)器證書，即使對此授予者的證書機構(gòu)證書并沒有安裝，因為它已經(jīng)包含在這個證書鏈中了。SSL3.0目前正由Internet Engineering Task Force(IETF)研發(fā)，是傳輸層安全[TLS]協(xié)議標準的基礎(chǔ)。
SSL會話在客戶端和服務(wù)器的握手過程之后建立，如Figure 1所示，其過程可能因服務(wù)器是否配置為支持服務(wù)器證書和是否要求有客戶證書有所不同。雖然存在密碼信息管理需要額外握手操作的情況，本文只說明其中有共性的部分，參見所有可能情況下的SSL規(guī)范。
SSL會話一旦建立就可能是可重用的，以避免在初始會話時的性能損失和許多步驟的重復(fù)。為此，服務(wù)器為其后的連接緩存了為每個SSL會話設(shè)定的唯一的會話標志，以減少握手操作(直到服務(wù)器緩存中的會話標志過期為止)。
Figure 1: Simplified SSL
Handshake Sequence
客戶端和服務(wù)器的握手過程如下所示：
第一步的密碼組協(xié)商，允許客戶端和服務(wù)器選擇一個共同支持的密碼組。SSL3.0協(xié)議規(guī)范定義了31個密碼組。密碼組由以下各部分組成：
此三個組成部分說明如下。
密鑰交換法指明如何在客戶端和服務(wù)器的數(shù)據(jù)傳輸中使用共享的對稱密鑰。SSL2.0僅使用RSA密鑰交換，而SSL3.0可以在啟用證書時，選擇使用包括RSA的多種密鑰交換算法，以及無須證書和客戶端-服務(wù)器先期通訊的Diffie-Hellman密鑰交換法。
密鑰交換法的一個變數(shù)是數(shù)字簽名(可用可不用)，如果用，用哪一種。私有密鑰配合簽名可以確保在生成共享密鑰[AC96, p516]的信息交換過程中抵御攻擊。
SSL使用在前面加密對話消息中有所講述的常規(guī)密碼算法(對稱密碼)，可以有包括不加密在內(nèi)的九種選擇：
這里的"CBC"是Cipher Block Chaining，指在加密當前塊時會用到先前已經(jīng)加密的部分文本；"DES"是Data Encryption Standard[AC96, ch12]，有多個變種(包括DES40和3DES_EDE)；"Idea"是現(xiàn)有最好的最堅強的加密算法之一；"RC2"是RSADSI[AC96, ch13]的專屬的算法。
摘要函數(shù)指明對一個記錄單元如何建立摘要。SSL有如下支持：
消息摘要用于建立加密的消息認證碼(MAC)，與消息本身一同發(fā)送，以確保消息完整性并抵御還原攻擊。
握手序列使用三個協(xié)議：
這些協(xié)議和應(yīng)用協(xié)議的數(shù)據(jù)用 SSL Record Protocol 進行封裝，如Figure 2所示，在不檢查數(shù)據(jù)的較底層的協(xié)議中傳輸。封裝協(xié)議對其底層協(xié)議來說是未知的。
Figure 2: SSL Protocol Stack
SSL控制協(xié)議對記錄協(xié)議的封裝，使一個正在進行的對話在重協(xié)商其控制協(xié)議后得以安全地進行傳輸。如果事先沒有建立對話，則會使用Null密碼組，也就是說，在建立對話以前，不使用密碼，且消息沒有完整性摘要。
SSL記錄協(xié)議，如Figure 3所示，用于客戶端和服務(wù)器之間的傳輸應(yīng)用和SSL控制數(shù)據(jù)，可能把數(shù)據(jù)分割成較小的單元，或者組合多個較高層協(xié)議數(shù)據(jù)為一個單元。在使用底層可靠傳輸協(xié)議傳輸數(shù)據(jù)單元之前，它可能會對這些單元進行壓縮、附著摘要簽名和加密(注意：目前所有主要SSL的實現(xiàn)都缺乏對壓縮的支持)。
Figure 3: SSL Record Protocol
SSL的一個常見的用途是保護瀏覽器和網(wǎng)絡(luò)服務(wù)器之間的網(wǎng)絡(luò)HTTP通訊，但這并排除應(yīng)用于不加保護的HTTP。其方法主要是，對普通HTTP加以SSL保護(稱為HTTPS)，但有一個重要的區(qū)別：它使用URL類型https而不是http ，而且使用不同的服務(wù)器端口(默認的是443)。mod_ssl為Apache網(wǎng)絡(luò)服務(wù)器提供的功能主要就是這些了...
Applied Cryptography, 2nd Edition, Wiley, 1996. See http://www.counterpane.com/ for various other materials by Bruce Schneier.
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.
The Directory - Authentication Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509.
Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. See for instance http://ietf.org/rfc/rfc2045.txt.
The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
The SSL Protocol Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
The TLS Protocol Version 1.0, 1999. See http://ietf.org/rfc/rfc2246.txt.