SSL/TLS高強度加密：緒論 · Apache 2.2 中文官方文檔

# SSL/TLS高強度加密：緒論 > 標準的好處就是你有充足的選擇。如果確實不喜歡現存的標準，你只需等待來年發布一個你喜歡的新標準。 > > -- <cite class="calibre63">A. Tanenbaum</cite>, "Introduction to Computer Networks" 作為緒論，本文針對的是熟悉Web、HTTP、Apache的讀者而不是安全方面的專家，它不是SSL協議的權威性指南，不討論在一個組織中管理證書的特殊技術，也沒有重要的法定專利聲明及摘錄和引用限制。但是，本文會通過綜合講述各種概念、定義和例子，給`mod_ssl`的使用者提供背景資料，作為更深入探索的起點。這里的內容主要是來源于[Introducing SSL and Certificates using SSLeay](http://home.comcast.net/~fjhirsch/Papers/wwwj/)并經過作者[Frederick J. Hirsch](http://home.comcast.net/~fjhirsch/)許可。此文由 Open Group Research Institute于1997年夏，發表在[Web Security: A Matter of Trust](http://www.ora.com/catalog/wjsum97/), World Wide Web Journal, Volume 2, Issue 3, Summer 1997，肯定意見請反饋給[Frederick Hirsch](mailto:hirsch@fjhirsch.com)(原作者)，反對意見請反饋給[Ralf S. Engelschall](mailto:rse@engelschall.com)(`mod_ssl`的作者)。 ## 密碼技術要理解SSL就必須理解密碼系統、消息摘要函數(單向或散列函數)和數字簽名，這些技術是許多文獻所討論的主題(比如[[AC96](#calibre_link-81))，提供了保密性、完整性和認證的基礎。 ### 密碼系統假設Alice想給她的銀行發一個消息以劃轉資金，并希望這個消息是保密的，因為其中含有她的帳號和劃轉金額等信息。一種方案是使用密碼系統，將要傳輸的信息轉變為加密形式，從而只能為希望他讀懂的人讀懂。一旦加密為這種形式，這條消息也許只能用一個密鑰來破譯，如果沒有，那么這條信息毫無用處，因為好的密碼系統可以使破譯難度高到入侵者認為原文不值得他們花費那么大的努力。密碼系統有兩大類：常規的和公共密鑰。常規密碼又稱為對稱密碼，需要發送者和接收者共同持有一個密鑰：一小段用來加密和解密的秘密信息。如果這個密鑰是保密的，那么這條消息除了發送者和接受者以外可能沒有人可以閱讀。如果Alice和銀行共同持有一個密鑰，則可以互相發送保密信息。但是，私有通訊密鑰的選擇行為本身，卻可能不是無懈可擊的。公共密鑰密碼又稱為不對稱密碼，定義了一種使用兩個密鑰的算法以解決密鑰交換問題，一個密鑰用于加密，另一個用于解密，從而使簡單公布一個密鑰(公共的密鑰，簡稱：公鑰)而保留其他的(私有的密鑰，簡稱：私鑰)以接收保密消息成為可能。任何人都可以用公鑰加密一條消息，而僅允許私鑰的持有者閱讀。如此，Alice就可能使用公鑰加密其保密消息，發送給私鑰的持有者(銀行)，只有銀行能夠對它解密。 ### 消息摘要雖然Alice可能加密其消息使它稱為私有的，但仍應注意到某些人可能會篡改或替換其原始消息，以劃轉資金到他們自己的帳戶。一種保證Alice消息完整性的方法是同時發一個其消息的簡單摘要給銀行，供銀行與消息本身比對，如果相符則消息正確。這樣的方法被稱為<dfn class="calibre27">消息摘要</dfn>、_單向函數_或_散列函數_。消息摘要用于對較大而且變長的消息建立較短而且等長的一種表述，其設計使將摘要還原成消息極其困難，而且對兩個不同的消息幾乎不可能生成相同的摘要，從而排除了替換一個消息為另一個而維持相同摘要的可能性。 Alice面臨的另一個挑戰是要保證摘要發送到銀行的安全，如此，才能確保消息的完整性。一種解決方法是在摘要中包含數字簽名。 ### 數字簽名當Alice發送消息到銀行，銀行需要確認此消息的確是她發送的，而不是入侵者盜用其帳號。為此，可以在消息中包含一個由Alice建立的_數字簽名_。數字簽名是以加密的消息摘要和其他信息(比如一個流水號)以及發送者的私有密鑰建立的。雖然任何人都可能用公共密鑰_解密_簽名，但是只有簽發者知道其私有密鑰，也就是，只有密鑰的持有者才能簽發。包含在簽名中的摘要只對該消息有效，以確保沒有人可以改變摘要而保持簽名不變。為了避免簽名日后被入侵者破譯和再利用，簽名包含有一個流水號。如此，萬一(只是假設)Alice并沒有發送此消息，雖然她可能真的簽發過，銀行可以免遭其欺詐性指控。 ## 證書雖然Alice可能已經發送了一個保密的消息給銀行，簽了名，并可以保證消息的完整性，但是她仍然需要確認她的確是在和那個銀行通訊，也就是說，她需要確認她用的公共密鑰的確對應于銀行用的私有密鑰。同樣，銀行也需要驗證此消息的簽名的確對應于Alice的簽名。如果各部分有驗證其余部分一致性的證書，以確認公共密鑰，并是由一個可以信任的代理所簽發的，那么他們雙方都可以肯定其通訊對象的身份。這個可以信任的代理稱為_證書機構(Certificate Authority)_，其證書用于認證。 ### 證書的內容與一個公共密鑰關聯的證書有一個主題，即一個個體或者服務器或者其他實體的真實身份，如[表1](#calibre_link-82)所示。主題中的信息包含身份信息(識別名[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](#calibre_link-83)]中定義了識別名的各個項及其名稱和縮寫(見[表2](#calibre_link-84))。 #### 表 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](#calibre_link-85)] [[PKCS](#calibre_link-86)]表示，記號法定義了如何表示內容，編碼規則定義了如何將信息轉變成二進制形式。證書的二進制編碼使用了基于更通用的基本編碼規則(Basic Encoding Rules[BER])的識別名編碼規則(Distinguished Encoding Rules[DER])。為了在不能處理二進制的情況下進行傳輸，二進制形式用Base64編碼方式[[MIME](#calibre_link-87)]轉換成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](http://www.thawte.com/)和[VeriSign](http://www.verisign.com/)，提供如下服務： * 驗證證書的申請 * 處理證書的申請 * 授予和管理證書自己建立一個證書機構也是可能的，雖然在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](#calibre_link-88)] | 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](#calibre_link-89)] | 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](#calibre_link-90)] | 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](#calibre_link-91)所示，SSL協議有多種版本。SSL3.0的一個優點是增加了對加載證書鏈的支持，以允許服務器在發給瀏覽器的授予者證書上附加一個服務器證書。鏈的加載也允許瀏覽器驗證服務器證書，即使對此授予者的證書機構證書并沒有安裝，因為它已經包含在這個證書鏈中了。SSL3.0目前正由Internet Engineering Task Force(IETF)研發，是傳輸層安全[[TLS](#calibre_link-90)]協議標準的基礎。 ### 會話的建立 SSL會話在客戶端和服務器的握手過程之后建立，如[Figure 1](#calibre_link-92)所示，其過程可能因服務器是否配置為支持服務器證書和是否要求有客戶證書有所不同。雖然存在密碼信息管理需要額外握手操作的情況，本文只說明其中有共性的部分，參見所有可能情況下的SSL規范。 ### 說明 SSL會話一旦建立就可能是可重用的，以避免在初始會話時的性能損失和許多步驟的重復。為此，服務器為其后的連接緩存了為每個SSL會話設定的唯一的會話標志，以減少握手操作(直到服務器緩存中的會話標志過期為止)。 ![](https://box.kancloud.cn/2015-12-14_566e616483f25.gif) <dfn class="calibre50">Figure 1</dfn>: Simplified SSL Handshake Sequence 客戶端和服務器的握手過程如下所示： 1. 協商用于數據傳輸的密碼組 2. 建立并共享客戶端和服務器的會話密鑰 3. 可選的客戶端對服務器的認證 4. 可選的服務器對客戶端的認證第一步的密碼組協商，允許客戶端和服務器選擇一個共同支持的密碼組。SSL3.0協議規范定義了31個密碼組。密碼組由以下各部分組成： * 密鑰交換法 * 數據傳輸密碼 * 建立消息認證代碼(Message Authentication Code[MAC])的消息摘要此三個組成部分說明如下。 ### 密鑰交換方法密鑰交換法指明如何在客戶端和服務器的數據傳輸中使用共享的對稱密鑰。SSL2.0僅使用RSA密鑰交換，而SSL3.0可以在啟用證書時，選擇使用包括RSA的多種密鑰交換算法，以及無須證書和客戶端-服務器先期通訊的Diffie-Hellman密鑰交換法。密鑰交換法的一個變數是數字簽名(可用可不用)，如果用，用哪一種。私有密鑰配合簽名可以確保在生成共享密鑰[[AC96](#calibre_link-81), 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](#calibre_link-81), ch12]，有多個變種(包括DES40和3DES_EDE)；"Idea"是現有最好的最堅強的加密算法之一；"RC2"是RSADSI[[AC96](#calibre_link-81), ch13]的專屬的算法。 ### 摘要函數摘要函數指明對一個記錄單元如何建立摘要。SSL有如下支持： * No digest (Null choice) * MD5, a 128-bit hash * Secure Hash Algorithm (SHA-1), a 160-bit hash 消息摘要用于建立加密的消息認證碼(MAC)，與消息本身一同發送，以確保消息完整性并抵御還原攻擊。 ### 握手序列協議握手序列使用三個協議： * <dfn class="calibre27">SSL Handshake Protocol</dfn> ，以完成客戶端和服務器之間對話的建立。 * <dfn class="calibre27">SSL Change Cipher Spec Protocol</dfn> ，以實際建立對話用密碼組的約定。 * <dfn class="calibre27">SSL Alert Protocol</dfn> ，在客戶端和服務器之間傳輸SSL出錯消息。這些協議和應用協議的數據用 <dfn class="calibre27">SSL Record Protocol</dfn> 進行封裝，如[Figure 2](#calibre_link-93)所示，在不檢查數據的較底層的協議中傳輸。封裝協議對其底層協議來說是未知的。 ![](https://box.kancloud.cn/2015-12-14_566e6164923ad.gif) <dfn class="calibre50">Figure 2</dfn>: SSL Protocol Stack SSL控制協議對記錄協議的封裝，使一個正在進行的對話在重協商其控制協議后得以安全地進行傳輸。如果事先沒有建立對話，則會使用Null密碼組，也就是說，在建立對話以前，不使用密碼，且消息沒有完整性摘要。 ### 數據傳輸 SSL記錄協議，如[Figure 3](#calibre_link-94)所示，用于客戶端和服務器之間的傳輸應用和SSL控制數據，可能把數據分割成較小的單元，或者組合多個較高層協議數據為一個單元。在使用底層可靠傳輸協議傳輸數據單元之前，它可能會對這些單元進行壓縮、附著摘要簽名和加密(注意：目前所有主要SSL的實現都缺乏對壓縮的支持)。 ![](https://box.kancloud.cn/2015-12-14_566e61649d41a.gif) <dfn class="calibre50">Figure 3</dfn>: SSL Record Protocol ### 保護HTTP通訊 SSL的一個常見的用途是保護瀏覽器和網絡服務器之間的網絡HTTP通訊，但這并排除應用于不加保護的HTTP。其方法主要是，對普通HTTP加以SSL保護(稱為HTTPS)，但有一個重要的區別：它使用URL類型`https`而不是`http` ，而且使用不同的服務器端口(默認的是443)。`mod_ssl`為Apache網絡服務器提供的功能主要就是這些了... ## References [AC96] Bruce Schneier, <q class="calibre27">Applied Cryptography</q>, 2nd Edition, Wiley, 1996\. See [http://www.counterpane.com/](http://www.counterpane.com/) for various other materials by Bruce Schneier. [X208] ITU-T Recommendation X.208, <q class="calibre27">Specification of Abstract Syntax Notation One (ASN.1)</q>, 1988\. See for instance [http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I](http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I). [X509] ITU-T Recommendation X.509, <q class="calibre27">The Directory - Authentication Framework</q>. See for instance [http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509](http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509). [PKCS] <q class="calibre27">Public Key Cryptography Standards (PKCS)</q>, RSA Laboratories Technical Notes, See [http://www.rsasecurity.com/rsalabs/pkcs/](http://www.rsasecurity.com/rsalabs/pkcs/). [MIME] N. Freed, N. Borenstein, <q class="calibre27">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</q>, RFC2045. See for instance [http://ietf.org/rfc/rfc2045.txt](http://ietf.org/rfc/rfc2045.txt). [SSL2] Kipp E.B. Hickman, <q class="calibre27">The SSL Protocol</q>, 1995\. See [http://www.netscape.com/eng/security/SSL_2.html](http://www.netscape.com/eng/security/SSL_2.html). [SSL3] Alan O. Freier, Philip Karlton, Paul C. Kocher, <q class="calibre27">The SSL Protocol Version 3.0</q>, 1996\. See [http://www.netscape.com/eng/ssl3/draft302.txt](http://www.netscape.com/eng/ssl3/draft302.txt). [TLS1] Tim Dierks, Christopher Allen, <q class="calibre27">The TLS Protocol Version 1.0</q>, 1999\. See [http://ietf.org/rfc/rfc2246.txt](http://ietf.org/rfc/rfc2246.txt).