本文参考《图解密码技术》， 从HTTPs 为什么比HTTP 安全的角度梳理多个和密码相关的知识点， 希望对你有帮助。

以下内容介绍，均基于Alice 向Bob 发送邮件为基础进行介绍

1. 前置知识

1.1 计算机网络

在了解密码具体知识前，需要先了解一下传输信息的计算机网络。
主要有2点

  1. 计算机网络是分层的
  2. 网络传输依赖一系列中间设备 网络传输并不是简单的A点到B点的直接通信，而是依赖于一系列中间设备。
  3. 当我们在互联网上发送数据时（例如发送一封电子邮件），数据不会以单一的整体方式进行传输。相反，它会被拆分成许多小的“数据包”（packets），每个数据包包含发送方、接收方以及数据本身的一部分。这些数据包会经过复杂的路径传输，最终在目标设备处重新组合，恢复成完整的消息。

1.1.1 计算机网络是分层的

1.1.2 网络传输依赖于一系列中间设备

网络传输并不是简单的A点到B点的直接通信，而是依赖于一系列中间设备。这些中间设备包括路由器、交换机、服务器、网关等，它们共同协作以确保数据包能够从源点传输到目标点。

在此过程中，每个中间设备都有可能成为窃听的切入点。为了理解这些中间设备如何导致窃听的可能性，我们先从网络的工作原理开始，然后逐步深入探讨中间设备如何影响数据的安全性。

为了使数据从A点传输到B点，它必须经过多个中间设备，这些设备主要包括：

  • 路由器（Router）：路由器在不同网络之间转发数据，它通过读取数据包中的目标地址来决定数据包应该被发送到哪个下一跳路由器。路由器实际上是决定数据传输路径的关键设备。
  • 交换机（Switch）：交换机通常在局域网（LAN）中使用，它负责根据数据包中的MAC地址在局域网内部的设备之间转发数据。
  • 防火墙（Firewall）：防火墙用于监控网络流量，阻止不安全或未经授权的通信。虽然防火墙并不负责路由，但它是数据包在传输时必须经过的设备之一，它在数据包进入或离开网络时检查流量。
  • 网关（Gateway）：网关是网络中的特殊设备，它负责在不同网络协议或不同网络之间转换数据。它们通常位于不同类型网络的边界上。
  • 服务器：在某些情况下，数据包可能会通过中间服务器进行处理。例如，当你发送电子邮件时，邮件首先被发送到邮件服务器，然后服务器根据接收者的地址将其传送到目标邮件服务器。

数据包在互联网中传输时，必须经过这些中间设备，依靠它们来找到最终的目标地址。因此，网络传输并不是简单的两台设备直接通信，而是通过一系列中间设备和多次转发实现的。

1.2 加密安全特性

现代加密系统关注的一些安全特性：

  1. 消息的机密性（Confidentiality）：指确保消息在传输过程中不会被未授权的第三方窃取，即使被窃取，也无法解读消息的真正含义。
  2. 消息的完整性/防篡改（Integrity）： 是指确保消息在传输过程中没有被修改。如果消息被篡改，接收方应该能够识别出这一点。
  3. 消息的认证（Authentication）：认证是指确认消息的发送者是谁，确保接收方能够识别消息的合法发送者。这意味着接收方可以确信消息确实是来自声称的发送者，而不是来自其他未授权的第三方。
  4. 消息发送者的认证与防止否认（Non-repudiation）：指一旦确定消息来自某个发送者，发送者就不能否认自己发送了这条消息。也就是说，发送方在发送消息后，无法声称自己没有发送过该消息。

1.3 密码学工具箱

  1. 对称加密
  2. 非对称加密
  3. 消息认证码
  4. 数字签名
  5. 单向散列函数
  6. 伪随机数

1.4 加密算法-机密性

加密与摘要的本质区别就在于，摘要是不可逆的，而加密是可逆的，逆过程就是解密。

在经典密码学时代，加密的安全主要是依靠机密性来保证的，也就是依靠保护加密算法或算法的执行参数不被泄露，来保障信息的安全。而现代密码学并不依靠机密性，加解密算法都是完全公开的，信息的安全是建立在特定问题的计算复杂度之上。具体来说，就是算法根据输入端计算输出结果，这里耗费的算力资源很小；但根据输出端的结果反过来推算原本的输入，耗费的算力就极其庞大。

1.4.1 对称加密算法

