跳到主要内容

3 篇博文 含有标签「计算机网络」

查看所有标签

· 阅读需 9 分钟

Why HTTPS 为什么会产生​

HTTPS 产生的原因在于 HTTP 本身的不安全性

HTTP 的不安全主要体现在三个方面

  1. 通信使用不加密的明文，通信的内容容易被窃听
  2. 无法验证通信双方的身份，有可能遭遇伪装
  3. 无法验证报文内容的完整性，有可能获取到的内容已被篡改

因为上述三个原因，使用 HTTP 的互联网是完全不可靠不安全的，直至 HTTPS 的诞生

学习 HTTPS 前置知识​

对称加密​

加密解密都使用同一个密钥，该密钥我们称为共享密钥

非对称加密​

加密和解密使用不同的密钥，取其中一个作为公钥可传播到公开场合，另一个作为私钥自己保管，两个密钥地位完全等同，其神奇之处在于经过一个密钥加密的内容，只有使用另一个密钥才能解密 非对称加密有两种场景

  1. 公钥加密，私钥解密：只有私钥的拥有者才能获取到真正的内容
  2. 私钥加密，公钥解密：内容接收者用于验证内容发送者的身份

非对称加密对比对称加密，安全性更高，但是同时带来的副作用是资源消耗变大，因为公钥和私钥的产生需要大量的计算，加解密也需要大量的计算

RSA​

常见的非对称加密算法之一

ECDHE​

常见的非对称加密算法之一

HTTPS 内容​

为了规避 HTTP 的不安全性，HTTPS 在 HTTP 协议之下，增设了一层 SSL/TLS 协议，在该层中，进行了数据的加密 20200517155416

HTTPS 的数据传输使用了对称加密的方式，客户端和服务端都使用客户端生成的同一个密钥，但是问题关键是客户端如何把密钥安全的送到服务端手中。这里，HTTPS 使用了非对称加密，将共享密钥作为内容发送过去，因此 HTTPS 总体上使用了对称加密和非对称加密混合的加密机制。 那么，为什么不在数据传输的过程中也使用非对称加密的方式呢？答案是考虑到非对称加密需要大量的计算，占用资源多，且连接繁琐，耗时长，因此采用对称加密的方式。

在使用非对称加密的过程中，必然涉及到公钥的发送与接收，那么 HTTPS 又如何保证公钥的真实性呢？ 这里，HTTPS 引入了由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书

与证书相关的流程见下图： 20200517161711 这里使用了前置知识中的私钥加密，公钥解密,内容接收者用于验证内容发送者的身份的知识，CA 使用自己的私钥对服务器的公钥进行了加密得到证书，之后客户端使用 CA 的公钥对证书解密，从而验证 CA 的真实性和服务器公钥的真实性

下图是 HTTPS 的通信步骤 20200517163743

  1. 客户端发送 ClientHello 报文开始 SSL 通信，包含一个随机数 client_random，SSL 版本，加密组件列表等信息
  2. 服务器发送 ServerHello 作为回应，包含一个随机数 server_random，SSL 版本，加密组件等信息
  3. 服务器发送 Certificate 报文，包含公钥证书
  4. 服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束
  5. SSL 第一次握手结束之后，客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
  6. 接着客户端继续发送 Change Cipher Spec 报文。该报文会提 示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
  7. 客户端发送 Finished 报文。该报文包含连接至今全部报文的 整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确 解密该报文作为判定标准。
  8. 服务器同样发送 Change Cipher Spec 报文
  9. 服务器同样发送 Finished 报文
  10. 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接 就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用 层协议的通信，即发送 HTTP 请求
  11. 应用层协议通信，即发送 HTTP 响应。
  12. 最后由客户端断开连接。断开连接时，发送 close_notify 报文。

大家可能看了上面的这些步骤一脸懵 其实总的来说，步骤 1-4 这一个 TTL 中，主要目的是服务器把配对的公钥发送给客户端； 步骤 5-9 这一个 TTL 中，目的是客户端使用刚刚获得的公钥，把之后对称加密用的密钥进行加密，发送给服务端； 之后就是双方使用对称加密进行数据通信，直至连接断开

以上是 TSL 的传统握手，当然随着时代发展，TSL 也进行了升级，现在主流的版本是 TLS/1.2, 之前的 TLS1.0、TLS1.1 都被认为是不安全的，在不久的将来会被完全淘汰。

安全性上，传统的 TSL 通信使用 RSA 算法作为非对称加密算法， TSL1.2 中使用了 ECDHE参考 1 参考 2作为加密算法，性能较 RSA 更好，使用 RSA 算法时服务器的私钥是固定的，一旦中间人拿到了服务器私钥，并且截获之前所有报文的时候，那么就能拿到 pre_random、server_random 和 client_random 并根据对应的随机数函数生成 secret，也就是拿到了 TLS 最终的会话密钥，每一个历史报文都能通过这样的方式进行破解。 但 ECDHE 在每次握手时都会生成临时的密钥对，即使私钥被破解，之前的历史消息并不会收到影响。这种一次破解并不影响历史信息的性质也叫前向安全性。 RSA 算法不具备前向安全性，而 ECDHE 具备，因此在 TLS1.3 中彻底取代了 RSA。

性能上，TSL1.3 通过 Session-ticket 进行会话复用减少重新生成密钥的时间，以及使用 PSK（Pre-Shared Key，在发送 Session-ticket 同时带上应用数据）做到了 0-RTT 连接