SSL / TLS强加密：简介
作为介绍，本章针对的读者是熟悉Web，HTTP和Apache但又不是安全专家的读者。它既不是SSL协议的权威指南，也不是讨论组织中管理证书的特定技术，也不是专利和进出口限制的重要法律问题。相反，它旨在mod_ssl通过将各种概念，定义和示例放在一起作为进一步探索的起点，为用户提供一个通用的背景。
密码技术
了解SSL需要了解加密算法，消息摘要功能（即单向或哈希函数）和数字签名。这些技术是整本书的主题（例如，参见[ AC96 ]），并为隐私，完整性和身份验证提供了基础。
密码算法
假设爱丽丝想向她的银行发送一条消息以转移一些钱。爱丽丝希望该消息为私人消息，因为它将包含诸如她的帐号和转账金额之类的信息。一种解决方案是使用密码算法，该技术会将她的消息转换为加密形式，直到解密后才能读取。一旦采用这种形式，则只能使用秘密密钥来解密消息。没有密钥，该消息将毫无用处：良好的加密算法使入侵者很难解码原始文本，因此不值得他们付出努力。
密码算法分为两类：常规密钥和公共密钥。
- 常规密码学
- 也称为对称加密，要求发送者和接收者共享密钥：可以用于加密或解密消息的秘密信息。只要将此密钥保密，发件人或收件人之外的任何人都无法阅读该消息。如果爱丽丝和银行知道密钥，那么他们可以互相发送私人消息。在通信之前在发送者和接收者之间共享密钥的任务，同时还要使其与他人保持秘密，可能会出现问题。
- 公钥加密
- 也称为非对称密码术，它通过定义使用两个密钥的算法来解决密钥交换问题，每个密钥可用于加密消息。如果使用一个密钥对消息进行加密，则必须使用另一个对消息进行解密。通过简单地发布一个密钥（公共密钥）并保留另一个秘密（私有密钥），就可以接收安全消息。
任何人都可以使用公共密钥对消息进行加密，但是只有私有密钥的所有者才能阅读该消息。通过这种方式，爱丽丝可以使用私钥对公用密钥进行加密，从而将私钥消息发送给密钥对的所有者（银行）。只有银行可以解密它们。
讯息摘要
尽管爱丽丝可以加密她的消息以使其私密，但是仍然有人担心有人可能会修改她的原始消息或将其替换为另一条消息，以便例如将钱转移给自己。保证爱丽丝信息完整性的一种方法是让她创建一个简短的信息摘要，并将其发送给银行。收到消息后，银行创建自己的摘要，并将其与发送的爱丽丝进行比较。如果摘要相同，则消息已完整接收。
这样的摘要称为消息摘要，单向函数或哈希函数。消息摘要用于为较长的可变长度消息创建简短的，固定长度的表示形式。摘要算法旨在为每个消息生成唯一的摘要。消息摘要旨在使从摘要中确定消息变得不切实际，并且（从理论上来说）不可能找到两个创建相同摘要的不同消息-这样就消除了在保持相同摘要的情况下将一个消息替换为另一个消息的可能性。
爱丽丝面临的另一个挑战是找到一种将摘要安全地发送到银行的方法。如果摘要的发送不安全，则其完整性可能会受到损害，并且银行有可能确定原始消息的完整性。只有安全地发送摘要，才能确定关联消息的完整性。
安全发送摘要的一种方法是将摘要包含在数字签名中。
数字签名
当爱丽丝向银行发送消息时，银行需要确保消息确实来自她，因此入侵者无法请求涉及其帐户的交易。由Alice创建并包含在消息中的数字签名可达到此目的。
通过使用发件人的私钥对消息摘要和其他信息（例如序列号）进行加密来创建数字签名。尽管任何人都可以使用公共密钥解密签名，但是只有发送者知道私有密钥。这意味着只有发件人可以对邮件签名。将摘要包含在签名中意味着签名仅适用于该消息。由于没有人可以更改摘要并仍然对其签名，因此它还确保了消息的完整性。
为了防止入侵者在以后拦截和重复使用签名，签名应包含唯一的序列号。这样可以保护银行免受爱丽丝（Alice）欺诈性声称她没有发送消息的要求-只有她可以对消息进行签名（不可否认）。
证明书
尽管爱丽丝本可以向银行发送私人消息，对其进行签名并确保消息的完整性，但她仍然需要确保自己确实在与银行通信。这意味着她需要确保所使用的公共密钥是银行密钥对的一部分，而不是入侵者的密钥对。同样，银行需要验证消息签名确实是由属于Alice的私钥签名的。
如果双方都拥有可证明对方身份，确认公钥并由受信任的机构签名的证书，则可以确保双方都在与自己认为的人进行通信。这种受信任的机构称为证书颁发机构，并且证书用于身份验证。
证书内容
证书将公钥与个人，服务器或其他称为主题的实体的真实身份相关联。如表1所示，关于主题的信息包括识别信息（专有名称）和公共密钥。它还包括颁发证书的证书颁发机构的标识和签名，以及证书有效的时间段。它可能具有其他信息（或扩展名）以及证书颁发机构使用的管理信息，例如序列号。
表1：证书信息
| 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 ]定义，该标准定义了字段，字段名称和用于引用这些字段的缩写（请参见表2）。
表2：专有名称信息
| 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 |
*.snakeoil.com。PEM编码的证书示例（snakeoil.crt）
----- BEGIN证书----- 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 == -----结束证书-----
证书颁发机构
通过在授予证书之前验证证书请求中的信息，证书颁发机构可以确保自己拥有密钥对的私钥所有者的身份。例如，如果爱丽丝（Alice）要求提供个人证书，则证书颁发机构必须首先确保爱丽丝（Alice）确实是证书要求的真实身份者。
证书链
证书颁发机构还可以为另一个证书颁发机构颁发证书。在检查证书时，爱丽丝可能需要针对每个父证书颁发机构检查颁发者的证书，直到获得她有信心的证书为止。她可以决定仅信任发行者有限的证书，以降低发生证书的风险。链中的“不良”证书。
创建一个根级CA
如前所述，每个证书都要求发行者声明证书主体身份的有效性，直到最高级别的证书颁发机构（CA）。这带来了一个问题：谁可以担保没有颁发者的最高级别机构的证书？在这种特殊情况下，证书是“自签名的”，因此证书的颁发者与主题相同。浏览器已预先配置为信任著名的证书颁发机构，但是在信任自签名证书时要格外小心。根权限广泛地公开了公钥，这降低了信任此密钥的风险-很明显，如果其他人公开了一个声称是权威的密钥。
Thawte和VeriSign等许多公司已将自己建立为证书颁发机构。这些公司提供以下服务：
- 验证证书申请
- 处理证书申请
- 颁发和管理证书
也可以创建自己的证书颁发机构。尽管在Internet环境中存在风险，但在企业可以轻松地验证个人和服务器身份的企业内部网中可能很有用。
证书管理
建立证书颁发机构是一项责任，需要坚实的管理，技术和管理框架。证书颁发机构不仅颁发证书，而且还管理证书-也就是说，他们确定证书的有效期限，更新证书并保留过去颁发但不再有效的证书列表（证书吊销列表或CRL）。
例如，如果爱丽丝（Alice）有权获得公司雇员的证书，但现在已离开该公司，则可能需要吊销其证书。因为仅在验证了对象的身份之后才颁发证书，然后才可以将证书传递给与对象通信的所有人员，所以仅凭证书就无法确定证书已被撤销。因此，在检查证书的有效性时，有必要联系发行证书的证书颁发机构以检查CRL，这通常不是过程的自动化部分。
注意
如果使用的证书颁发机构默认未将浏览器配置为信任，则有必要将证书颁发机构证书加载到浏览器中，以使浏览器能够验证由该证书颁发机构签名的服务器证书。这样做可能很危险，因为一旦加载，浏览器将接受该证书颁发机构签署的所有证书。
安全套接字层（SSL）
安全套接字层协议是可以放置在可靠的面向连接的网络层协议（例如TCP / IP）和应用协议层（例如HTTP）之间的协议层。SSL通过允许相互身份验证，使用数字签名来保证完整性以及使用加密来保护隐私，从而在客户端和服务器之间提供了安全的通信。
该协议旨在支持用于加密，摘要和签名的特定算法的多种选择。这允许根据法律，出口或其他方面的考虑为特定服务器选择算法，并使协议能够利用新算法。建立协议会话时，应在客户端和服务器之间协商选择。
表4：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个密码套件。密码套件由以下组件定义：
- 密钥交换方式
- 数据传输密码
- 消息摘要，用于创建消息验证码（MAC）
以下各节将介绍这三个元素。
密钥交换方式
密钥交换方法定义了客户端和服务器如何协商用于应用程序数据传输的共享秘密对称加密密钥。SSL 2.0仅使用RSA密钥交换，而SSL 3.0支持多种密钥交换算法，包括RSA密钥交换（使用证书时）和Diffie-Hellman密钥交换（用于在没有证书的情况下交换密钥，或者在客户端与服务器之间无需事先通信的情况下））。
选择密钥交换方法的一个变量是数字签名-是否使用它们，如果使用，则使用哪种类型的签名。使用私钥签名可以防止在发生用于生成共享密钥的信息交换期间出现中间人攻击[ AC96，p516]。
数据传输密码
SSL使用传统的对称密码术（如前所述）来加密会话中的消息。有9种加密方式的选择，包括不加密的选项：
- 没有加密
- 流密码
- 带40位密钥的RC4
- 带128位密钥的RC4
- CBC分组密码
- 带40位密钥的RC2
- 带40位密钥的DES
- 带56位密钥的DES
- 带168位密钥的三重DES
- 想法（128位密钥）
- Fortezza（96位密钥）
“ CBC”是指密码块链接，这意味着先前加密的密文的一部分用于当前块的加密。“ DES”是指数据加密标准[ AC96，ch12]，具有许多变体（包括DES40和3DES_EDE）。目前，“ Idea”是目前可用的最佳算法和密码学上最强的算法，“ RC2”是RSA DSI专有的算法[ AC96，ch13]。
摘要功能
摘要功能的选择确定如何从记录单元创建摘要。SSL支持以下内容：
- 没有摘要（无选择）
- MD5，128位哈希
- 安全哈希算法（SHA-1），160位哈希
消息摘要用于创建消息身份验证代码（MAC），该消息已与消息一起加密，以验证完整性并防止重放攻击。
握手序列协议
握手序列使用三种协议：
- 用于执行客户端和服务器SSL会话建立的SSL握手协议。
- 该SSL变更密码说明协议为本届会议实际上建立在密码套件协议。
- 该SSL告警协议输送客户端和服务器之间的SSL错误消息。
这些协议以及应用程序协议数据封装在SSL Record Protocol中，如图2所示。封装的协议通过不检查数据的下层协议作为数据传输。封装的协议不了解基础协议。
图2：SSL协议栈
记录协议对SSL控制协议的封装意味着，如果重新协商活动会话，则将安全地传输控制协议。如果没有以前的会话，则使用Null密码套件，这意味着在建立会话之前，将不会进行加密，并且消息将没有完整性摘要。
数据传输
SSL记录协议（如图3所示）用于在客户端和服务器之间传输应用程序和SSL控制数据，必要时将该数据分为较小的单元，或将多个较高级别的协议数据消息组合为单个单元。在使用基础可靠的传输协议传输这些单元之前，它可能会压缩，附加摘要签名并对其进行加密（注意：当前，没有主要的SSL实现包含对压缩的支持）。
图3：SSL记录协议
保护HTTP通信
SSL的一种常见用法是保护浏览器和Web服务器之间的Web HTTP通信。这并不排除使用非安全的HTTP-安全版本（称为HTTPS）与基于SSL的纯HTTP相同，但是使用URL方案https而不是http，并且使用不同的服务器端口（默认为端口443）。此功能是mod_ssl为Apache Web服务器提供的功能的很大一部分。