加密、解密使用同一个密钥 称之为对称加密。

就像我们用保险箱存取贵重物品一样，存的时候用一把钥匙打开门把贵重物品放进去，取的时候 也是用同一把钥匙打开门把贵重物品取出来。

常见的对称加密算法

DES

DES 是一种分组加密算法，采用64位的明文分组进行加密，并且使用56位的密钥进行加密操作（虽然密钥的实际长度是64位，但其中8位用于校验）。
现代计算能力可以在短时间内通过暴力破解尝试所有可能的密钥，从而解密DES加密的数据。因此，DES在现代已被视为不安全的加密算法。

三重DES
3DES是为了增强DES的安全性而设计的。它通过重复DES加密过程三次来提高加密强度，从而克服了DES密钥过短的问题。
3DES使用三个不同的56位密钥，进行三轮DES加密解密操作：首先使用第一个密钥加密数据，然后用第二个密钥解密，最后再用第三个密钥加密。这个过程可以有效地增强DES的加密强度。

虽然3DES比DES安全，但是计算速度也更慢，所以在现代应用中，除一些遗留系统外，它已经被更新的加密标准AES所取代

AES
AES是目前最常用的对称加密算法，并被广泛用于政府、金融、军事和商业应用中。它已经取代了DES和3DES，成为主流的加密标准。

AES是一种分组加密算法，支持128位、192位或256位的密钥长度，且使用128位的固定分组大小。

分组加密

从前面的描述中可以看到，DES 和AES 都属于分组加密算法，他们只能加密固定长度的明文， 如果需要加密任意长度的明文，就需要将明文分组然后加密迭代。

分组加密算法有多种工作模式，包括ECB、CBC、CFB、OFB、CTR

1.4.2 非对称加密算法

加密、解密使用不同的密钥 称之为非对称加密。
加密过程使用的密钥通常称之为私钥，解密过程使用的密钥通常称之为公钥

公钥和私钥确实是通过特定的数学算法生成的密钥对，它们紧密相连

  • 公钥加密、私钥解密：在典型的加密场景中（如RSA加密），公钥用于加密数据，私钥用于解密数据。这使得任何拥有公钥的人都可以加密数据，但只有拥有私钥的人可以解密。
  • 私钥签名、公钥验证：在数字签名场景中，私钥用于对数据进行签名，公钥用于验证签名的真实性。也就是说，私钥生成的签名可以被公钥验证，而不泄露私钥。
    1. 公钥加密，私钥解密，这种就是加密，用于向私钥所有者发送信息，这个信息可能被他人篡改，但是无法被他人得知。举个例子，如果甲想给乙发一个安全保密的数据，那么应该甲乙各自有一个私钥，甲先用乙的公钥加密这段数据，再用自己的私钥加密这段加密后的数据，最后再发给乙。这样确保了内容既不会被读取，也不能被篡改。
  1. 私钥加密，公钥解密，这种就是签名，用于让所有公钥所有者验证私钥所有者的身份，并能用来防止私钥所有者发布的内容被篡改。但是它不用来保证内容不被他人获得。

缺点

  1. 加密效率低且不能直接用于大量数据的加密。因此非对称加密算法，并不适合直接用户加密传输大量明文
  2. 无法解决中间人攻击，具体内容放在下面说

密传输问题
公钥的传输依然有可能被第三方获取， 从而导致中间人攻击，后面会具体介绍。

1.4.3 单向散列函数-识别篡改

一般这个性质叫做防篡改， 我觉得叫做识别篡改更准确。

单向散列函数（也称为哈希函数）不能主动防止内容的篡改，但它可以通过生成固定长度的哈希值来检测内容是否被篡改。

单向散列函数的主要特点：

  1. 固定长度输出：无论输入数据的长度如何，散列函数生成的哈希值长度总是固定的。比如SHA-256总是输出256位的哈希值。
  2. 单向性：散列函数是单向的，意味着很难从哈希值反推原始数据。
  3. 相同输入相同输出：如果两次输入的数据相同，那么散列函数的输出也一定相同。
  4. 微小的输入变化会导致完全不同的输出：称为“雪崩效应”，即使输入数据只有一个比特的变化，生成的哈希值也会完全不同。

单向散列函数是一种将任意长度的输入（如文件、消息）映射为固定长度输出（称为哈希值、消息摘要）的算法。常见的单向散列函数有：

  • MD5（虽然已经被认为不安全）
  • SHA-1（也已不推荐使用）
  • SHA-256、SHA-3 等较新的哈希算法

