HTTPS 是如何进行安全传输的 ？

概述

现代密码学对信息的处理主要离不开以下的三种形式：

1. 摘要：主要用于数据校验，例如存储密码等，摘要是对信息进行单向的哈希，改变信息的原有形态，因为哈希函数的特点是易变性（即使微小的变化也会产生完全不同的哈希值），而且无法被反向推导出来，例如上文提到常见的哈希加密方式有：MD2/4/5/6、SHA0/1/256/512 算法等方式。
2. 加密：主要用于保证信息的安全传输，确保真实的信息只能被授权的人访问（拥有密钥），通常使用密钥对信息进行加密，和摘要不同的是，加密是可以解密为明文信息的。密钥的类型又分为：对称型密钥，非对称型密钥（公钥、私钥）等，常见的有 DES、AES、RC4、IDEA 等方式。
3. 签名：主要是用来保证明文信息的完整性、真实性和检查是否被篡改的一种方式（使用哈希函数），例如 jwt 令牌 中就是有一段签名，用于保证负载信息的真实性，签名并不保证信息的私密性。

总体来说，它们的分工是：

• 摘要：用于确保数据的完整性和快速比较，无法被解密。
• 加密：用于保护数据的机密性，它和摘要的区别是加密可以逆向破解，也就是解密。
• 签名：则提供了一种验证消息来源和完整性的方法。但信息是公开的。

这三者共同构成了现代密码学的基石，广泛应用于数据保护、身份验证和网络安全等领域。

密钥

对称型密钥

对称型密钥加密的基本原理是将明文数据通过一个加密算法和一个密钥转换成密文，然后接收方使用相同的密钥和解密算法将密文还原成原始的明文。由于加密和解密都使用同一个密钥，因此被称为对称加密。对称型密钥加密算法的特点是算法简单、速度快，适合于大量数据的加密。常见的对称型密钥加密算法包括：AES (Advanced Encryption Standard)、DES (Data Encryption Standard)、3DES (Triple DES)。

对称型密钥在密钥的保管和分发上面存在困难，因为密钥必须安全地分发给所有需要它的用户，并且每次通信都需要一个新的密钥，这在大规模通信中可能会变得复杂。关于对称型密钥总结如下：

• 优点：加解密速度快，适合大量数据、算法简单，资源消耗低，适合大量数据的加解密的场景。
• 缺点：密钥的保存和分发困难：无法在不可信的网络上进行分发，存在 “先有鸡，还是先有蛋” 的问题。

非对称型密钥

非对称型密钥加密，也称为公钥加密或双密钥加密，是一种使用两个不同密钥的加密方法：一个用于加密（称为公钥），另一个用于解密（称为私钥）。公钥可以公开分享，而私钥则必须保密。

非对称加密的基本原理是：

1. 密钥生成：首先生成一对密钥，包括一个公钥和一个私钥。这两个密钥是数学上相关的，但即使知道了公钥，也无法轻易推导出私钥。

2. 加密：当 A 想要向 B 发送加密信息时，A 会使用 B 的公钥来加密信息。这样，只有拥有相应私钥的 B 才能解密这条信息。

3. 解密：B 收到加密信息后，使用自己的私钥来解密，恢复原始信息。

非对称加密的关键特性是公钥可以公开，而私钥必须保密。这使得非对称加密在某些应用场景中非常有用，但非对称加密的主要缺点是计算复杂，消耗资源，速度慢等，因此它通常与对称加密结合使用：非对称加密用于安全地交换对称密钥，然后使用对称密钥进行实际的数据加密，以提高效率。使用非对称型密钥主要解决两个不信任个体在不安全通信环境下的信息传输问题，解决信息在公开网络中传输的问题，既然被截获也不会受到影响。关于非对称型密钥总结如下：

• 优点：使用密钥对解决密钥分发的问题，可以在公开网络中安全传输信息
• 缺点：速度慢，不适合对大量数据进行加密，计算资源消耗高，拥有长度的限制多长的密钥只能加密多长的明文。

因此，对称密钥和非对称密钥的区分是为了满足不同的安全需求、提高效率、简化密钥管理，并适应不同的通信场景。单独依靠某一种算法（对称加密、非对称加密）既做不了加密，也做不了签名。在实际应用中，对称加密和非对称加密往往是结合使用的。已混合加密方式来保护信道安全。

具体做法：

1. 使用非对称加密方式，协商一个密钥（少量信息）给通信的另一方
2. 双方基于共同的密钥进行对称加密传输大量的信息

混合使用对称和非对称加密方法来传输信息，这样可以同时利用两种加密方式的优势，也称为现代密码学套件。信息传输的终极解决方案 HTTPS 就是基于该方式实现的。

证书

在现实生活中，我们要和一个未曾谋面的人建立信任，通常有两种方式：

