TLS/SSL 高级进阶

TLS/SLL 是现在网络安全通信比较重要的一环，通过一些列的 key 交换和 key 生成，最终确立加密通道的整个流程。众所周知，TLS/SSL 耗费的时间也是挺可观的，相对于 TCP 的3次 RTT 来说，如果加上 TLS/SSL, 则总的 RTT 时间至少为 4 次。虽然看起来很多，但如果相对于现在的网络环境来说，大概也就每次 20~30ms，这样算下来，估计也就 100ms 左右。这样的时间差还是可以忍受的，不过，这里还没算入 DNS 解析，这个暂时不考虑。而且，TLS/SSL 生成的 sessionkey 如果在有效期内的话，那么这个时间就可以完全忽略掉了。不多说了，我们直接来看下 TLS/SSL 的基本内容。

TLS 算法

TLS/SSL 其实就是通过非对称加密，生成对称加密的 sessionkey 的过程。对称加密的算法无外乎就 AES，或者使用 Cipher/Decipher 模块。而非对称加密常用的就是 RSA，不过也有使用 Diffie-Hellman (迪菲)。但，较安全性来说，DH 要高一些。因为，RSA 在生成 sessionkey 时，最后是由 browser 生成，然后通过 public key 加密后传给 server 的，这样存在一定的问题是，如果 hacker 得到了 private key，那么，他可以全程监控流量，然后使用 private key 进行解密，那么可想而知，sessionkey 也就暴露了。

但对于 DH 来说，它机制的不同点在于，sessionkey 不会通过网络传输，而是在两端独立生成的。ok~ 这就涉及到两个 key 的一致性问题。DH 还有一个机制，即，前向安全性(perfect forward secrecy--PFS)：server 端的 private key，不能用来代替以前任何一把的 sessionkey，所以，也无法破解以前任何一次的 session 内容。每次连接，DH 都会重新生成一个 key，并且当该次 session 结束时，丢弃它。不过，这并不是很大的问题，因为 DH 能很快的生成 key。因为它耗费在网络上的时间相比于 RSA 来说少了一半。可以从下图简单了解 DH 的加密算法：

简单来说，两边通过一次的信息交换，完成了密钥生成。因为 sessionkey 是独立放在两端的，为了达到一致性，每次连接时，DH 都需要重新协商生成 sessionkey。现在有个问题是： 为什么一定要有 session key，他存在的意义是什么？

sessionkey 用途

TLS/SSL 其实就是通过非对称加密，生成对称加密的 session key 的过程

那 session key 主要又干了什么呢？

首先，我们要先明确，session key 是用来进行对称加密的，这种加密方式主要使用到的是 AES 加密算法。这不同于 Elliptic Curve Diffie-Hellman (ECDH) 这种非对称加密算法。两者其实都可以用来对信息进行加密，但由于算法内部的实现机理不同，他们所用的时间也是不一样的。基本上是，ECDH 所用的时间是 AES 的 3 倍。

你可以自行测试一下：

openssl speed ecdh
openssl speed aes

ok,上面大概简述了 TLS/SSL 所用到的算法。接下来，我们来了解一下，具体 TLS/SSL 密钥交换的过程。

TLS/SLL 过程

在详述过程之前，我们需要了解一下，在过程中会出现的内容。

• session key: 这是 TLS/SSL 最后协商的结果，用来进行对称加密。

• client random: 是一个 32B 的序列值，每次连接来时，都会动态生成，即，每次连接生成的值都不会一样。因为，他包含了 4B 的时间戳和 28B 的随机数。

• server random: 和 client random 一样，只是是由 server 端生成。

• premaster secret: 这是 48B 的 blob 数据。它能和 client & server random 通过 pseudorandom (PRF) 一起生成 session key。

• cipher suite: 用来定义 TLS 连接用到的算法。通常有 4 部分：

  • 非对称加密 (ECDH 或 RSA)

  • 证书验证 (证书的类型)

  • 保密性 (对称加密算法)

  • 数据完整性 (产生 hash 的函数)

    比如 AES128-SHA 代表着：

    • RSA 算法进行非对称加密

    • RSA 进行证书验证

    • 128bit AES 对称加密

    • 160bit SHA 数据加密算法

  • 比如 ECDHE-ECDSA-AES256-GCM-SHA384 代表着

    • ECDHE 算法进行非对称加密

    • ECDSA 进行证书验证

    • 265bit AES 对称加密

    • 384bit SHA 数据加密算法