1.4.4 消息认证码-识别篡改 & 认证

消息认证码（MAC, Message Authentication Code） 是一种通过共享的对称密钥生成的固定长度的校验值，用于确保消息的完整性和认证性。MAC的主要功能是：

  • 完整性：指的是数据在传输过程中是否被篡改。MAC通过计算消息的哈希值并结合共享密钥生成一个认证码（MAC值）。接收方使用同样的密钥计算MAC值并与接收到的MAC值进行对比，从而确认消息是否被篡改。
  • 认证性：由于MAC是基于双方共享的对称密钥生成的，只有持有该密钥的合法发送者才能生成正确的MAC值，因此接收方可以通过验证MAC值来确认消息的发送者是持有密钥的合法参与者。

消息认证码（MAC） 的两个主要特性都是基于共享密钥的安全性来实现的。如果共享的密钥被第三方窃取，MAC的这两个特性就不复存在。

尽管在密钥安全的前提下，MAC能够识别篡改和认证消息的发送者身份，但它存在一个明显的局限性：无法防止消息发送者的否认，这在密码学中称为不可否认性（Non-repudiation）。

在使用MAC时，发送方和接收方都持有相同的对称密钥，这意味着：

  • 接收方和发送方都可以生成和验证相同的MAC值。由于双方共享相同的密钥，任何一方都可以计算出有效的MAC。
  • 如果发送方之后否认曾发送过某条消息，接收方没有办法证明发送方确实发送了这条消息，因为接收方自己也可以生成相同的MAC值。

因此，消息认证码不能提供不可否认性。在法律或信任系统中，接收方无法向第三方（如法庭）证明某个特定消息是由发送方发出的，因为双方共享同一个密钥，任何一方都可以生成有效的MAC。这使得发送者有可能否认曾发送消息，或者接收方可能伪造消息并声称是发送方发送的。

1.4.5 数字签名-认证 & 防止否认

数字签名依赖于非对称加密的核心机制，即使用私钥进行签名、使用公钥进行验证，从而能够完成认证不可否认两个特性。

如果签名验证通过，接收方可以确认消息确实来自持有该私钥的发送者。这就是认证性，即确保消息的发送者身份是真实的。

由于只有私钥持有者能够生成有效的签名，发送方无法否认自己曾经对消息进行过签名。这就是不可否认性。

1.4.6 消息认证码认证 vs 数字签名认证

MAC（消息认证码）通过共享的密钥，认证消息确实来自通信对方，但是它一个非常大的缺点就是没有强身份认证，即不认证具体身份

  1. 由于双方共享同一个密钥，MAC 只能证明消息来自拥有该密钥的一方，但如果多个实体共享同一个密钥，无法确定到底是哪一个实体发送的消息。也就是说，MAC 没有强身份认证功能，无法防止发送者后来否认自己发出的消息（不可否认性问题）。
  2. 同时由于没有身份认证，在密钥泄漏的情况下，也无法识别中间人攻击

数字签名则提供了一种强身份认证的认证类型，确保消息来自某个具体的发送者， 同时可以防止否认

2. HTTP -通信使用明文可能会被窃听

Alice 发出的邮件通过计算机网络传输给Bob, 邮件传输的过程中需要经过一系列中间设备。这些设备或节点被恶意控制或监控，那么邮件就有可能被窃听。
黑客或其他有恶意意图的人，可以在这些节点上安装窃听软件，或者通过物理方式接入网络来截获数据, 进而做篡改或者中间人攻击等

既然窃听是因为网络传输需要经过设备造成的，那么一种理想的解决办法就是，点对点通信。

如果Alice和Bob的计算机之间有一个完全物理隔离的、私有的连接（比如一根专线或者光纤），且中间没有任何其他设备介入，那么窃听的风险将会大幅减少。

这样的情况在一些高安全性、需要严格保密的环境中确实有可能实现，像是军事用途、金融系统内部的特殊通信等。但实现成本非常高。

且即便完全避免中间设备的参与没有经过加密处理的数据在传输过程中被截获（例如通过物理入侵或电磁信号泄漏），信息同样可能被窃听。

因此，关键的问题不仅在于是否经过中间设备，而是 通信的安全性依赖于数据加密技术的有效性。

