Apache HTTP 服务器版本 2.4
Apache HTTP 服务器版本 2.4
作为介绍，本章面向的读者是熟悉Web，HTTP和Apache，但不是安全专家的读者。它既不是SSL协议的权威指南，也不是讨论组织中用于管理证书的特定技术，也不是专利和进出口限制的重要法律问题。相反，它旨在mod_ssl通过将各种概念，定义和示例放在一起作为进一步探索的起点，为用户提供一个通用的背景。
了解SSL需要了解加密算法，消息摘要功能（即单向或哈希功能）和数字签名。这些技术是整本书的主题（例如，参见[ AC96 ]），并为隐私，完整性和身份验证提供了基础。
假设爱丽丝想向她的银行发送一条消息以转移一些钱。爱丽丝希望该消息为私人消息，因为它将包含诸如她的帐号和转账金额之类的信息。一种解决方案是使用加密算法，该技术会将她的消息转换为加密形式，直到解密后才能读取。一旦采用这种形式，则只能使用秘密密钥来解密消息。没有密钥，该消息将毫无用处：好的加密算法使入侵者很难解码原始文本，因此不值得他们付出努力。
密码算法分为两类：常规密钥和公共密钥。
任何人都可以使用公共密钥对消息进行加密，但是只有私有密钥的所有者才能阅读该消息。通过这种方式，爱丽丝可以使用私钥对公用密钥进行加密，从而将私密消息发送给密钥对的所有者（银行）。只有银行可以解密它们。
尽管爱丽丝可能会加密她的消息以使其私密，但是仍然有人担心有人可能会修改她的原始消息或将其替换为其他消息，以便例如将钱转移给自己。保证爱丽丝信息完整性的一种方法是让她创建一个简短的信息摘要，并将其发送给银行。收到消息后，银行将创建自己的摘要，并将其与发送的爱丽丝进行比较。如果摘要相同，则消息已完整接收。
诸如此类的摘要称为消息摘要，单向函数或哈希函数。消息摘要用于为较长的可变长度消息创建简短的，固定长度的表示形式。摘要算法旨在为每个消息生成唯一的摘要。消息摘要旨在使从摘要中确定消息变得不切实际，并且（理论上）不可能找到创建相同摘要的两个不同消息-从而消除了在保持相同摘要的情况下将一个消息替换为另一消息的可能性。
爱丽丝面临的另一个挑战是找到一种将摘要安全地发送到银行的方法。如果摘要的发送不安全，则其完整性可能会受到损害，并且银行有可能确定原始消息的完整性。只有安全发送摘要，才能确定关联消息的完整性。
安全发送摘要的一种方法是将摘要包含在数字签名中。
当爱丽丝向银行发送消息时，银行需要确保消息确实来自她，因此入侵者无法请求涉及其帐户的交易。由Alice创建并包含在消息中的数字签名用于此目的。
通过使用发件人的私钥对消息和其他信息（例如序列号）的摘要进行加密来创建数字签名。尽管任何人都可以使用公共密钥解密签名，但是只有发送者知道私有密钥。这意味着只有发件人可以对邮件签名。将摘要包含在签名中意味着签名仅适用于该消息。由于没有人可以更改摘要并仍然对其签名，因此它还确保了消息的完整性。
为了防止入侵者在以后拦截和重复使用签名，签名包含唯一的序列号。这样可以保护银行免受爱丽丝（Alice）欺诈性声称她没有发送消息的要求-只有她可以对消息进行签名（不可否认）。
尽管爱丽丝本可以向银行发送私人消息，对其进行签名并确保消息的完整性，但她仍需要确保自己确实在与银行通信。这意味着她需要确保所使用的公共密钥是银行密钥对的一部分，而不是入侵者的密钥对。同样，银行需要验证消息签名确实是由属于Alice的私钥签名的。
如果双方都拥有可证明对方身份，确认公钥并由受信任的机构签名的证书，则可以确保双方都在与自己认为的人进行通信。这种受信任的机构称为证书颁发机构，并且证书用于身份验证。
证书将公钥与个人，服务器或其他实体（称为主题）的真实身份相关联。如表1所示，关于主题的信息包括识别信息（专有名称）和公共密钥。它还包括颁发证书的证书颁发机构的标识和签名，以及证书有效的时间段。它可能具有其他信息（或扩展名）以及证书颁发机构使用的管理信息，例如序列号。
| 学科 | 专有名称，公钥 |
|---|---|
| 发行人 | 专有名称，签名 |
| 有效期 | 不早于日期，不晚于日期 |
| 行政信息 | 版本，序列号 |
| 扩展信息 | 基本约束，Netscape标志等 |
专有名称用于在特定情况下提供身份-例如，一个人可能拥有个人证书以及一个雇员身份的证书。专有名称由X.509标准[ X509 ] 定义，该标准定义了字段，字段名称和用于引用这些字段的缩写（请参见表2）。
| DN字段 | Abbrev。 | 描述 | 例 |
|---|---|---|---|
| 通用名 | CN | 名称被认证 | CN =乔平均 |
| 组织或公司 | Ø | 名称与此 组织相关 |
O =蛇油有限公司 |
| 组织单位 | OU | 名称与此 组织单位（例如部门）相关联 |
OU =研究所 |
| 城市/地区 | 大号 | 名字位于这个城市 | L =蛇城 |
| 州/省 | ST | 名称位于该州/省 | ST =沙漠 |
| 国家 | 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）确实是证书申请所声称的那个人。
证书颁发机构还可以为另一个证书颁发机构颁发证书。在检查证书时，爱丽丝可能需要针对每个父证书颁发机构检查颁发者的证书，直到获得她有信心的证书为止。她可以决定仅信任发行者有限的证书链，以降低发生证书的风险。链中的“不良”证书。
如前所述，每个证书都要求发行者声明证书主体身份的有效性，直到最高级别的证书颁发机构（CA）。这带来了一个问题：谁可以担保没有颁发者的最高级别机构的证书？在这种特殊情况下，证书是“自签名的”，因此证书的颁发者与主题相同。浏览器已预先配置为信任著名的证书颁发机构，但在信任自签名证书时要格外小心。根权限广泛地公开了公钥，这降低了信任此密钥的风险-很明显，如果其他人公开了一个声称是权威的密钥。
Thawte和VeriSign等许多公司 已将自己建立为证书颁发机构。这些公司提供以下服务：
也可以创建自己的证书颁发机构。尽管在Internet环境中存在风险，但在企业可以轻松地验证个人和服务器身份的Intranet中可能很有用。
建立证书颁发机构是一项责任，需要坚实的管理，技术和管理框架。证书颁发机构不仅颁发证书，而且还管理证书-也就是说，他们确定证书的有效期限，更新证书并保留过去颁发但不再有效的证书列表（证书吊销列表或CRL）。
例如，如果爱丽丝（Alice）有权获得公司雇员的证书，但现在已离开该公司，则可能需要吊销她的证书。因为仅在验证了对象的身份之后才颁发证书，然后才可以将证书传递给与对象通信的所有人员，所以仅凭证书就无法确定证书已被撤销。因此，在检查证书的有效性时，有必要联系发行证书的证书颁发机构以检查CRL，这通常不是过程的自动化部分。
如果您使用默认未将浏览器配置为信任的证书颁发机构，则有必要将证书颁发机构证书加载到浏览器中，以使浏览器能够验证由该证书颁发机构签名的服务器证书。这样做可能很危险，因为一旦加载，浏览器将接受该证书颁发机构签署的所有证书。
安全套接字层协议是可以放置在可靠的面向连接的网络层协议（例如TCP / IP）和应用协议层（例如HTTP）之间的协议层。SSL通过允许相互身份验证，使用数字签名来保证完整性以及使用加密来保护隐私，从而确保了客户端和服务器之间的安全通信。
该协议旨在支持用于加密，摘要和签名的特定算法的多种选择。这允许根据法律，出口或其他方面的考虑为特定服务器选择算法，并使协议能够利用新算法。建立协议会话时，应在客户端和服务器之间协商选择。
| 版 | 资源 | 描述 |
|---|---|---|
| SSL v2.0 | 供应商标准（来自Netscape Corp.） | 存在其实现的第一个SSL协议 |
| SSL v3.0 | Internet草案已过期（来自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是Internet工程任务组（IETF）当前正在开发的传输层安全性（TLS）协议标准的基础。
通过遵循客户端与服务器之间的握手序列来建立SSL会话，如图1所示。此顺序可能会有所不同，具体取决于服务器是配置为提供服务器证书还是请求客户端证书。尽管在某些情况下，需要额外的握手步骤来管理密码信息，但本文总结了一种常见的情况。有关所有可能性的信息，请参阅SSL规范。
一旦建立了SSL会话，就可以重新使用它。这样可以避免重复启动会话所需的许多步骤而导致的性能损失。为此，服务器为每个SSL会话分配一个唯一的会话标识符，该标识符在服务器中缓存，并且客户端可以在以后的连接中使用它来减少握手时间（直到会话标识符从服务器的缓存中过期为止）。
图1：简化的SSL握手序列
客户端和服务器使用的握手序列的元素如下所示：
第一步，Cipher Suite协商，允许客户端和服务器选择两者都支持的Cipher Suite。SSL3.0协议规范定义了31个密码套件。密码套件由以下组件定义：
以下各节将介绍这三个元素。
密钥交换方法定义了客户端和服务器如何协商用于应用程序数据传输的共享秘密对称加密密钥。SSL 2.0仅使用RSA密钥交换，而SSL 3.0支持多种密钥交换算法，包括RSA密钥交换（使用证书时）和Diffie-Hellman密钥交换（用于在没有证书的情况下交换密钥，或者在客户端与服务器之间无需事先通信的情况下） ）。
选择密钥交换方法的一个变量是数字签名-是否使用它们，如果使用，则使用哪种类型的签名。使用私钥签名可以防止在发生用于生成共享密钥的信息交换期间出现中间人攻击[ AC96，p516]。
SSL使用传统的对称密码术（如前所述）来加密会话中的消息。有9种加密方式的选择，包括不加密的选项：
“ CBC”是指密码块链接，这意味着先前加密的密文的一部分用于当前块的加密。“ DES”是指数据加密标准[ AC96，ch12]，它具有许多变体（包括DES40和3DES_EDE）。当前，“ Idea”是可用的最佳和加密能力最强的算法之一，“ RC2”是RSA DSI专有的算法[ AC96，ch13]。
摘要功能的选择确定如何从记录单元创建摘要。SSL支持以下内容：
消息摘要用于创建消息身份验证代码（MAC），该消息验证代码随消息一起加密，以验证完整性并防止重放攻击。
握手序列使用三种协议：
这些协议以及应用程序协议数据封装在SSL Record Protocol中，如图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服务器提供的功能的很大一部分。
应用密码学，第二版，Wiley，1996。有关Bruce Schneier的其他各种材料，请参见http://www.counterpane.com/。
抽象语法符号一的规范（ASN.1），最新更新于2008年。请参见http://www.itu.int/ITU-T/asn1/。
目录认证框架。有关参考，请参见http://en.wikipedia.org/wiki/X.509。
公钥加密标准（PKCS），RSA实验室技术说明，请参见http://www.rsasecurity.com/rsalabs/pkcs/。
多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文的格式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。