相信大家对这张图已经很熟悉了：

不过，上面不是说了有两种不同的非对称加密方式吗？ RSA & DH？ 那为什么图只是一个嘞？

ok，实际上这图没错，他并没有把传输的内容是什么写出来，这很关键。而两种算法也是在传输内容上区分开的，基本的过程是完全一样的。根据 wiki 的解释，我们大概能知道整个传输过程需要的内容。

1. 客户端发送 clientHello 信息，包含了客户端支持的最高 TLS 协议版本，random num (上文提到过)，cipher suite。如果，客户端使用 resumed handshake，那么这里发送的就是 sessionID。如果，客户端还支持 ALPN，那么它应该还需要发送它所支持的其他协议，比如 HTTP/2.

2. 在 server 端进行 serverhello 阶段，这里 server 根据 client 发送过来的相关信息，采取不同的策略，同样会发送和 client 端匹配的 TLS 最高版本信息，cipher suite 和 自己产生的 random num. 并且，这里会产生该次连接独一无二的 sessionID 。

3. 通过 certificate 阶段，会在信息流中加入 public key certification。ServerKeyExchange 该阶段，主要是针对于 ECDH 加密方式，这里就不赘述，后面再进行讲解。

4. serverHelloDone 标识这 server 阶段处理结束，将该阶段产生的信息发送给 client。

5. 在 clientKeyExchange 阶段时，client 会随机生成一串 pre-master secret 序列，并且会经由 public key 加密,然后发送给 server。在 ChangeCipherSpec 阶段，主要是 client 自己，通过 pre-master secret + server random-num + client random-num 生成 sessionKey。这就标识着，此时在 client 端，TLS/SSL 过程已经接近尾声。

6. 后面在 server 端进行的 ChangeCipherSpec 和 client 进行的差不多，通过使用 private key 解密 client 传过来的 pre-master secret ,然后生成 sessionkey。 后面再通过一次验证，使用 session Key 加密 server finshed ，发送给 client，观察能够成功解密，来表示最终的 TLS/SSL 完成。

上面主要是根据 RSA 加密方式来讲解的。因为 RSA 才会在 TLS/SSL 过程中，将 pre-master secret 显示的进行传输，这样的结果有可能造成，hacker 拿到了 private key 那么他也可以生成一模一样的 sessionKey。即，该次连接的安全性就没了。

接下来，我们主要讲解一下另外一种加密方式 DH。它和 RSA 的主要区别就是，到底传不传 pre-master secret。RSA 传而 DH 不传。

根据 cloudflare 的讲解可以清楚的了解到两者的区别：

这是 RSA 的传输方式，基本过程如上述。

而 DH 具体区别在下图：

这里先补充一下 DH 算法的知识。因为，pre-master secret 就是根据这个生成的。DH 基本过程也不算太难，详情可以参考 wiki 。 它主要运用到的公式就是:

为了防止在 DH 参数交换时，数据过大，DH 使用的是取模数的方式，这样就能限制传输的值永远在 [1,p-1]。这里，先说明一下 DH 算法的基本条件：

• 公共条件： p 和 g 都是已知，并且公开。即，第三方也可以随便获取到。

• 私有条件： a 和 b 是两端自己生成的，第三方获取不到。

基本流程就是：

我们只要把上图的 DH parameter 替换为相对应的 X/Y 即可。而最后的 Z 就是我们想要的 Premaster secret。 之后，就和 RSA 加密算法一致，加上两边的 random-num 生成 sessionKey。通过，我们常常称 DH 也叫作 Ephemeral Diffie-Hellman handshake 。 因为，他每次一的 sessionKey 都是不同的。

而 RSA 和 DH 两者之间的具体的区别就在于：RSA 会将 premaster secret 显示的传输，这样有可能会造成私钥泄露引起的安全问题。而 DH 不会将 premaster secret 显示的传输。

TLS/SSL 中的基本概念