而现代密码学并不依靠机密性，加解密算法都是完全公开的，信息的安全是建立在特定问题的计算复杂度之上。具体来说，就是算法根据输入端计算输出结果，这里耗费的算力资源很小；但根据输出端的结果反过来推算原本的输入，耗费的算力就极其庞大。

2.1 对称加密-保证消息机密性

由于在HTTP中一切信息都是明文传输，一旦发生窃听，第三个人立马就能读懂其中的含义。

那如果信息发送者Alice 将内容加密，Bob 收到信息解密后再阅读内容， 则第三方即使窃听到传输内容，也读不懂，是不是就可以保证传输内容不泄漏了？

是的，这是一个思路，这里可以使用高效的对称加密算法算法。

2.2 非对称加密算法-安全传输密钥

在使用对称加密算法高效加密明文时保证机密性的思路中，存在一个问题， 这个密钥如何被Alice 和Bob 双方安全共享。

假设Alice 生成了密钥，Bob 也必须获取到才能进行解密，否则就和窃听者一样即使拿到邮件内容也无法得知其含义。

Bob 如何获取到密钥，无非就2种方式

  1. 俩人见面，线下给密钥
  2. 网络传输密钥

本文我们可以规定一切行为都发生在网络上， 那么通过网络传输密钥时依然是明文，也就是说窃听者可以通过和窃听邮件内容一样的方式获取到明文传递的密钥。

关于密钥被窃听有2种应对方式

  1. 钻牛角尖思考，到底有什么方法可以让密钥安全传输呢 - 基本无解，有解的话直接传输内容本身就可以了
  2. 换个思路，即使密钥被窃听到也不影响内容加密传输是不是也可以 。 那这里就可以非对称加密算法

非对称加密算法 有2种用法

  1. 公钥加密，私钥解密 - 对应加密场景
  2. 私钥加密，公钥解密 - 对应数字签名场景

在本小节中，先关注公钥加密、私钥解密这种场景，

如下图， 如果Alice 想给Bob 发送加密消息，需要Bob先将他的公钥通过网络明文传输给Alice, 这个过程公钥即使被窃听到也没关系

因为窃听者没有解密私钥，后面即使窃听到Alice 发给Bob 的加密信息，也无法解密用公钥加密后的内容。

2.3 混合加密系统-既安全又高效

根据前面的内容可以看出

  1. 对称加密算法可以使用分组方式，对大量明文进行高效加密，但是其密钥本身的安全传输是一个问题
  2. 非对称密钥 很好的解决了对称加密密钥被窃取的问题，但是它又不适合用户对大量明文进行加密

可以考虑将二者的优点结合形成混合加密系统。

混合加密系统通过利用非对称加密的强大安全性和对称加密的高效性，能够实现既安全又高效的数据加密。

其核心思想是分为2步

  1. 密钥交换：使用非对称加密（如RSA或ECC）来加密和交换对称加密密钥。由于非对称加密仅用于加密短小的对称密钥（如AES的256位密钥），计算开销较小，速度相对可接受。

  2. 数据加密：一旦通过非对称加密安全地交换了对称密钥，实际的数据传输就使用高效的对称加密算法（如AES）。对称加密的加密速度非常快，能够处理大量的数据，适用于文件加密、实时视频流加密等场景。

  3. 安全性和性能的平衡：这种方法兼具了非对称加密的安全性（用于密钥交换）和对称加密的效率（用于大数据加密），是现代安全通信的基础。HTTPS、SSH、PGP等安全协议都采用了这种混合加密模型。

2.4 消息认证码-既防篡改又能认证

防篡改和认证性质的实现见上文。

2.5 数字签名-无法否认且能认证

如果Alice使用Bob 的公钥加密消息发送给Bob, 如何能确定这条消息一定是Alice发出的，因为窃听者同样可以拿到Bob 的公钥，然后以Alice 的口吻向Bob 发送消息。Bob 如何确定一条消息一定是Alice 发出的， 而不是窃听者冒充Alice 发出的。

这里可以使用非对称加密：私钥加密，公钥验证这个流程 ， 完成数字签名的功能，来保证消息一定是Alice 发出的， 且Alice 无法否认自己发出过这条消息。

关于私钥加密，公钥验证为什么就能保证消息就一定是私钥持有者发出的

当然，物理世界中私钥被窃取，在加密这样的网络世界是管不到的

2.6 中间人攻击下，公钥的认证问题