1. 基于共同的私密信息：对方打电话来说是我的小学同学，他能说出我们小学还有同学的名字，做过的一些糗事，那么我就会信任他
2. 基于权限的公证人：对方说他是警察，需要我配合办案，如果他能提供证件和警员编号，那么我们也会信任他，并且进行配合

在网络世界里面，我们不能认为两台计算机是相互认识并且存在共同的私密信息的，所以解决信任问题只有基于第二种 基于权限的公证人 的方式。

CA 认证中心

CA 认证中心是负责给计算机的服务端颁发数字证书（Certificate）的机构，类似于上面例子中给警察颁发证件的权威机构类似。当客户端访问服务端时，会检查服务端的证书是有效，确认无误后才会建立安全链接。

服务端的 PKI 证书是遵循 X.509 标准，证书包含了用于 SSL/TLS 通信的信息，具体如下：

1. 版本：指出该证书使用了哪种版本的 X.509 标准（版本 1、版本 2 或是版本 3）
2. 序列号：由 CA 分配的证书唯一的标识符。
3. 证书签名算法：说明数字证书所使用的签名算法。
4. 发行者：证书颁发机构可识别名称
5. 有效期：证书的有效期，包括开始和结束日期。
6. 主题：证书持有者的名称，通常是域名，全网唯一。
7. 使用者公钥信息：由 CA 中心颁发给证书持有人的公钥和公钥算法信息。
8. 扩展属性：一些后期用于扩展的其他属性。

安全传输协议

前面介绍的繁琐的密钥和证书等机制，最终都是为了安全传输所准备的。如何将复杂的技术无感知的应用在所有人都使用的网络通信中，成为工程师要面对的挑战之一，SSL/TLS 技术也经历的漫长时间和摸索，早在 1994 年就开始尝试。以下是 SSL/TLS 技术的简要发展历：

1. 1994年：SSL 的引入 - 安全套接字层（SSL）是由网景公司（Netscape）开发的，目的是为了提供一种安全的网络传输机制来保护网上交易的隐私和完整性。
2. 1999年：TLS 的诞生 - 传输层安全协议（TLS）1.0 被作为 SSL 的后续标准正式发布，由互联网工程任务组（IETF）进行标准化。TLS 在设计上与SSL 3.0相似，但增强了安全性并修复了 SSL 的一些缺陷。
3. 2006年：TLS 1.1发布 - 作为对 TLS 1.0 的改进，TLS 1.1 在安全机制上做了进一步的增强，如引入了显式 IV 以防止密码本重放攻击。
4. 2008年：TLS 1.2 发布 - TLS 1.2 进一步增强了协议的安全性，引入了更多的加密算法和安全特性，比如支持 SHA-256 散列函数。
5. 2018年：TLS 1.3发 布 - TLS 1.3 简化了握手过程，提高了连接的速度和安全性。它移除了一些过时的算法和特性，使得协议更加健壮和难以被攻击。

TLS 在传输之前的握手过程一共需要进行上下两轮、共计四次通信，通过混合使用非对称加密交换密钥，使用对称加密传输信息的方式保障通信安全。如图：

1. 客户端发送 ClientHello 消息：客户端以明文的方式向服务器发送一个 ClientHello 消息，该消息包括客户端支持的 TLS 版本、加密算法列表（密码套件）、会话ID（用于会话恢复）和客户端生成的随机数。
2. 服务器回应 ServerHello 消息：服务器选择一个共同的 TLS 版本和密码套件，并向客户端发送 ServerHello 消息。此消息包括服务器生成的随机数和会话ID，
3. 客户端确认 Client Handshake Finished：客户端首先会验证证书的有效性，如果没有问题，客户端会根据特定算法计算出 MasterSecret 作为后续对称加密的私钥，32 位随机数，编码改变通知，此消息使用新的加密参数发送，验证握手的完整性等。
4. 服务端确认 Server Handshake Finished：服务端向客户端回应最后的确认通知，包括：编码改变通知，服务器握手结束通知等

通过四次握手，一个 TLS 安全连接建立。客户端和服务端通过握手协商出许多信息，例如：只有双方才知道的随机密钥，传输过程采用的对称加密算法（例如 AES 128 等）、压缩算法等。TLS 安全连接的建立，最终实现了以下的效果：

• 保障所有信息都是第三方无法窃听（加密传输）
• 无法篡改（一旦篡改通信算法会立刻发现）
• 无法冒充（证书验证身份）的

这种处理方式对上层的用户，虽然在传输性能上会有下降，但在功能上完全不会感知到有 TLS 的存在。建立在这层安全传输层之上的 HTTP 协议，就被称为 “HTTP over SSL/TLS”，也即是大家所熟知的 HTTPS 了。