上面内容大概讲清楚了基本的 TLS/SSL 的加密过程。不过，其中，还有很多其他的小细节，比如 SNI，ALPN，Forward Secrey。 接下来，我们主要将这些细节将一下，因为他们其实也很重要。

Forward Secrey

FS(Forward Secrey) 主要是针对 private key 进行描述了。如果你的 private key 能够用来破解以前通信的 session 内容，比如，通过 private key 破解你的 premaster secret ，得到了 sessionKey，就可以解密传输内容了。这种情况就是 non-forward-secrey。那如何做到 FS 呢？ 很简单，上文也已经提到过了，使用 DH 加密方式即可。因为，最后生成的 sessionKey 和 private key 并没有直接关系，premaster secret 是通过g(ab) mod P 得到的。

简单的说就是，如果你想要启用 FS，那么你应该使用的是 DH 加密方式，而放弃 RSA。不过，由于历史原因（TLS 版本问题），RSA 现在还算是主流的加密方式。但，DH 也凭借他 5S 的安全性，份额也在增加。

ALPN

ALPN 全称是 Application Layer Protocol Negotiation（应用层协议协商机制）。看到应用层，程序员们应该都能反应出 OSI 7层网络协议。在应用层中，HTTP 协议应该是重点。不过，由于 HTTP 版本的问题，以及现在 HTTP2 的流行，为了让 client-server 使用相同的协议而出现了 ALPN。ALPN 实际上是从 SPDY 中的 NPN 协议衍生出来的。不过，它们俩的机制正好相反。

• NPN： 由 server 端告诉 client，它支持什么协议，然后 client 确认支持的协议后，开始进行连接。

• ALPN：在 TLS 阶段，由 client 告诉 server，它所支持的所有协议，然后开始进行连接。

总的来说，NPN 已经退出历史的舞台了。。。ALPN 现在是 IETF 指定的标准协议。ALPN 在 TLS 具体的过程是：

• 在 clientHello 阶段，client 会在 message 中，添加一个 ProtocolNameList 字段。用来表示它所支持的协议列表

• server 端在 serverHello 阶段，处理 client 提供的 ProtocolNameList。并且选择最高版本的协议，执行。将选择信息添加到 serverhello 内。

SNI

SNI 的全称为：Server Name Indication。该机制的提出的意义是，当有一个 server 同时处理了很多个 host 时。相当于，一个 IP 映射多个域名，但，由于证书只能对一个 3 级域名有效，所以，针对于多个 host 来说，server 为了能同时兼顾这些域名。一种简单的办法就是重定向到指定域名，如果都想支持的话，也行，掏钱自己多买几个证书 （真土豪）。如果，你很土豪的话，现在就有这样的情况，一个 IP 服务器下，搭载了支持多个域名的 server，并且每个域名都有合法的 CA 证书。那么，server 怎么判断，哪一个域名用哪一个证书呢？这时候，就需要用到 SNI。相当于在 TLS 阶段，将 host 一并发送过去，然后 server 就知道在 serverhello 阶段该返回啥证书了。

现在，有个问题，为什么一定要用 SNI 呢？

我们回想一下，这里我们仅仅只是建立 TCP + TLS 连接，客户端的一些内容，比如 hostname，我们并不能在 TCP 中获得。而，想要获得的话，就需要等到 HTTP 阶段，获得 client 传过来的 host 或 origin 字段。所以，为了解决这个比较尴尬的点，就提出了 SNI。

Session Resumption

感觉能看到这里的人，应该都是闲的蛋疼的人。。。如果让我来看这篇文章，估计看几张图，我基本上就直接关网站了。因为，这实在是复杂。并且，上面说的只是协议上的复杂性，对于计算机来说，只需要记下每一次该发什么东西而已，但真正让 Computer 感到蛋疼的是，key 的计算。特别是 random key 和 premaster secret 动不动就是 32B，48B 的数据量。所以，为了真正减少计算机的工作量（实际上是 server），提出了 Session ID 和 Session Tickets，来将成功进行连接的 session 内容缓存起来。

Session ID

Session ID 是 server 将上一次成功连接的 session 内容存在自己的硬盘里面。这里，就不涉及对 session data 的二次加密。基本的过程是：

