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