SSL/TLS互联网安全加密技术原理详解

SSL/TLS是一种互联网安全加密技术。原理比较复杂，枯燥无味。我也试图理解它，然后重新排列它以使其尽可能清晰。正文开始。

1。 SSL/TLS 概述

1.1 总体结构

SSL 是 HTTP 协议和 TCP 之间的可选层。它的位置大致如下：

• SSL：（Secure Socket Layer，安全套接字层），由Netscape公司开发，用于保证互联网上数据传输的安全性。采用数据加密（Encryption）技术，保证数据在网络传输过程中不被泄​​露。捕捉当前版本是3.0。它已广泛用于网络浏览器和服务器之间的身份验证和加密数据传输。
  SSL协议位于TCP/IP协议和各种应用层协议之间，为数据通信提供安全支持。 SSL协议可分为两层： SSL记录协议：基于可靠的传输协议（如TCP），支持高层协议的数据封装、压缩、加密等基本功能。 SSL 握手协议：SSL 基于记录协议，通信双方使用 SSL 来验证身份、就加密算法达成一致并在实际数据传输开始之前交换加密密钥。
• TLS：（Transport Layer Security，传输层安全协议），用于保证两个应用程序之间的机密性和数据完整性。
  TLS 1.0 是由互联网工程任务组 (IETF) 开发的新协议。它基于SSL 3.0协议规范，是SSL 3.0的更高版本。考虑 SSL 3.1。它被写在 RFC 中。该协议由两层组成：TLS 记录和 TLS 握手。底层是 TLS 记录协议，它位于 TCP 等可靠传输协议之上。

SSL/TLS协议提供的主要服务有：

1. 对用户和服务器进行身份验证，确保数据发送到正确的客户端和服务器；
2. 对数据进行加密，防止数据中途被盗；
3. 数据维护完整性确保数据在传输过程中不发生改变。

1.2 TLS 与 SSL 的区别

1. 版本号：TLS 记录格式与 SSL 记录格式相同，但版本号的值不同。 TLS 1.0 版使用的版本号是 SSLv3.1。
2. 消息认证码：SSLv3.0和TLS的MAC算法和MAC计算范围不同。 TLS 使用 RFC-2104 中定义的 HMAC 算法。 SSLv3.0 使用类似的算法。两者的区别在于，SSLv3.0中连接操作是在填充字节和密钥之间进行的，而HMAC算法使用的是XOR操作。但两者具有相同的安全级别。
3. 伪随机函数：TLS使用称为PRF的伪随机函数将密钥扩展到数据块，这是一种更安全的方法。
4. 报警代码：TLS支持几乎所有SSLv3.0报警代码，并且TLS还定义了很多报警代码，例如decryption_failed、record_overflow、unknown CA、访问被拒绝（access_denied）等。
5. 密文族和客户端证书：SSLv3.0 和 TLS 之间存在细微差别，即 TLS 不支持 Fortezza 密钥交换、加密算法和客户端证书。
6. certificate_verify 和completed 消息：当SSLv3.0 和TLS 使用certificate_verify 和completed 消息计算MD5 和SHA-1 哈希码时，计算的输入略有不同，但安全性相当。
7. 加密计算：TLS 和 SSLv3.0 在计算主密钥值时使用不同的方法。
8. Padding：在加密用户数据之前添加的填充字节。在SSL中，填充数据的长度必须至少是密文块长度的倍数。在TLS中，填充的数据长度可以是密文块长度的任意整数倍（但最大填充长度为255字节）。通过这种方法，可以防止基于消息长度分析的攻击。

TLS的主要发展

TLS的主要目的是让SSL更加安全，让协议规范更加精确和完整。基于 SSL v3.0，TLS 提供了以下改进：

1. 更安全的 MAC 算法
2. 更严格的警报
3. 更清晰的“灰色地带”规范定义

   使用 TLS 进行安全密钥身份验证：TLS 是“消息验证码”（HMAC），它确保当记录通过开放网络（例如互联网）传输时，记录不会被更改。SSLv3.0还提供密钥消息认证，但HMAC比SSLv3.0使用的MAC（消息认证码）功能更安全。