1. client 端在 clientHello 阶段，将 random num，TLS protocol 和通过 hostname 匹配到的最新一次的 session ID 发送给 server 端。（也就是说，client 同样需要存储一份 session data）

2. server 接收到 session ID 后，在缓存中查找，如果找到，则直接进行 ChangeCipher 阶段，开始生成sessionKey。然后，返回相同的 sessionID 即可。

那么相对于完全的 TLS/SSL 连接来说，这里只用到了一次 RTT。那么协议过程就变为了：

Session Ticket

既然 Session ID 是为了解决网络时延和计算机性能问题，那么 Session Ticket 又干了什么呢？

Session Ticket 和 Session ID 做的也是同样的事情，server 将最新一次的 sesion data 通过二次加密，在上一次握手结束时传递过去，然后 client 将传递过来的信息保存。

这样，利不利用缓存的 session data 这时，就取决于 client。如果该次的 session data 没有过期，那么 client 就会在 clientHello 阶段将该数据发送过去，server 接受到之后，便开始进行解密然后，双方生成 sessionKey，握手结束。

那 Session Ticket 和 Session ID 到底用哪一个呢？

这估计得看你的业务情况了，Session ID 注重的是节省性能，而损耗部分空间。Session Ticket 注重的是节省空间，而损耗部分性能。它们两者都能节省一次 RTT 时间，用谁，还是得看你的服务器的具体情况。

CA 证书详情

前面大致说了 TLS/SSL 是怎样运作的，以及有哪些连接方法。相当于，学画一条线一样，我们现在只知道这条线该画多长，但还不知道，这条线从哪里画。所以，接下来，我们就需要来探讨一下，两端发生了什么。其实也不难，主要还是关于 CA 证书的存放和验证。server 端的很简单，就是把自己的 CA 证书发过来就 ok。但，client 验证这个证书是否可信，会有点复杂。

首先，证书颁发机构就那么一些，换句话理解就是，每个证书颁发机构，就代表着一张 CA 证书。但，现在市面上的 HTTPS 网站，辣么辣么多，难道他们都用同一张证书？难道他们都有一样的 pu/pr key? 那么 HTTPS 安全还有用吗？

所以，按照上面的推理，我们的网站上的 HTTPS 证书，肯定都是各不一样的。一般来说，有 3 种类型的证书： DV（Domain Validation），OV（Organization Validation），EV（Extended Validation）。均价按照顺序上升，所以，最便宜的就是 DV，这应该是我们勤劳的贫苦大众用得起的。它们之间具体的区别在于域名的支持上：

• DV：就是个人证书嘛，基本支持的就是单域名和多域名，不支持泛域名（*.villainhr.com）。不过，看价格，比如我这个就是腾讯云给的一个免费的 DV 证书，所以，就支持一个 3 级域名（ https://www.villainhr.com ）。如果是收费的，单/多域名应该都支持。

• OV：就比较牛逼，面向企业的，多域名/泛域名都支持。

• EV：属于贵族用的，一般人也搞不到，主要它还需要去买个保险。。。

那我们的证书在芸芸证书中，是处于哪一个层级呢？

一般是三级。怎么体现的呢？

那这么多证书，我们用的是哪一个呢？当然是，最下面那个。因为每个证书并不是都被信任，所以客户端首先就要了解一下，你这个证书能否用来进行验证。如果不行的话，那么你这次连接就是不被信任的，就没有 绿色的小锁 。这就需要了解一下，客户端的验证过程。

CA 链式验证

首先，什么叫做可信的证书呢？

我们先要明白一个道理，HTTPS 是先建立在人与人之间的相互信任上，然后才建立在机器与机器的相互信任上。假如，根证书 A 机构，恶意的将一个以前颁发过的证书，又给了另外一个 不要脸 拦截站点（比如，用来插广告的）。这样，我拿到了这个证书后，就可以自己搭一个服务器，用来进行拦截浏览，监管里你网站，并强行插广告。这就被称为不可信的机构/证书。

而验证的可行性，通常又跟机构的权威性有着极大的关系。它基本的验证过程简述就是（按照上面的层级）：

• www.villainhr.com 问 TrustAsia DV SSL，我的证书可不可信？

• 可信！ok，继续。TrustAsia DV SSL 问 VeriSign Class 3，我的证书可不可信

