SQL SERVER 的SSL证书 sql ssl安全错误_SSL


说明：此篇作为ARTS学习打卡专用（何为ARTS，详见这里），每周输出一篇原创能力有限，但是自己不想说放弃这个 flag，所以以下内容可能存在（但不限于）如下问题：1. 篇幅短小。2. 解释不够详尽。3. 内容不够严谨。4. 措辞未经修饰。

背景

之前一直对 https 的握手过程一知半解，这次再次拿出来学习记录下笔记。SSL/TLS + http = https，SSL/TLS 就是建立在 http 协议上的一层安全协议。TLS 是 SSL 的升级版，看下各个版本的历史：

  1. SSL 1.0 - 未公开发布。
  2. SSL 2.0 - 1995年发布。
  3. SSL 3.0 - 1996年发布。
  4. TLS 1.0 - 1999年发布。
  5. TLS 1.1 - 2006年发布。
  6. TLS 1.2 - 2008年发布。

概述

大致的流程

握手的双方是 client 端和 server 端，client 我们比较常见的就是浏览器，server 我们比较常见的是服务器端。 宏观的流程如下：

  1. client 向 server 发起 “hello” 明文请求，请求包括自己支持的安全协议的版本，能够使用的加密套件的列表，等相关信息。
  2. server 向 client 回应 “hello” 请求，回应包括服务器选择此次握手使用的协议版本，哪种加密套件，自己的证书。
  3. client 收到 server 的证书验证真伪，并且从中获取到公钥。用公钥把 pre_master_key 加密发送给 server。
  4. client 使用 pre_master_key 生成 shared_secret_key，用 shared_secret_key 根据协议加密一段内容x发给 server。
  5. server 收到加密后的 pre_master_key，先用私钥解密，然后生成 shared_secret_key。用这个 shared_secret_key 解密 client 发来的内容 x 看是否符合协议。
  6. server 再用 shared_secret_key 同样根据协议加密一段内容x发给 client。
  7. client 使用 shared_secret_key 解密 x 看看是否符合协议。如果符合则完成握手。
  8. 正常通信内容都通过 shared_secret_key 加密进行传输。

合并请求

上述几个步骤其实里面有几个是可以合并内容到一次请求发送的：

Request1:

Response1:

PreRequest2: 验证 server 的证书，并抽取公钥。

Request2:

Response2:

client 解密 x 验证握手完成。

如何生成 shared_secret_key

  1. client 向 server 发起 “hello” 明文请求同时，附带上随机串 random_C。
  2. server 向 client 回应 “hello” 请求，附带上随机串 random_S。
  3. …… client 用公钥把 pre_master_key 加密发送给 server。此时 client 端已经拥有 random_C、random_S、pre_master_key，所以使用协商加密信息计算 shared_secret_key = Fuc(random_C, random_S, Pre-Master)。
  4. server 收到加密后的 pre_master_key也就拥有了 random_C、random_S、pre_master_key。同样可以生成 shared_secret_key。