4. 增强型伪随机函数（PRF）：PRF 生成关键数据。在 TLS 中，HMAC 定义了 PRF。 PRF 使用两种哈希算法来保证其安全性。如果任何一种算法可用，数据将保持安全，直到第二种算法公开。
5. 改进了已完成消息的验证：TLS 和 SSLv3.0 都为两个端点提供已完成的消息，以验证交换的消息未被修改。然而，TLS 将此完整消息基于 PRF 和 HMAC 值，这也比 SSLv3.0 更安全。
6. 一致的证书管理：与 SSLv3.0 不同，TLS 尝试定义要在 TLS 之间交换的证书类型。
7. 特殊警报消息：TLS 提供更准确的附加警报来指示任何会话端点检测到的问题。 TLS 还跟踪何时应发送某些警报。

2。密钥协商流程-TLS握手

SSL协议分为两部分：握手协议和记录协议。握手协议用于协商密钥。协议的很大一部分内容是通信双方如何使用它来安全地协商密钥。记录协议定义了传输格式。

由于非对称加密速度比较慢，所以通常用于密钥交换。双方通过公钥算法商定密钥，然后使用对称加密进行通信。当然，为了保证数据的完整性，加密前必须经过HMAC处理。

SSL默认只进行服务器端认证，客户端认证是可选的。显示以下流程图（来自 TLS 协议）。 † TLS协议的传输过程 这是我们保证数据正常加解密的唯一方法。在TLS握手阶段，客户端首先要告诉服务器自己支持哪些加密算法，因此客户端必须向服务器发送本地支持的密码套件（Cipher Suite）列表。此外，客户端还必须生成一个随机数。这个随机数必须保存在客户端并发送到服务器。客户端的随机数必须与服务器生成的随机数相结合才能产生下面我们来谈谈主密钥。

综上所述，在这一步中，客户端主要向服务器提供以下信息：

1. 支持的协议版本，例如TLS 1.0
2. 客户端生成的随机数，稍后生成。 “conversation Secret”密钥为“
3. 支持的加密方法，例如 RSA 公钥加密
4. 支持的压缩方法

2.2 服务器响应（SeverHello）

上图中 Server to Done，Hello some server实现 每条消息都是单独发送的，由服务器实现将它们组合起来发送。 Server Hello 和 Server Ready 数据仅包含标头，没有内容。

服务器收到客户端的Client Hello消息后，必须将其证书发送给客户端。该证书是对服务器的认证。比如客户端收到一个自称是www.alipay.com的数据，但是如何验证对方是不是这个，这就是证书的作用。支付宝的证书可以证明是支付宝，不是财付通。证书是一种电子证书，必须由专门的数字证书颁发机构 (CA) 申请并经过严格审查后颁发。颁发证书时，会生成私钥和公钥。私钥由服务器自己保存，不能泄露。公钥包含在证书信息中，可以公开。证书本身还包括证书的电子签名。该签名用于验证证书的完整性和真实性，并防止证书被更改。此外，该证书还有有效期。

当服务器发送给客户端的证书没有提供足够的信息（证书公钥）时，还可以发送服务器密钥交换给客户端，

此外，在非常重要的机密数据的情况下、服务客户端必须验证客户端，以确保将数据传输给安全合法的客户端。服务器可以向客户端发送证书请求消息，要求客户端发送证书来验证客户端的合法性。例如，金融机构通常只允许经过认证的客户连接到其网络，并为授权客户提供包含客户证书的 USB 密钥。

与客户端一样，服务器必须生成一个随机数并将其发送给客户端。客户端和服务器都必须使用这两个随机数来生成 Master Secret。

最后，服务器端向客户端发送Server Hello Done消息，表示Server Hello消息已经结束。

综上所述，该步骤的服务器响应包含以下内容：

1. 确认所使用的加密通信协议的版本，例如TLS版本1.0。如果浏览器支持的版本与服务器不一致，则服务器关闭加密通信
2. 服务器生成的随机数，稍后用于生成“会话密钥”
3. 确认使用的加密方式，如RSA公钥加密
4. 服务器证书

2.3 客户端响应（证书验证）

客户端密钥交换

如果服务器必须首先从服务器接收客户端的消息，则服务器必须报告它。发送客户端的证书，让服务器验证客户端的合法性。