• 可信！ok，然后便开始 TLS/SSL 连接。

如果上述任一步骤出现问题，那么该次 TLS/SSL 就不会进行，会回退。那么它们在询问的时候，会不会发送网络请求呢？

不会~ 因为，电脑在初始化时，会自带很多可信任的证书机构（即，Root CA），也就是我们刚刚提到的 VeriSign Class 3 的证书机构。以及，能够签发证书的二级机构（比较少）。到时候，浏览器会自动的根据数字签名来进行证书的验证。

CA 合法验证

上面已经阐述了，CA 证书的合法性是自下而上的验证方式。那么它们具体验证协议是怎样的呢？

在说之前，我们先说几个概念：

• 数字签名：它是用颁发机构的私钥，对下级证书的公钥进行加密生成的值。digital_sign = CA_pr_key + sub_Cer_ppu_key。

• 解密：用颁发机构的公钥对数字签名进行解密，对比下级证书的公钥和解密后的值是否一致。

CA 验证首先需要说一下它的颁发过程：

• 颁发机构 A，用自己的私钥将需要生成的下级证书 B 的公钥进行加密，生成数字签名，然后再带上相关信息：公钥，公钥的指纹，数字签名，证书名，签发机构等。

然后，验证过程就是根据这个来的：

• 浏览器解析下级证书 B 的相关信息，找到签发机构和数字签名。

• 然后，找到签发机构 A，使用 A 的公钥去解密数字签名，然后对比下级证书 B 的公钥。如果成功则合法，反之，不合法。

而上面的三级证书层级，也是同样的道理，自上而下的找就 ok。当然，有时候为了验证的速度，会做一些缓存，这样就不必再进行验证了。所以，根据上面的描述，有童鞋可能会想到，能不能自签证书呢？反正，浏览器也是从本地找的。

当然可以， openssl 就可以生成你自己的 CA。不过需要注意的是，你生成的 CA 只是在你自己的电脑上使用，如果你想保证你的 CA 在其他电脑上也能使用的话（这是不可能的），那就用钱砸就 ok。

具体的过程可以参考： 生成自己的 CA 证书 。

以前，在使用 Charles 和 Fiddler 的时候，一直在想，它们是怎么做到，将自己的证书，变成签发机构证书。

后来发现，它是把证书中的相关字段该成它的证书内容。不过，对于某些高级证书，还是会有一些问题，比如，wx.qq.com（微信的）

另外，为了证书的可靠性，提出了 Certificate Transparency 项目，实际上，就是让证书机构公开它的签发流水。防止出现重复签发。

证书的吊销

现在有个问题，为什么证书有过期时间呢？

这同样是为了安全性，前面说过，如果你的证书发生了泄漏（实际上就是私钥）。那么，其他服务器就可以作为一个代理去拦截你的流量。这时候，由于过期的原因，可能一段时间后，中间恶意的服务器就没用了，另外，如果你发现了你遗失了证书，可以向颁发机构去挂失。

另外，还有一个原因是证书吊销的 CRL 机制。简单来说，就是有一个列表来记录当前时间，该颁发机构被吊销的证书 list。如果，没有过期时间的话，那么这个 list，会随时间程指数增长，引入过期机制的话，该 list 只要记录当前没过期但吊销的证书信息即可。

证书的吊销有两种机制：CRL，OCSP

CRL

CRL（Certificate Revocation List），即，证书吊销列表。CA 机构会生成一个列表，列表里面是当前周期被吊销证书的序列号，当进行证书验证时，同样也会进行验证该项。如果，已经是吊销证书的话，那么该次 TLS/SSL 连接也会失败。

我们可以从证书信息中找到 CRL URI:

该协议虽然简单，但，缺陷还是比较多的。

• 下载时间。因为该 list 不是自带的，需要从颁发机构下载，这就造成了网络时延。

• 缓存时间。如果存在缓存，就存在了信息不同步的问题，如果一个证书已经过期，但缓存中显示的是未过期，那么也是一个安全问题。

OCSP

OCSP（Online Certificate Status Protocol），即，在线证书状态协议。它通过在线请求的方式来进行验证，不需要下载整个 list，只需要将该证书的序列号发送给 CA 进行