Apache HTTP Server 版本 2.4
Apache HTTP Server 版本 2.4
作为介绍，本章面向熟悉 Web、HTTP 和 Apache 但不是安全专家的读者。它并非旨在成为 SSL 协议的权威指南，也不讨论在组织中管理证书的特定技术，或专利、进出口限制等重要法律问题。相反，它的目的是通过将各种概念、定义和示例汇集在一起，为 mod_ssl 用户提供一个共同的背景，作为进一步探索的起点。
理解 SSL 需要理解加密算法、消息摘要函数（也称为单向或哈希函数）和数字签名。这些技术是整本书的主题（例如，参见 [AC96]），并为隐私、完整性和身份验证提供了基础。
假设 Alice 想向她的银行发送一条消息来转账一些钱。Alice 希望这条消息是私密的，因为它将包含她的帐号和转账金额等信息。一种解决方案是使用加密算法，这是一种将她的消息转换为加密形式的技术，在解密之前无法读取。一旦处于这种形式，消息只能使用密钥解密。没有密钥，消息就毫无用处：好的加密算法使入侵者解码原始文本变得如此困难，以至于不值得他们付出努力。
加密算法有两类：传统算法和公钥算法。
任何人都可以使用公钥加密消息，但只有私钥的所有者才能读取它。这样，Alice 可以通过使用银行的公钥加密消息来向密钥对的所有者（银行）发送私密消息。只有银行才能解密它们。
虽然 Alice 可以加密她的消息以使其私密，但仍然存在有人可能会修改她的原始消息或将其替换为其他消息的担忧，例如，为了将钱转给自己。保证 Alice 消息完整性的一种方法是让她创建消息的简要摘要，并将此摘要也发送给银行。收到消息后，银行创建自己的摘要并将其与 Alice 发送的摘要进行比较。如果摘要相同，则消息已完整收到。
这样的摘要称为 消息摘要、单向函数或哈希函数。消息摘要用于创建较长、可变长度消息的简短、固定长度表示。摘要算法旨在为每条消息生成唯一的摘要。消息摘要旨在使从摘要中确定消息变得不切实际地困难，并且（理论上）不可能找到创建相同摘要的两个不同消息——从而消除了在保持相同摘要的同时将一条消息替换为另一条消息的可能性。
Alice 面临的另一个挑战是找到一种安全地将摘要发送给银行的方法；如果摘要没有安全发送，它的完整性可能会受到损害，以及银行确定原始消息完整性的可能性。只有当摘要安全发送时，才能确定相关消息的完整性。
安全发送摘要的一种方法是将其包含在数字签名中。
当 Alice 向银行发送消息时，银行需要确保消息确实是来自她的，因此入侵者无法请求涉及她帐户的交易。由 Alice 创建并包含在消息中的数字签名可以实现此目的。
数字签名是通过使用发送方的私钥加密消息的摘要和其他信息（例如序列号）来创建的。虽然任何人都可以使用公钥解密签名，但只有发送方知道私钥。这意味着只有发送方才能签署消息。将摘要包含在签名中意味着签名仅对该消息有效；它还确保了消息的完整性，因为没有人可以更改摘要并仍然对其进行签名。
为了防止入侵者在以后拦截和重复使用签名，签名包含一个唯一的序列号。这可以保护银行免受 Alice 的欺诈性索赔，即她没有发送消息——只有她才能签署它（不可否认）。
虽然 Alice 可以向银行发送私密消息，对其进行签名并确保消息的完整性，但她仍然需要确保她确实是在与银行通信。这意味着她需要确保她使用的公钥是银行密钥对的一部分，而不是入侵者的密钥对。类似地，银行需要验证消息签名确实是使用属于 Alice 的私钥签署的。
如果每一方都拥有一个验证对方身份、确认公钥并由可信机构签署的证书，那么双方都可以确信他们正在与他们认为的对方通信。这样的可信机构称为证书颁发机构，证书用于身份验证。
证书将公钥与个人、服务器或其他实体的真实身份相关联，称为主体。如 表 1 所示，有关主体的信息包括识别信息（识别名称）和公钥。它还包括颁发证书的证书颁发机构的标识和签名以及证书有效的时段。它可能还包含其他信息（或扩展）以及证书颁发机构使用的管理信息，例如序列号。
| 主体 | 识别名称、公钥 |
|---|---|
| 颁发者 | 识别名称、签名 |
| 有效期 | 不早于日期、不晚于日期 |
| 管理信息 | 版本、序列号 |
| 扩展信息 | 基本约束、Netscape 标志等 |
识别名称用于在特定上下文中提供身份——例如，个人可能拥有个人证书以及作为员工身份的证书。识别名称由 X.509 标准 [X509] 定义，该标准定义了用于引用字段的字段、字段名称和缩写（参见 表 2）。
| DN 字段 | 缩写 | 描述 | 示例 |
|---|---|---|---|
| 通用名称 | CN | 正在认证的名称 | CN=Joe Average |
| 组织或公司 | O | 名称与该组织相关联 组织 |
O=Snake Oil, Ltd. |
| 组织单位 | OU | 名称与该组织相关联 组织单位，例如部门 |
OU=Research Institute |
| 城市/地区 | L | 名称位于该城市 | L=Snake City |
| 州/省 | ST | 名称位于该州/省 | ST=Desert |
| 国家 | C | 名称位于该国家（ISO 代码） | C=XZ |
证书颁发机构可以定义一个策略，指定哪些识别字段名称是可选的，哪些是必需的。它还可以对字段内容提出要求，就像证书用户一样。例如，Netscape 浏览器要求代表服务器的证书的通用名称与该服务器域名（例如 *.snakeoil.com）的通配符模式匹配。
证书的二进制格式使用 ASN.1 符号 [ASN1] [PKCS] 定义。此符号定义如何指定内容，编码规则定义如何将此信息转换为二进制形式。证书的二进制编码使用区分编码规则 (DER) 定义，这些规则基于更通用的基本编码规则 (BER)。对于那些无法处理二进制的传输，可以使用 Base64 编码 [MIME] 将二进制形式转换为 ASCII 形式。当放置在开始和结束分隔符行之间（如下所示）时，此编码版本称为 PEM（“隐私增强邮件”）编码证书。
-----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 和 VeriSign 已成为证书颁发机构。这些公司提供以下服务
也可以创建自己的证书颁发机构。虽然在互联网环境中存在风险，但在内联网中可能很有用，因为组织可以轻松验证个人和服务器的身份。
建立证书颁发机构是一项责任，需要牢固的行政、技术和管理框架。证书颁发机构不仅颁发证书，还管理证书——也就是说，它们确定证书的有效期，续订证书并保留过去颁发但不再有效的证书列表（证书吊销列表，或 CRL）。
例如，如果 Alice 有权获得作为公司员工的证书，但现在已离开该公司，则可能需要吊销她的证书。由于证书仅在验证主体身份后才颁发，然后可以传递给主体可能与之通信的所有人，因此无法仅从证书本身判断它是否已被吊销。因此，在检查证书的有效性时，有必要联系颁发证书的证书颁发机构以检查 CRL——这通常不是该过程的自动化部分。
如果您使用的证书颁发机构不是浏览器默认配置为信任的，则需要将证书颁发机构证书加载到浏览器中，使浏览器能够验证由该证书颁发机构签名的服务器证书。这样做可能很危险，因为一旦加载，浏览器将接受由该证书颁发机构签名的所有证书。
安全套接字层协议是一个协议层，可以放置在可靠的面向连接的网络层协议（例如 TCP/IP）和应用程序协议层（例如 HTTP）之间。SSL 通过允许相互身份验证、使用数字签名来保证完整性和使用加密来保证隐私，从而提供客户端和服务器之间的安全通信。
该协议旨在支持用于密码学、摘要和签名的特定算法的一系列选择。这允许根据法律、出口或其他问题为特定服务器选择算法，并且还使协议能够利用新算法。在建立协议会话时，客户端和服务器之间协商选择。
| 版本 | 来源 | 描述 |
|---|---|---|
| SSL v2.0 | 供应商标准（来自 Netscape Corp.） | 第一个存在实现的 SSL 协议 |
| SSL v3.0 | 已过期的互联网草案（来自 Netscape Corp.）[SSL3] | 修订以防止特定的安全攻击，添加非 RSA 密码和对证书链的支持 |
| TLS v1.0 | 拟议的互联网标准（来自 IETF）[TLS1] | SSL 3.0 的修订，以将 MAC 层更新为 HMAC，为块密码添加块填充，消息顺序标准化以及更多警报消息。 |
| TLS v1.1 | 拟议的互联网标准（来自 IETF）[TLS11] | TLS 1.0 的更新，以添加对密码块链接 (CBC) 攻击的保护。 |
| TLS v1.2 | 拟议的互联网标准（来自 IETF）[TLS12] | TLS 1.1 的更新，弃用 MD5 作为哈希，并添加与 SSL 的不兼容性，因此它永远不会协商使用 SSLv2。 |
SSL 协议有许多版本，如 表 4 所示。如表中所述，SSL 3.0 的优点之一是它增加了对证书链加载的支持。此功能允许服务器将服务器证书与颁发者证书一起传递给浏览器。链加载还允许浏览器验证服务器证书，即使没有为中间颁发者安装证书颁发机构证书，因为它们包含在证书链中。SSL 3.0 是传输层安全 [TLS] 协议标准的基础，该标准目前正在由互联网工程任务组 (IETF) 开发。
SSL 会话是通过遵循客户端和服务器之间的握手序列来建立的，如 图 1 所示。此序列可能会有所不同，具体取决于服务器是否配置为提供服务器证书或请求客户端证书。虽然存在需要额外的握手步骤来管理密码信息的情况，但这篇文章总结了一种常见的情况。有关所有可能性的完整范围，请参阅 SSL 规范。
一旦建立了 SSL 会话，就可以重复使用它。这避免了重复启动会话所需的许多步骤带来的性能损失。为此，服务器为每个 SSL 会话分配一个唯一的会话标识符，该标识符缓存在服务器中，客户端可以在将来的连接中使用它来减少握手时间（直到会话标识符从服务器的缓存中过期）。
图 1：简化的 SSL 握手序列
客户端和服务器使用的握手序列的元素列在下面
第一步，密码套件协商，允许客户端和服务器选择它们都支持的密码套件。SSL3.0 协议规范定义了 31 个密码套件。密码套件由以下组件定义
以下部分将描述这三个元素。
密钥交换方法定义了客户端和服务器如何就用于应用程序数据传输的共享秘密对称密码密钥达成一致。SSL 2.0 仅使用 RSA 密钥交换，而 SSL 3.0 支持多种密钥交换算法，包括 RSA 密钥交换（当使用证书时）和 Diffie-Hellman 密钥交换（用于在没有证书或客户端和服务器之间没有事先通信的情况下交换密钥）。
密钥交换方法选择中的一个变量是数字签名——是否使用它们，以及如果使用，使用哪种签名。使用私钥签名可以防止在用于生成共享密钥的信息交换期间发生中间人攻击 [AC96，第 516 页]。
SSL 使用前面描述的传统对称密码学来加密会话中的消息。有九种加密选择，包括不加密的选择
“CBC” 指密码块链接，这意味着先前加密的密文的一部分用于当前块的加密。“DES” 指数据加密标准 [AC96，第 12 章]，它有许多变体（包括 DES40 和 3DES_EDE）。“Idea” 目前是最好的、密码学上最强的算法之一，“RC2” 是 RSA DSI 的专有算法 [AC96，第 13 章]。
摘要函数的选择决定了如何从记录单元创建摘要。SSL 支持以下内容
消息摘要用于创建消息认证码 (MAC)，该代码与消息一起加密以验证完整性并防止重放攻击。
握手序列使用三个协议
这些协议以及应用程序协议数据都封装在 SSL 记录协议 中，如 图 2 所示。封装的协议作为数据由底层协议传输，底层协议不会检查数据。封装的协议不知道底层协议。
图 2：SSL 协议栈
记录协议对 SSL 控制协议的封装意味着，如果重新协商活动会话，控制协议将被安全地传输。如果没有先前的会话，则使用 Null 密码套件，这意味着不会进行加密，并且消息将没有完整性摘要，直到会话建立。
SSL 记录协议（如 图 3 所示）用于在客户端和服务器之间传输应用程序和 SSL 控制数据，必要时将这些数据分割成更小的单元，或将多个更高级别的协议数据消息组合成单个单元。它可以在使用底层可靠传输协议传输这些单元之前压缩、附加摘要签名和加密这些单元（注意：目前，没有主要的 SSL 实现包含对压缩的支持）。
图 3：SSL 记录协议
SSL 的一个常见用途是保护浏览器和 Web 服务器之间的 Web HTTP 通信。这并不排除使用非安全 HTTP——安全版本（称为 HTTPS）与 SSL 上的普通 HTTP 相同，但使用 URL 方案 https 而不是 http，以及不同的服务器端口（默认情况下为端口 443）。此功能是 mod_ssl 为 Apache Web 服务器提供的功能的重要组成部分。
多用途互联网邮件扩展 (MIME) 第一部分：互联网消息体的格式，RFC2045。例如，参见 http://tools.ietf.org/html/rfc2045。
SSL 协议版本 3.0，1996 年。参见 http://www.netscape.com/eng/ssl3/draft302.txt。
TLS 协议版本 1.0，1999 年。参见 http://ietf.org/rfc/rfc2246.txt。
TLS 协议版本 1.1，2006 年。参见 http://tools.ietf.org/html/rfc4346。
TLS 协议版本 1.2，2008 年。参见 http://tools.ietf.org/html/rfc5246。