证书验证
接下来，客户端必须验证服务器的证书。如果证书不是由不受信任的组织颁发的，或者证书中的域名与实际域名不匹配，或者证书已过期，则会向访问者显示一条消息。注意，用户决定是否继续通信。如果证书没有问题，客户端将从服务器的证书中检索服务器的公钥。然后向服务器发送以下三条信息：

1. 随机数。随机数用服务器的公钥加密，防止窃听
2. 编码更改通知，表示后续信息将使用双方同意的加密方法和密钥发送 握手阶段完成。该元素也是之前发送的所有内容的哈希值，用于验证服务器。客户端使用某种加密。该算法（例如：RSA、Diffie-Hellman）生成 48 字节密钥。该密钥称为 PreMaster Secret，在许多资料中也称为 PreMaster Key。

   ChangeCipherSpec
   ChangeCipherSpec 是一种独立协议，在数据包中显示为一个字节的数据。用于通知服务器客户端已经切换到先前协商的密码套件（Cipher Suite）的状态。使用事先商定的加密程序对数据进行加密和传输。

   完成ChangecipherSpec传输后，客户端使用之前协商好的加密包和Session Secret对Finish数据进行加密并发送给服务器。该数据用于加密和解密在正式传输应用程序数据之前立即建立的握手。控制通道。

   2.4 服务器完成

   服务器收到客户端发来的PreMaster加密数据后，使用秘钥对加密数据进行解密并验证数据。会话密钥的生成方式与客户端相同。一切准备就绪后，它会向客户端发送 ChangeCipherSpec，通知客户端已更改为协商密码套件状态，并准备好使用密码套件和 Session Secret 来加密数据。然后服务器使用Session Secret对Completion消息进行加密并发送给客户端，以验证之前握手建立的加解密通道是否成功。

   根据之前的握手信息，如果客户端和服务端都能正常加解密Finish信息，并且该消息已被正确验证，则说明握手通道已成功建立。然后双方都可以使用上面生成的会话密钥。数据经过加密传输。

   2.5 更多秘密 深入理解和掌握这些秘密密钥非常重要。因此，我们将这些秘钥提取出来并分别进行分析和解释。

   首先我们来看看这些秘钥的生成过程和功能流程图。这将用于生成主密钥，并结合服务器和客户端在 Hello 阶段生成的随机数。客户端使用服务器的公钥来加密PreMaster Secret，然后将其发送到服务器。服务器使用私钥解密并获取PreMaster Secret。换句话说，服务器和客户端都具有相同的 PreMaster 密钥和随机数。

   PreMaster 密钥的前两个字节是 TLS 版本号。对于验证握手数据来说，这是一个更重要的版本号，因为在 Client Hello 阶段，客户端会发送当前支持的密码套件的列表。 SSL/TLS 版本号由服务器接收并以明文形式传输。 。如果握手数据包被破解，攻击者很可能会修改数据包并为服务器选择安全性较低的密码套件和版本。 ，从而破解数据。因此，服务器必须将密文中解密的PreMaster版本号与之前的Client Hello阶段的版本号进行比较。如果版本号变低，则说明发生了变化，会立即停止发送消息。

   PreMaster Secret（Key）的计算请参见Https SSL/TLS PreMaster/Master Secret（Key）计算。

   Master Secret
   如上所述，由于服务器和客户端都具有相同的 PreMaster Secret 和随机数，因此该随机数将作为后续生成 Master Secret 的种子，与 PreMaster Secret 结合，客户端和服务客户​​端一样计算一个主密钥。

   主密钥由一系列哈希值组成，这些哈希值用作与数据加密和解密相关的密钥的密钥材料的一部分。通过密钥材料分析最终数据如下：
   

   其中，输入MAC密钥是会话密钥还是会话密钥。客户端的写 MAC 密钥是客户端用于发送数据的会话密钥，服务器的写 MAC 密钥是服务器用于发送数据的会话密钥。 MAC（消息验证码）是一种数字签名，用于验证数据的完整性并检测数据是否已被更改。

   要计算会话密钥（密钥），请参阅 Https SSL/TLS 会话密钥（密钥）计算。

   2.6 应用程序数据传输

   所有握手阶段完成后，即可开始应用程序数据传输。在传输应用数据之前，必须首先附加MAC密钥，然后必须使用写加密密钥对数据包进行加密。服务器收到密文后，使用客户端的写入加密密钥对其进行解密。客户端收到服务器发来的数据后，使用服务器的写入加密密钥对其进行解密，然后使用相应的写入MAC密钥来验证数据的完整性，包括是否被修改。验证。

   2.7 小结

   SSL客户端（也是TCP客户端）建立TCP连接后，发送ClientHello发起握手。该消息包含它可以实现的算法列表以及其他必要的消息。 SSL 服务器用 ServerHello 进行响应，指定通信所需的算法，然后发送自己的证书（其中包含其身份和自己的公钥）。客户端收到此消息后，会创建一条秘密消息，用 SSL 服务器的公钥对其进行加密并传输。一旦SSL服务器用自己的私钥解密，会话密钥协商成功，双方可以使用相同的会话密钥进行通信。

   3。附录：关键协议的视觉隐喻

   如果上面的解释还不够清楚，这里有一个生动的隐喻。我们假设A与B进行通信。 A 是 SSL 客户端，B 是 SSL 服务器。 ，加密消息括在方括号 [] 中，以突出与明文消息的区别。括号()中是对双方处理操作的描述。

   A：我想安全地和你说话。我这里使用的对称加密算法包括DES和RC5，密钥交换算法包括RSA和DH，摘要算法包括MD5和SHA。

   B：使用 DES-RSA-SHA 组合。
   这是我的证书，包含我的姓名和公钥。你可以用它来验证我的身份（将证书发送给A）。
   目前没什么可说的。

   A：（检查证书上B的名字是否正确，并通过现有CA的证书验证B的证书的真实性。如果有任何一项不正确，则发出警告并断开连接。这一步保证了真实性B的证书.公钥）
   （处理后生成一条秘密消息，将用作加密密钥、加密初始化向量（IV）和hmac密钥。转换此秘密消息-在协议中命名为per_master_secret - 使用公钥 B 和 a 进行加密，它包含在名为 ClientKeyExchange 的消息中。由于我们使用B的公钥，所以保证第三方无法窃听）
   我创建了一条秘密消息，用你的公钥加密它并给你（发送ClientKeyExchange给B）
   注意，下面的I。我将发送加密消息！
   （处理密文，生成加密密钥、加密初始化向量和hmac密钥）
   【完成】

   B：（使用自己的私钥在ClientKeyExchange中解密密文，然后处理秘密消息以创建加密密钥、加密初始化向量和hmac密钥。目前，双方已经安全地商定了加密方法）
   注意，我也想开始使用加密。他给你发消息了！ †2000年底的文章《The End of SSL and SSH?》，引起很大争议。还有一些成熟的工具，例如允许中间人攻击的 dsniff (http://www.monkey.org/~dugsong/dsniff/)。它拦截 https 消息。

   从以上原理可以看出，SSL的结构是严格的，在实际应用中往往会出现不严格的问题。一种常见的攻击是中间人攻击，这意味着当 A 和 B 进行通信时，第三方 C 位于信道中间，可以完全听到 A 和 B 之间正在通信的消息，并且可以拦截、替换并添加到这些消息中。 。

   1. SSL允许各种密钥交换算法，而有些算法，如DH，没有证书的概念，所以A无法验证B的公钥和身份的真实性，所以C可以很容易地冒充自己并使用他自己。钥匙与双方进行通信，从而窃听对方所说的话。
      必须使用经过认证的密钥交换算法来防止中间人攻击。
   2. 获得证书后，如果C将原来的证书替换为自己的证书，A的浏览器中会出现警告窗口，但是有多少人会注意到这个警告呢？
   3. 由于美国密码出口限制，IE、Netscape等浏览器支持的加密强度非常弱。如果只使用浏览器自带的加密功能，理论上是可以破解的。？ com.之后，代理就完全变成了一个内容交付工具。浏览器和Web服务器创建一个安全通道，因此这个安全通道是端到端的。虽然所有信息都流经代理，但其内容无法被代理解密或修改（当然，它必须有证书支持，否则这个地方很容易成为中间人攻击的好地方，请参阅上面的安全部分）。