由于非对称加密中公钥需要通过网络明文传输给Alice， 那么就是可以被窃听获取到的。

此时如果有一个主动攻击者Molly 自己也生成一个非对称加密密钥对， 他在窃取到Bob传递给Alice 后公钥后， 篡改成自己的公钥发送非Alice， 此时Alice 没有什么手段可以判断这个公钥到底是不是Bob, 他如果直接拿来加密内容，传输给Bob, Molly 继续窃取这个内容，由于Alice实际用来加密的公钥匙Molly 的， 此时Molly 就可以用自己的私钥进行解密获取具体内容。

中间人攻击的风险：

  • 公钥篡改：如果 Alice 想与 Bob 通信，但攻击者（Mallory）冒充 Bob 拦截了 Alice 请求的公钥，并替换为自己的公钥。Alice 会误以为她在使用 Bob 的公钥加密信息，但实际上传输的对称密钥被 Mallory 用自己的私钥解密。
  • 认证性问题：Alice 需要确认她收到的公钥确实是 Bob 的，而不是来自攻击者。因此，公钥的认证是一个关键问题。

基于以上解释，你应该可以理解， 公钥的“安全配送”并不是像对称加密密钥的安全配送那样，不被人窃取， 而是在明文传输的前提下，即使被窃取，收到公钥的人也要能识别出来，也就是说Alice 在收到公钥后，要能100%确定 这个公钥一定是Bob 的， 如果被中间人窃听篡改了，Alice 需要识别出来，不用这个公钥。

如果仍然考虑公钥的网络安全传输问题，将继续陷入“如果能安全传输密钥，那就肯定能安全传输明文”的死循环。

为了打破这个循环，引入第三方可信机构成为了解决方案的关键。具体来说，这一机构就是证书颁发机构（CA, Certificate Authority），它的作用是通过公钥基础设施（PKI, Public Key Infrastructure）来验证和管理公钥，确保公钥的传输是安全的。

2.6.1 CA-公钥的数字签名

数字证书认证机构(CA,Certificate Authority)。数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。

  • 证书颁发机构（CA）如何工作：
    1. 身份验证：Bob 向 CA 提交身份信息和公钥，申请一个数字证书。CA 验证 Bob 的身份，确认公钥确实属于 Bob。这个身份验证可以是电话、邮箱等方式
    2. 签发证书：CA使用自己的私钥 对 Bob 的身份和公钥进行数字签名，生成一个数字证书，并将该证书发给 Bob。证书中包含 Bob 的身份信息、他的公钥，以及 CA 的数字签名。
    3. 公钥验证：Alice 在与 Bob 通信时，收到 Bob 提供的数字证书。她可以使用 CA 的公钥验证证书的签名，确保她获得的公钥没有被篡改，从而防止中间人攻击。即使攻击者在传输过程中试图篡改公钥，Alice 也能通过验证 CA 的签名识别出这种篡改。

2.6.2 CA公钥的获取-操作系统和浏览器预装的根证书

在证书颁发机构（CA） 的工作流程中，Alice 需要使用 CA 的公钥来验证 Bob 的数字证书是否有效，从而确保 Bob 的公钥未被篡改。那么Alice 如何获取 CA 的公钥呢？
实际上，Alice 不需要主动从网络上获取 CA 的公钥，因为这样会产生安全隐患。相反，CA 的公钥通常通过操作系统和浏览器预装的根证书

现代操作系统和浏览器（如 Windows、macOS、Linux，Chrome、Firefox、Safari 等）通常都会预装一组可信任的根证书，这些根证书由全球广泛认可的证书颁发机构（CA）提供。每个根证书都包含 CA 的公钥，并被操作系统或浏览器标记为可信任的。

根证书的作用：

  • CA 的身份认证：根证书是 CA 的自签名证书，它包含 CA 的身份信息和公钥，以及 CA 自己用其私钥对证书签名的数字签名。因为这些证书是由操作系统或浏览器厂商直接植入的，Alice 可以信任这些根证书中的公钥。
  • 验证链证书的可信度：当 Alice 收到 Bob 的数字证书时，Bob 的证书通常是由中间 CA 签发的，而中间 CA 的证书会由上一级的 CA 签发，最终形成一个信任链。通过验证链中的证书，Alice 可以逐级追溯到操作系统或浏览器中内置的根证书，从而验证 Bob 的证书。

