# 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会话设定的唯一的会话标志，以减少握手操作(直到服务器缓存中的会话标志过期为止)。  <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)所示，在不检查数据的较底层的协议中传输。封装协议对其底层协议来说是未知的。  <dfn class="calibre50">Figure 2</dfn>: SSL Protocol Stack SSL控制协议对记录协议的封装，使一个正在进行的对话在重协商其控制协议后得以安全地进行传输。如果事先没有建立对话，则会使用Null密码组，也就是说，在建立对话以前，不使用密码，且消息没有完整性摘要。 ### 数据传输 SSL记录协议，如[Figure 3](#calibre_link-94)所示，用于客户端和服务器之间的传输应用和SSL控制数据，可能把数据分割成较小的单元，或者组合多个较高层协议数据为一个单元。在使用底层可靠传输协议传输数据单元之前，它可能会对这些单元进行压缩、附着摘要签名和加密(注意：目前所有主要SSL的实现都缺乏对压缩的支持)。  <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).