SSL/TLS 强加密：简介

作为介绍，本章针对的 Reader 是熟悉 Web，HTTP 和 Apache，但不是安全 maven 的 Reader。它既不是 SSL 协议的 Authority 指南，也不是讨论组织中用于 Management 证书的特定技术，也不是专利和进 Export 限制的重要法律问题。相反，它旨在通过汇集各种概念，定义和示例作为mod_ssl用户的通用背景，作为进一步探索的起点。

Cryptographic Techniques

了解 SSL 需要了解加密算法，消息摘要功能(即单向或哈希功能)和数字签名。这些技术是整本书的主题(例如，参见 [AC96)，并为隐私，完整性和身份验证提供了基础。

Cryptographic Algorithms

假设爱丽丝想向她的银行发送一条消息以转移一些钱。爱丽丝希望该消息为私人消息，因为它将包含诸如她的帐号和转账金额之类的信息。一种解决方案是使用加密算法，该技术会将她的消息转换为加密形式，直到解密后才能读取。一旦采用这种形式，则只能使用 Secret 密钥来解密消息。没有密钥，该消息将毫无用处：良好的加密算法使入侵者很难解码原始文本，因此不值得他们付出努力。

密码算法分为两类：常规密钥和公共密钥。

  • Conventional cryptography

    • 也称为对称密码术，要求发送者和接收者共享密钥：可以用于加密或解密消息的 Secret 信息。只要将此密钥保密，发件人或收件人就无法读取该消息。如果爱丽丝和银行知道密钥，那么他们可以互相发送私人消息。在通信之前在发送者和接收者之间共享密钥的任务，同时还要使其与他人保持 Secret，可能会出现问题。

  • 公钥加密

    • 也称为非对称密码术，它通过定义使用两个密钥的算法来解决密钥交换问题，每个密钥可用于加密消息。如果使用一个密钥对消息进行加密，则必须使用另一个对消息进行解密。通过简单地发布一个密钥(公共密钥)并保留另一个 Secret(私有密钥)，就可以接收安全消息。

任何人都可以使用公用密钥对邮件进行加密，但是只有专用密钥的所有者才能读取该邮件。通过这种方式，爱丽丝可以使用私钥对公用密钥进行加密，从而将私密消息发送给密钥对的所有者(银行)。只有银行将能够解密它们。

Message Digests

尽管爱丽丝可能会加密自己的消息以使其私密，但是仍然有人担心有人会修改她的原始消息或将其替换为另一条消息，例如将钱转移给自己。保证爱丽丝信息完整性的一种方法是让她创建一个简短的信息摘要，并将其发送给银行。收到消息后，银行将创建自己的摘要，并将其与发送的爱丽丝进行比较。如果摘要相同，则消息已完整接收。

这样的摘要称为消息摘要，单向函数或哈希函数。消息摘要用于为较长的可变长度消息创建简短的，固定长度的表示形式。摘要算法旨在为每个消息生成唯一的摘要。消息摘要的设计使从摘要中确定消息变得不切实际，并且(从理论上来说)不可能找到两个创建相同摘要的不同消息-从而消除了在保持相同摘要的情况下将一条消息替换为另一条消息的可能性。

爱丽丝面临的另一个挑战是找到一种将摘要安全地发送到银行的方法。如果摘要的发送不安全，则其完整性可能会受到损害，并且银行有可能确定原始消息的完整性。只有安全地发送了摘要，才能确定关联消息的完整性。

安全发送摘要的一种方法是将摘要包含在数字签名中。

Digital Signatures

当爱丽丝向银行发送消息时，银行需要确保消息确实来自她，因此入侵者无法请求涉及其帐户的 Transaction。由 Alice 创建并包含在消息中的数字签名可以达到此目的。

通过使用发件人的私钥加密消息摘要和其他信息(例如序列号)来创建数字签名。尽管任何人都可以使用公共密钥“解密”签名，但是只有发送者知道私有密钥。这意味着只有发件人可以对邮件签名。将摘要包含在签名中意味着签名仅适用于该消息。由于没有人可以更改摘要并仍然对其签名，因此它还确保了消息的完整性。

为了防止入侵者在以后拦截和重复使用签名，签名包含唯一的序列号。这样可以保护银行免受爱丽丝(Alice)欺诈性声称她没有发送消息的要求-只有她可以对消息进行签名(不可否认)。

Certificates

尽管爱丽丝本可以向银行发送私人消息，对其进行签名并确保消息的完整性，但她仍需要确保自己确实在与银行通信。这意味着她需要确保所使用的公共密钥是银行密钥对的一部分，而不是入侵者的密钥对。同样，银行需要验证消息签名确实是由属于 Alice 的私钥签名的。

如果双方都拥有可证明对方身份，确认公钥并由受信任的机构签名的证书，则可以确保双方都在与自己认为的人进行通信。这样的受信任的机构称为“证书颁发机构”，并且证书用于身份验证。

Certificate Contents

证书将公钥与个人，服务器或其他称为主题的实体的真实身份相关联。如Table 1所示，关于主题的信息包括识别信息(专有名称)和公共密钥。它还包括颁发证书的证书颁发机构的标识和签名，以及证书有效的时间段。它可能具有其他信息(或 extensions)以及证书颁发机构使用的 Management 信息，例如序列号。

表 1：证书信息

Subject专有名称，公钥
Issuer专有名称，签名
有效期不早于日期，不晚于日期
Administrative Information版本，序列号
Extended Information基本约束，Netscape 标志等

专有名称用于在特定上下文中提供身份-例如，一个人可能拥有个人证书以及一个雇员身份的证书。专有名称由 X.509 标准\ [X509]定义，该标准定义了字段，字段名称和用于引用这些字段的缩写(请参见Table 2)。

表 2：专有名称信息

DN FieldAbbrev.DescriptionExample
Common NameCN名称被认证CN=Joe Average
组织或公司O名称与此<_ 11>组织相关联O =蛇油有限公司
Organizational UnitOU名称与此<_ 12>组织单位(例如部门)相关联OU=Research Institute
City/LocalityL名字位于这个城市L=Snake City
State/ProvinceST名称位于该 State/省ST=Desert
CountryC名称位于该国家(ISO 代码)C=XZ

证书颁发机构可以定义一个策略，以指定哪些专有字段名称是可选的，哪些是必填字段。证书的用户也可能对字段内容提出要求。例如，Netscape 浏览器要求代表服务器的证书的公用名与该服务器的域名的通配符模式匹配，例如*.snakeoil.com。

证书的二进制格式使用 ASN.1 表示法\ [ASN1][PKCS]定义。该符号定义如何指定内容，编码规则定义如何将此信息转换为二进制形式。证书的二进制编码是使用可分辨编码规则(DER)定义的，该规则基于更通用的基本编码规则(BER)。对于那些不能处理二进制的传输，可以使用 Base64 编码\ [MIME将二进制形式转换为 ASCII 形式。当放置在开始和结束定界线之间时(如下所示)，此编码版本称为 PEM(“隐私增强邮件”)编码证书。

PEM 编码的证书示例(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-----

Certificate Authorities

通过在授予证书之前验证证书请求中的信息，证书颁发机构可以确保自己拥有密钥对的私钥所有者的身份。例如，如果爱丽丝(Alice)要求提供个人证书，那么证书颁发机构必须首先确保爱丽丝(Alice)确实是证书要求的真实身份者。

Certificate Chains

证书颁发机构还可以为另一个证书颁发机构颁发证书。在检查证书时，爱丽丝可能需要针对每个父证书颁发机构检查颁发者的证书，直到获得她有信心的证书颁发机构为止。她可以决定仅信任发行者链有限的证书，以减少发生证书的风险。链中的“不良”证书。

创建根级 CA

如前所述，每个证书都要求发行者声明证书主体身份的有效性，直到最高级别的证书颁发机构(CA)。这带来了一个问题：谁可以担保没有颁发者的最高级别机构的证书？在这种独特情况下，证书是“自签名的”，因此证书的颁发者与主题相同。浏览器已预先配置为信任知名的证书颁发机构，但是在信任自签名证书时要格外小心。根权限广泛地公开了公钥，从而降低了信任此密钥的风险-很明显，如果其他人公开了一个声称是 Authority 的密钥。

许多公司(例如Thawte和VeriSign)已将自己构建为证书颁发机构。这些公司提供以下服务：

  • 验证证书申请

  • 处理证书申请

  • 颁发和 Management 证书

也可以创建自己的证书颁发机构。尽管在 Internet 环境中存在风险，但在企业可以轻松地验证个人和服务器身份的企业内部网中可能很有用。

Certificate Management

构建证书颁发机构是一项责任，需要坚实的 Management，技术和 Management 框架。证书颁发机构不仅颁发证书，而且还 Management 证书-也就是说，他们确定证书的有效期限，更新证书并保留过去颁发但不再有效的证书列表(证书吊销列表或 CRL)。

例如，如果爱丽丝(Alice)有权获得公司雇员的证书，但现在已经离开该公司，则可能需要吊销其证书。因为仅在验证了对象的身份之后才颁发证书，然后才可以将证书传递给与对象通信的所有人员，所以仅凭证书就无法确定证书已被撤销。因此，在检查证书的有效性时，有必要联系发行证书的证书颁发机构以检查 CRL，这通常不是过程的自动化部分。

Note

如果使用的证书颁发机构默认未将浏览器配置为信任，则有必要将证书颁发机构证书加载到浏览器中，以使浏览器能够验证由该证书颁发机构签名的服务器证书。这样做可能很危险，因为一旦加载，浏览器将接受该证书颁发机构签署的所有证书。

安全套接字层(SSL)

安全套接字层协议是可以放置在可靠的面向连接的网络层协议(例如，TCP/IP)和应用协议层(例如，HTTP)之间的协议层。 SSL 通过允许相互身份验证，使用数字签名进行完整性保护和加密以实现隐私保护，从而确保了 Client 端和服务器之间的安全通信。

该协议旨在支持用于加密，摘要和签名的特定算法的多种选择。这允许根据法律，Export 或其他方面的考虑为特定服务器选择算法，并使协议能够利用新算法。构建协议会话时，应在 Client 端和服务器之间协商选择。

表 4：SSL 协议的版本

VersionSourceDescription
SSL v2.0供应商标准(来自 Netscape Corp.)存在其实现的第一个 SSL 协议
SSL v3.0Internet 草案已过期(来自 Netscape Corp.)\ [SSL3]进行修订以防止特定的安全攻击，添加非 RSA 密码并支持证书链
TLS v1.0拟议的互联网标准(来自 IETF)\ [TLS1]修订 SSL 3.0，以将 MAC 层更新为 HMAC，为块密码添加块填充，消息 Sequences 标准化以及更多警报消息。
TLS v1.1拟议的互联网标准(来自 IETF)\ [TLS11]TLS 1.0 的更新，增加了针对密码块链接(CBC)攻击的保护。
TLS v1.2拟议的互联网标准(来自 IETF)\ [TLS12]TLS 1.1 的更新不赞成将 MD5 作为哈希值使用，并增加了与 SSL 的不兼容性，因此它将永远不会协商使用 SSLv2.

SSL 协议有许多版本，如Table 4所示。如此处所述，SSL 3.0 的好处之一是它增加了对证书链加载的支持。此功能允许服务器将服务器证书和颁发者证书一起传递到浏览器。链加载还允许浏览器验证服务器证书，即使未为中间发行者安装证书颁发机构证书，因为它们包含在证书链中。 SSL 3.0 是 Internet 工程任务组(IETF)当前正在开发的传输层安全性[TLS]协议标准的基础。

构建会话

通过遵循 Client 端和服务器之间的握手序列来构建 SSL 会话，如Figure 1所示。此 Sequences 可能会有所不同，具体取决于服务器是配置为提供服务器证书还是请求 Client 端证书。尽管在某些情况下，需要额外的握手步骤来 Management 密码信息，但本文总结了一种常见的情况。有关所有可能性的信息，请参阅 SSL 规范。

Note

一旦构建了 SSL 会话，就可以重新使用它。这样可以避免重复启动会话所需的许多步骤而导致的性能损失。为此，服务器为每个 SSL 会话分配一个唯一的会话标识符，该标识符在服务器中缓存，并且 Client 端可以在以后的 Connecting 使用该会话标识符以减少握手时间(直到会话标识符从服务器的缓存中过期为止)。

Figure 1：简化的 SSL 握手序列

Client 端和服务器使用的握手序列的元素如下所示：

  • 协商要在数据传输期间使用的密码套件

  • 在 Client 端和服务器之间构建并共享会话密钥

  • (可选)向 Client 端验证服务器

  • (可选)向服务器验证 Client 端

第一步是 Cipher Suite 协商，它允许 Client 端和服务器选择它们都支持的 Cipher Suite。 SSL3.0 协议规范定义了 31 个密码套件。密码套件由以下组件定义：

  • 密钥交换方法

  • 数据传输密码

  • 消息摘要，用于创建消息验证码(MAC)

以下各节将介绍这三个元素。

密钥交换方法

密钥交换方法定义了 Client 端和服务器将如何协商用于应用程序数据传输的共享 Secret 对称加密密钥。 SSL 2.0 仅使用 RSA 密钥交换，而 SSL 3.0 支持多种密钥交换算法，包括 RSA 密钥交换(使用证书时)和 Diffie-Hellman 密钥交换(用于在没有证书的情况下交换密钥，或者在 Client 端与服务器之间无需事先通信的情况下) )。

选择密钥交换方法的一个变量是数字签名-是否使用数字签名，如果使用，则使用哪种签名。使用私钥签名可以防止在用于生成共享密钥\ [AC96(p516)的信息交换期间出现中间人攻击。

用于数据传输的密码

SSL 使用传统的对称密码术(如前所述)来加密会话中的消息。有 9 种加密方式可供选择，包括不加密方式：

  • No encryption

  • Stream Ciphers

  • 带 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]专有的算法。

Digest Function

摘要功能的选择确定如何从记录单元创建摘要。 SSL 支持以下内容：

  • 没有摘要(无选择)

  • MD5，128 位哈希

  • 安全哈希算法(SHA-1)，160 位哈希

消息摘要用于创建消息身份验证代码(MAC)，该消息验证代码随消息一起加密，以验证完整性并防止重放攻击。

握手序列协议

握手序列使用三种协议：

  • 用于执行 Client 端和服务器 SSL 会话构建的 SSL 握手协议。

  • SSL 更改密码规范协议，用于在会话的密码套件上实际构建协议。

  • SSL 警报协议，用于在 Client 端和服务器之间传送 SSL 错误消息。

这些协议以及应用程序协议数据都封装在 SSL 记录协议中，如Figure 2所示。封装的协议通过不检查数据的下层协议作为数据传输。封装的协议不了解基础协议。

Figure 2：SSL 协议栈

记录协议对 SSL 控制协议的封装意味着，如果重新协商活动会话，则将安全地传输控制协议。如果没有以前的会话，则使用 Null 密码套件，这意味着在构建会话之前，不会进行加密，消息也不会具有完整性摘要。

Data Transfer

Figure 3中所示的 SSL 记录协议用于在 Client 端和服务器之间传输应用程序和 SSL 控制数据，必要时将该数据分为较小的单元，或将多个较高级别的协议数据消息组合为单个单元。在使用基础可靠的传输协议传输这些单元之前，它可能会压缩，附加摘要签名并对其进行加密(注意：当前，没有主要的 SSL 实现包含对压缩的支持)。

Figure 3：SSL 记录协议

保护 HTTP 通信

SSL 的一种常见用法是保护浏览器和 Web 服务器之间的 Web HTTP 通信。这并不排除使用非安全的 HTTP-安全版本(称为 HTTPS)与基于 SSL 的普通 HTTP 相同，但是使用 URL 方案https而不是http，并且使用不同的服务器端口(默认情况下为端口 443) 。 mod_ssl为 Apache Web 服务器提供的功能很大。

References

Name Apache 中文文档
Version
Language
Badge
Last Updated 2021-07-07T12:52