预装根证书的好处：

  • 安全性：根证书是直接通过操作系统和浏览器厂商提供的，因此这些公钥的获取过程是安全的，不需要通过网络传输，避免了中间人攻击的风险。
  • 自动验证：当 Alice 在浏览器中访问一个网站（如 Bob 的网站）时，浏览器会自动使用系统或浏览器中的根证书来验证该网站证书的可信度，无需 Alice 手动获取或验证 CA 的公钥。

3. 密钥交换方法

通过CA 解决了公钥的认证问题，下面来总结一下，对称加密算法中密钥的安全传输问题。
密钥交换一般有以下4种方式

  1. 公钥密码交换算法
  2. Diffie-Hellman 密钥交换算法
  3. 使用密钥分配中心
  4. 事先共享密钥

3.1 公钥密码交换算法

即我们在前面介绍的混合加密系统中，在公钥认证问题解决的前提下， 通过非对称加密算法加密传输密钥

3.2 Diffie-Hellman 密钥交换

Diffie-Hellman（DH）密钥交换协议是一种安全密钥交换的方法，它允许两个不相互信任的实体在不预先共享密钥的情况下，通过一个不安全的信道生成共享的加密密钥。该方法依赖于特定的数学问题（如大整数的离散对数问题），这些问题在现有计算能力下很难快速破解，因此确保了密钥交换的安全性。

  1. 公用参数选择：首先，通信双方A和B选择一个公共的素数p和一个基数g，这些值可以在公共信道中传输，无需保密。
  2. 生成私钥：双方分别选择一个私有的随机数a（A的私钥）和b（B的私钥），这些值不会在通信中公开。
  3. 计算共享值：A计算A_value = g^a mod p，B计算B_value = g^b mod p。然后A和B将各自的计算结果通过公共信道交换

3.3 事先共享密钥（Pre-shared Key, PSK）

事先共享密钥（PSK）是一种传统的加密方法。在这种方式中，通信双方需要预先通过某种安全途径共享一个密钥。这个密钥可以通过线下物理方式进行传输，例如通过安全的信道、面对面的会晤、信件或电话。这种方式通常用于小范围或高度安全的环境中，例如在公司内部网络、军事通信或物联网设备之间。

  1. 密钥生成：首先，通信的双方需要决定一个共享的加密密钥。这通常是在一个安全的环境中产生的。
  2. 线下共享：这个密钥不能通过不安全的渠道传输，因此通常通过物理方式或事先商定的安全信道传递。双方在建立通信前必须获取该密钥。
  3. 使用密钥加密通信：一旦双方获得密钥，通信过程便使用该密钥进行加密和解密。通常是使用对称加密算法（如AES或DES），因为这些算法对加密和解密使用的是同一个密钥。
  4. 更新或更换密钥：如果密钥有泄露的风险，双方需要通过安全的方式再次共享新的密钥。

3.4 使用密钥分配中心（Key Distribution Center, KDC）

密钥分配中心（KDC）是一种集中化的密钥共享方式，适用于大规模网络环境，尤其是对称加密的环境中。KDC 是一个专用的服务器，负责管理和分发加密密钥。在这种架构中，参与通信的各方不需要直接相互共享密钥，而是通过一个可信的第三方KDC来管理密钥的分发和验证。这种方式可以有效减少直接共享密钥的复杂性和安全风险。

  1. 注册：首先，每个通信方需要在KDC注册，KDC为每个实体分配一个唯一的密钥（通常是与KDC共享的会话密钥）。
  2. 请求通信密钥：当两个实体（比如A和B）想要通信时，A会向KDC请求与B通信所需的会话密钥。
  3. 密钥分发：KDC生成一个新的会话密钥，并通过加密的方式分别传递给A和B。例如，KDC会用A的密钥加密会话密钥并发送给A，用B的密钥加密会话密钥并发送给B。
  4. 安全通信：在获得会话密钥后，A和B可以使用该密钥进行加密通信。
  5. 密钥刷新：KDC可以在需要时生成新的密钥，并通知通信双方。

优点

  • 安全集中管理：所有密钥的管理和分配由一个可信的中心控制，简化了密钥管理过程，减少了潜在的泄露风险。
  • 扩展性好：在大规模网络中，无需每对通信方直接共享密钥，可以由KDC动态生成和分发密钥。
  • 灵活性高：可以灵活地控制密钥的生效时间和使用权限，提高安全性。

