Levon's Blog

微信: L6241425

0%

https协议原理和认证过程

发表于 更新于 分类于 ， 阅读次数： Valine：
本文字数： 4.4k 阅读时长 ≈ 4 分钟

1. https 协议

HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。

1.1 SSL历史和版本

1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。

1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。

1996年，SSL 3.0版问世，得到大规模应用。

1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。

目前，应用最广泛的是TLS 1.0。但是，主流浏览器都已经实现了TLS 1.2的支持。

TLS 1.0通常被标示为SSL 3.1, TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

2. 数字证书

数字证书，又称互联网上的”身份证”，用于唯一标识一个组织或一个服务器的，HTTPS 使用携带公钥信息的数字证书来保证公钥的安全性和完整性。

2.1 数字证书内容

一个数字证书通常包含了：

  • 服务器公钥；
  • 持有者信息；
  • 证书认证机构（CA）的信息；
  • CA 对这份文件的数字签名及使用的算法；
  • 证书有效期；
  • 还有一些其他额外信息；

那数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。

2.2 数字证书签发【CA用私钥加密，网站信息hash，签名】

1

  1. 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包(蓝色)，然后对这些信息进行 Hash 计算，得到一个 Hash 值；

  2. 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；

  3. 最后形成数字证书；（公钥等信息+签名）

2.3 数字证书验证流程

  1. 首先客户端会使用同样的 Hash 算法计算该证书的 Hash 值 H1；

  2. 通常浏览器中集成了 CA 的公钥信息，浏览器收到服务器的证书后可以使用 CA 的公钥解密 Certificate Signature（签名） 内容，得到一个 Hash 值 H2 ；

  3. 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为服务器证书不可信。

2.4 证书链

但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：

1

  1. 客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。
  2. 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书。如果发现验证通过，就认为该中间证书是可信的。
  3. “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。
1 1

操作系统里一般都会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：

1

最后一个问题，为什么需要证书链这么麻烦的流程？Root CA 为什么不直接颁发证书，而是要搞那么多中间层级呢？

这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

3. tls 认证过程（四次握手）

简单模型理解

img

认证过程

img

用 Wireshark 工具抓了用 RSA 密钥交换的 TLS 握手过程，你可以从下面看到，一共经历来四次握手

1

3.1 客户端 Client Hello

1

（1）客户端支持的 TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

3.2 服务端 Server Hello 并返回证书

1

（1）确认 TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

1

3.3 客户端验证证书，确认好对称密钥

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

3.4 服务端最后确认

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个 TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

4. tls 1.3

4.1 ECDHE 密钥

RSA 密钥协商算法的最大问题是不支持前向保密。一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

为了保证「前向安全」，就让双方的私钥在每次密钥交换通信时，都是随机生成的、临时的，这个方式也就是 DHE 算法，E 全称是 ephemeral（临时性的）。为了提升 DHE 算法的性能，所以就出现了现在广泛用于密钥交换算法 —— ECDHE 算法。

ECDHE 密钥交换算法支持「False Start」，它是“抢跑”的意思，客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性。

4.2 一次 RTT

SSL/TLS 1.2 需要 4 握手，需要 2 个 RTT 的时延，SSL/TLS 1.3 优化了过程，只需要 1 个 RTT 往返时延。

图片
  1. 在 TLS 1.2 的握手中，一般是需要 4 次握手，先要通过 Client Hello （第 1 次握手）和 Server Hello（第 2 次握手） 消息协商出后续使用的加密算法，再互相交换公钥（第 3 和 第 4 次握手），然后计算出最终的会话密钥。
  2. TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，客户端在 Client Hello 消息里带上了支持的椭圆曲线，以及这些椭圆曲线对应的公钥。服务端收到后，选定一个椭圆曲线等参数，然后返回消息时，带上服务端这边的公钥。经过这 1 个 RTT，双方手上已经有生成会话密钥的材料了，于是客户端计算出会话密钥，就可以进行应用数据的加密传输了。
  3. 而且，TLS1.3 对密码套件进行“减肥”了， 对于密钥交换算法，废除了不支持前向安全性的 RSA 和 DH 算法，只支持 ECDHE 算法。

5. 中间人攻击

5.1 原理

img

从客户端的角度看，其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于，中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。

但是要发生这种场景是有前提的，前提是用户点击接受了中间人服务器的证书。这其实并不能说 HTTPS 不够安全，毕竟浏览器都已经提示证书有问题了，如果用户坚决要访问，那不能怪 HTTPS 。

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。

5.2 防止抓包

  1. 客户端内置服务端的公钥证书，强制客户端验证与其通信的是否为服务端，这样 Charles 就没有办法做中间人了。具体有两种做法，一种是证书锁定(Certificate Pinning)，还有一种是公钥锁定(Public Key Pinning)。

  • 证书锁定(Certificate Pinning)。这种方式有一个缺点是，公钥证书是会到期的，服务端需要差不多每年都更新自己的证书，客户端也需要记得更新证书这个事儿，因为公钥证书过期之后客户端就没有办法发起请求了。

  • 公钥锁定(Public Key Pinning)。我们其实思考一下，证书的内容其实就是公钥，机构信息和签名。我们验证证书链的时候用到的就是公钥，本质上并不需要别的东西，所以我们只需要将公钥内置到我们的应用里，这样校验证书的时候我们用公钥去解密数据，然后和证书内置签名数据比较，结果一致我们就认为证书是有效的。

  1. 可以通过 HTTPS 双向认证来避免这种问题。一般我们的 HTTPS 是单向认证，客户端只会验证了服务端的身份，但是服务端并不会验证客户端的身份。

6. 参考资料

可以加首页作者微信，咨询相关问题！