SSL/TLS高強(qiáng)度加密：緒論

標(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的作者)。

密碼技術(shù)

要理解SSL就必須理解密碼系統(tǒng)、消息摘要函數(shù)(單向或散列函數(shù))和數(shù)字簽名，這些技術(shù)是許多文獻(xiàn)所討論的主題(比如[AC96)，提供了保密性、完整性和認(rèn)證的基礎(chǔ)。

密碼系統(tǒng)

假設(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ī)的和公共密鑰。

常規(guī)密碼: 又稱為對(duì)稱密碼，需要發(fā)送者和接收者共同持有一個(gè)密鑰：一小段用來(lái)加密和解密的秘密信息。如果這個(gè)密鑰是保密的，那么這條消息除了發(fā)送者和接受者以外可能沒(méi)有人可以閱讀。如果Alice和銀行共同持有一個(gè)密鑰，則可以互相發(fā)送保密信息。但是，私有通訊密鑰的選擇行為本身，卻可能不是無(wú)懈可擊的。
公共密鑰密碼: 又稱為不對(duì)稱密碼，定義了一種使用兩個(gè)密鑰的算法以解決密鑰交換問(wèn)題，一個(gè)密鑰用于加密，另一個(gè)用于解密，從而使簡(jiǎn)單公布一個(gè)密鑰(公共的密鑰，簡(jiǎn)稱：公鑰)而保留其他的(私有的密鑰，簡(jiǎn)稱：私鑰)以接收保密消息成為可能。

任何人都可以用公鑰加密一條消息，而僅允許私鑰的持有者閱讀。如此，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ù)字簽名。

數(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ò)，銀行可以免遭其欺詐性指控。

證書(shū)

雖然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)證。

證書(shū)的內(nèi)容

與一個(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)等附加信息。

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

識(shí)別名用于在一個(gè)特定的上下文中指明身份，比如，一個(gè)個(gè)體可能有一個(gè)個(gè)人證書(shū)，同時(shí)還有一個(gè)其雇傭者的證書(shū)。X.509標(biāo)準(zhǔn)[X509]中定義了識(shí)別名的各個(gè)項(xiàng)及其名稱和縮寫(xiě)(見(jiàn)表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

證書(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")，如下所示：

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

證書(shū)機(jī)構(gòu)

證書(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è)人。

證書(shū)鏈

一個(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)。

建立頂級(jí)CA

如前所述，每個(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ù)：

驗(yàn)證證書(shū)的申請(qǐng)
處理證書(shū)的申請(qǐng)
授予和管理證書(shū)

自己建立一個(gè)證書(shū)機(jī)構(gòu)也是可能的，雖然在Internet環(huán)境中有風(fēng)險(xiǎn)，但在驗(yàn)證個(gè)體或服務(wù)器較容易的Intranet環(huán)境中，會(huì)很有用。

證書(shū)的管理

建立一個(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)處理的一部分)。

說(shuō)明

如果使用了一個(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ū)。

安全套接字層(SSL)

安全套接字層協(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)始階段。

表 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協(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ǔ)。

會(huì)話的建立

SSL會(huì)話在客戶端和服務(wù)器的握手過(guò)程之后建立，如Figure 1所示，其過(guò)程可能因服務(wù)器是否配置為支持服務(wù)器證書(shū)和是否要求有客戶證書(shū)有所不同。雖然存在密碼信息管理需要額外握手操作的情況，本文只說(shuō)明其中有共性的部分，參見(jiàn)所有可能情況下的SSL規(guī)范。

說(shuō)明

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é)商用于數(shù)據(jù)傳輸?shù)拿艽a組
建立并共享客戶端和服務(wù)器的會(huì)話密鑰
可選的客戶端對(duì)服務(wù)器的認(rèn)證
可選的服務(wù)器對(duì)客戶端的認(rèn)證

第一步的密碼組協(xié)商，允許客戶端和服務(wù)器選擇一個(gè)共同支持的密碼組。SSL3.0協(xié)議規(guī)范定義了31個(gè)密碼組。密碼組由以下各部分組成：

密鑰交換法
數(shù)據(jù)傳輸密碼
建立消息認(rèn)證代碼(Message Authentication Code[MAC])的消息摘要

此三個(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ò)程中抵御攻擊。

數(shù)據(jù)傳輸密碼

SSL使用在前面加密對(duì)話消息中有所講述的常規(guī)密碼算法(對(duì)稱密碼)，可以有包括不加密在內(nèi)的九種選擇：

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，指在加密當(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ù)

摘要函數(shù)指明對(duì)一個(gè)記錄單元如何建立摘要。SSL有如下支持：

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

消息摘要用于建立加密的消息認(rèn)證碼(MAC)，與消息本身一同發(fā)送，以確保消息完整性并抵御還原攻擊。

握手序列協(xié)議

握手序列使用三個(gè)協(xié)議：

SSL Handshake Protocol ，以完成客戶端和服務(wù)器之間對(duì)話的建立。
SSL Change Cipher Spec Protocol ，以實(shí)際建立對(duì)話用密碼組的約定。
SSL Alert Protocol ，在客戶端和服務(wù)器之間傳輸SSL出錯(cuò)消息。

這些協(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)有完整性摘要。

數(shù)據(jù)傳輸

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

保護(hù)HTTP通訊

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ù)器提供的功能主要就是這些了...

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.