缺点

  • 单点故障问题：KDC 作为系统中的核心，如果KDC出现故障，整个系统将无法正常工作，甚至可能导致所有通信被中断。
  • 需要高度信任的第三方：通信双方必须完全信任KDC，任何KDC的漏洞或恶意行为都会破坏系统的安全性。
  • 性能瓶颈：KDC 需要处理大量的密钥分发请求，可能会成为系统的性能瓶颈。

4. 网络传输安全层 -SSL/TLS

由以上分步骤一一解决HTTP 明文传输中存在的问题可以看出，解决过程是复杂且繁琐的， 但是沿用网络分层的概念，在传输层和应用层之间抽象出一个安全层，可以隐藏这个复杂且繁琐的过程， 这个安全层就是我们熟悉的SSL/TLS。

SSL/TLS 是用于保护通信安全的协议，旨在提供机密性（通过加密）、完整性（防止数据篡改）、身份认证（确认通信双方的身份）和不可否认性（防止消息发送者否认发送过消息）。这些目标依赖于多种密码学工具的有机组合。

加密传输的HTTPs =HTTP + SSL/TLS

4.1 SSL/TLS 发展历史

构建传输安全层这个想法，几乎可以说是和万维网的历史一样长，早在 1994 年，就已经有公司开始着手去实践了：

  1. 1994 年，网景（Netscape）公司开发了 SSL 协议（Secure Sockets Layer）的 1.0 版，这是构建传输安全层的起源，但是 SSL 1.0 从未正式对外发布过。
  2. 1995 年，Netscape 把 SSL 升级到 2.0 版，正式对外发布，但是刚刚发布不久，就被发现有严重漏洞，所以并未大规模使用。
  3. 1996 年，修补好漏洞的 SSL 3.0 对外发布，这个版本得到了广泛的应用，很快成为 Web 网络安全层的事实标准。
  4. 1999 年，互联网标准化组织接替网景公司，将 SSL 改名为 TLS（Transport Layer Security），随即就形成了传输安全层的国际标准。第一个正式的版本是RFC 2246定义的 TLS 1.0，该版 TLS 的生命周期极长，直到 2020 年 3 月，主流浏览器（Chrome、Firefox、IE、Safari）才刚刚宣布同时停止 TLS 1.0/1.1 的支持。而讽刺的是，由于停止后许多政府网站被无法被浏览，此时又正值新冠病毒的爆发期，Firefox 紧急发布公告宣布撤回该改动，因此目前 TLS 1.0 的生命还在顽强延续。
  5. 2006 年，TLS 的第一个升级版 1.1 发布（RFC 4346），但它除了增加对 CBC 攻击的保护外，几乎没有任何改变，沦为了被遗忘的孩子，当时也很少有人会使用 TLS 1.1，甚至 TLS 1.1 根本都没有被提出过有啥已知的协议漏洞。
  6. 2008 年，TLS 1.1 发布 2 年之后，TLS 1.2 标准发布（RFC 5246），迄今超过 90% 的互联网 HTTPS 流量都是由 TLS 1.2 所支持的，现在我们仍在使用的浏览器几乎都完美支持了该协议。
  7. 2018 年，最新的 TLS 1.3（RFC 8446）发布，比起前面版本相对温和的升级，TLS 1.3 做出了一些激烈的改动，修改了从 1.0 起一直没有大变化的两轮四次（2-RTT）握手，首次连接仅需一轮（1-RTT）握手即可完成；在有连接复用支持的时候，甚至可以把 TLS 1.2 原本的 1-RTT 下降到 0-RTT，显著提升了访问速度。

SL/TLS 工作在传输层和应用层之间的安全层。它能够为 HTTP（即 HTTPS）、SMTP、FTP 等应用层协议提供加密和身份验证功能。通过 SSL/TLS，应用层的通信变得安全透明，开发者无需在应用层实现复杂的安全机制，只需使用 SSL/TLS 来保护通信。

4.2 SSL/TLS 工作流程

SSL/TLS 协议通过将密码学工具箱中的六个关键工具（对称加密、非对称加密、消息认证码、数字签名、散列函数、密钥交换协议）有机结合，提供了高效的加密通信解决方案。这些工具的具体实现可以根据实际情况灵活替换，如选择不同的加密套件。SSL/TLS 保障了传输的机密性、完整性和身份认证，为上层应用层协议（如 HTTP、SMTP 等）提供了安全通信的基础。

现在广泛使用的是TLS 1.2，下面将以其为基础介绍一些袭击嗯

