Skip to content

HTTPS 与 HTTP3

HTTPS

定义

  • HTTPS is an extension of HTTP 协议，S stands for TLS (Transport Layers Security)。

步骤

x

  • 1）TCP 握手

    • 三次握手，建立连接

  • 2）证书检查（非对称）

    • 客户端 -Hello-> 服务端

      • 客户端告诉服务端：
      • 1、浏览器支持哪个TLS 版本：TLS 1.2，TLS 1.3。
      • 2、支持哪些 cipher suites：加密套件（即加密算法的集合）

    • 服务端 -Hello 开始-> 客户端

      • 服务端选择 TLS 版本和 cipher suites，告诉客户端

    • 服务端 -Certificate-> 客户端

      • 服务端生成一对 公/私密钥(A/A‘)，发送 Certificate(证书，包含公钥 A) 给客户端

    • 服务端 -Hello Done-> 客户端

      • 双方意见达成一致

  • 3）钥匙交换（非对称）

    • 客户端随机生成 密钥 X（也叫 session key），并用公钥 A 加密，生成 X' = encrypt(X, A)
    • 服务端拿到 X‘，并用私钥 A‘ 解密 X = decrypt(X‘, A')

  • 4）数据传输（对称）

    • 后续数据传输中，使用 X 加解密

非对称加密+对称加密

  • 某网站拥有用于非对称加密的 公钥 A、私钥A’。
  • 浏览器向网站服务器请求，服务器把 公钥A 明文给传输浏览器。
  • 浏览器随机生成一个用于 对称加密的密钥 X，用公钥A加密后传给服务器。
  • 服务器拿到后用 私钥A’ 解密得到 密钥X。
  • 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过 密钥X 加密解密即可。
  • 结论：HTTPS 这方案完美吗？还是有漏洞的。

中间人攻击

x

  • 中间人劫持到了数据，却完全不需要拿到私钥A’就能干坏事：
  • 某网站有用于非对称加密的公钥A、私钥A’。
  • 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  • 中间人 劫持到公钥A，保存下来，把数据包中的公钥A 替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
  • 浏览器生成一个用于 对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
  • 中间人 劫持后用私钥B’解密 得到 密钥X，再 用公钥A 加密 后传给服务器。
  • 服务器拿到后用私钥A’解密得到密钥X。
  • 结论：在双方都不会发现异常的情况下，中间人通过一套「狸猫换太子」的操作，掉包了服务器传来的公钥，进而得到了密钥X。

数字证书

  • 定义

    • 网站在使用 HTTPS 前，向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。
    • 服务器把证书传输给浏览器，浏览器从证书里获取公钥 就行了，证书就如身份证，证明「该公钥对应该网站」。

  • 数字签名

    • 数字签名的制作过程：

      • CA机构拥有非对称加密的私钥/公钥。
      • CA机构对证书 明文数据T 进行 hash， 得到 T'。
      • 对hash后的值 T‘ 用私钥加密，得到 数字签名S。

    • 浏览器验证过程：

      • 拿到证书，得到明文 T，签名S。
      • 用CA 机构的 公钥对 S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。
      • 用证书里指明的 hash 算法对明文 T进行 hash，得到 T’。
      • 显然通过以上步骤，T’ 应当等于 S‘，则表明证书可信，除非明文或签名被篡改。

CA机构的公钥是可信的？

  • 本质上是，CA 机构替代中间人，并提供权威证明。
  • 其实所有证明的源头都是一条或多条不证自明的「公理」，由它推导出一切。
  • 比如，小明的身份证是由政府作证的，这里的「公理」就是：「政府机构可信」。
  • 能不能类似地有个机构充当互联网世界的「公理」呢？让它作为一切证明的源头？它就是CA机构。

HTTP1 to HTTP3

主要线索

x

  • HTTP/1 → HTTP/1.1 → HTTP/2 → HTTP/3

HTTP/1

x

  • 1996 年
  • HTTP over TCP
  • 每个到同一服务器的请求，需要独立建立 TCP 连接（三次握手）

HTTP/1.1

x

  • 1997 年
  • 引入 「Keep-Alive」机制（持久化连接），TCP 连接可以被多个请求复用。
  • 同样，引入 「HTTP Pipeline」 机制，多个请求的要求响应 必须按顺序被接收；容易引发「队头阻塞(Head-of-line blocking )」问题，后来被废除。

HTTP/2

x

  • 2015 年发布
  • 引入「HTTP Streams」，一次 TCP 连接，多路请求流。
  • 每一路请求流「Stream」相互独立，不必按顺序发送/接收；解决「队头阻塞」问题。
  • 同样，引入「Push Cache」能力，允许服务端当数据 available 时，主动更新到客户端；不用等到客户端去 Pull。

HTTP/3

x

  • 2020 年起草，2022 发布。
  • 传输层使用新的 QUIC 协议取代 TCP 协议，其中 QUIC 基于 UDP。
  • QUIC 中「流(Streams)」作为「一等公民」；「Streams」共享同一个 UDP 连接，每一路流独自投递。
  • 同样，在目前移动互联时代，移动设备频繁在4G、5G、Wifi 中切换，TCP 协议切换迟缓，而 QUIC 协议无缝切换。

x