4.3 TLS协议分层结构

TLS 协议 由 TLS 记录协议和TLS 握手协议组成，可以将其理解为握手阶段和通信阶段。

TLS 握手协议中的握手协议负责双方的身份认证（即基于公钥的CA）、协商通信双方间的密码算法、密钥。

记录协议负责数据根据协商出密钥进行加密、数据认证

4.4 握手协议

根据《图解密码技术》一书提供的流程，将进行握手阶段的概括描述：

  1. 客户端问候（Client Hello）：
    • 客户端发送支持的 SSL/TLS 版本、加密套件列表（包括对称加密算法、散列算法、密钥交换方法等）和随机数 ClientRandom。
  2. 服务器问候（Server Hello）：
    • 服务器选择一个客户端支持的加密套件，并生成自己的随机数 ServerRandom，然后将这些信息返回客户端。
    • 服务器发送数字证书（包含服务器的公钥），用于证明其身份。

  3. 客户端密钥交换：

    • 客户端生成一个预主密钥（Pre-Master Secret），然后根据使用的密钥交换算法， 使用 RSA 时：客户端会用服务器的公钥加密预主密钥，并发送给服务器。

  4. 生成主密钥：

    • 客户端和服务器使用预主密钥，以及之前生成的 ClientRandom 和 ServerRandom，通过伪随机函数（PRF）生成主密钥（Master Secret）。
  5. 握手完成：
    • 客户端和服务器确认握手成功，握手阶段结束。此时，双方已经协商出了用于后续加密通信的对称密钥。

握手阶段的作用：

  • 身份认证：通过服务器的数字证书，客户端确认服务器的身份。如果需要双向认证，客户端也可能提供自己的证书。
  • 密钥协商：根据主密钥可以生成对称加密需要的密钥、消息认证码需要的密钥。

4.5 记录协议-通信阶段

握手阶段完成后，SSL/TLS 进入通信阶段，双方开始通过协商好的对称密钥进行安全通信。此时，所有的消息都会使用对称密钥加密，并通过消息认证码（MAC）来保证数据的完整性和防篡改。

  1. 加密数据传输：
    • 客户端和服务器使用协商生成的对称密钥（例如 AES、ChaCha20）对传输的数据进行加密，确保通信内容的机密性。
  2. 消息完整性验证：
    • 每条加密的数据都会附带一个 MAC（消息认证码），接收方使用相同的对称密钥计算 MAC 来验证数据的完整性，确保数据未被篡改。
  3. 数据传输和解密：
    • 双方在通信过程中反复使用对称加密进行数据的加密和解密操作。加密的数据经过传输后，接收方使用对称密钥解密消息并验证其完整性。

SSL/TLS 并不会对每条发送的消息进行数字签名。数字签名仅在 握手阶段 用于身份认证和密钥协商，而 数据传输阶段 主要依赖 对称加密和 MAC 来确保数据的机密性和完整性。这样设计是为了在保证安全性的前提下，最大程度提升传输效率。

4.6 TLS 中的密钥交换

在HTTP 明文传输的问题 一节中，我的表达是使用非对称加密算法直接加密传输共享密钥，但其实在TLS的实际工作中并不直接传输密钥， 从对握手协议的描述中可以看出，

  1. 在TLS1.2 中， 使用RSA加密传输的是预主密码。然后客户端和服务器基于这个共享的预主密钥，再结合双方各自生成的随机数，使用规定的算法生成主密码，最后基于主密码生成对称加密需要的密钥、消息认证码需要的密钥。
  2. 如果使用Diffie-Hellman 密钥交换算法, 则不需要使用非对称密钥加密传递信息，双方通过数学公式和公开值计算出相同的共享密钥，从而避免直接传输密钥相关信息并提供更强的安全性。
  3. 在TLS1.3中，相比 TLS 1.2，TLS 1.3 默认采用 ECDHE（椭圆曲线 Diffie-Hellman 临时密钥交换），这一算法相比传统的 RSA 密钥交换或静态的 Diffie-Hellman 提供了更高的安全性和效率。ECDHE 通过使用临时密钥对，确保即使未来服务器的私钥被泄露，过去的通信内容仍然是安全的。前向安全性通过每次通信协商临时的 Diffie-Hellman 公私钥对来实现，即使私钥泄露，之前的通信记录也无法被解密。（这是前向安全性）
许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。