一文理解https运行机制

一 什么是https

https的英文全程为：Hypertext Transfer Protocol Secure，相比http多了一个secure，顾名思义，就是在http的基础上新增了安全相关内容。具体来说，主要是如下两点：

1. 客户端(浏览器)对服务端(网站)的身份进行认证。
2. 客户端(浏览器)与服务端(网站)之间做加密通信。

在2016年之前，证书的颁发都是一项昂贵的操作，只有支付交易等对安全要求很高的领域才会广泛使用https，后面EFF(Electronic Frontier Foundation)组织开展了一项推广https的活动，才使得这个协议变得普遍。

现在https服务已经非常普及，互联网上每一个服务都需要使用https协议已经得到共识，如果你访问的网站提供的是http服务，chrome浏览器甚至会对你发出警告，通知该网站不安全。而当该网站是https时，在url输入框的最左端，你可以看到一把小锁:

https使用的整体流程为：

1. 客户端使用安全 HTTPS发起连接
2. 服务端向客户端发送其证书
3. 客户端验证证书合法性
4. 客户端和服务端双方协商加密算法与加密密钥
5. 双方加密会话

可以看到上面描述的https功能是通过下面的机制实现：

1. 身份识别：使用证书证明身份
2. 加密通信：使用SSL协议进行数据的加密传输(后升级为TLS协议)。 下面就对两者进行说明：

二 https证书解析

1 证书的信任链机制

https使用证书作为身份识别的凭证，那么浏览器在发起访问的时候如何判断服务器证书是有效的呢？这里面又有哪些认证机制呢？

简单来说，https证书是使用信任链这种机制来证明其证书的有效性，这种信任链的信任源头是根证书，根证书向中间CA颁发证书，中间CA向网站服务商颁发服务器证书，证书中含有可以验证证书的公钥，私钥则被隐藏起来，整个流程如下所示：

如果想了解证书的颁发流程，可以查看附录：

当浏览器认证服务端的证书时，它会先验证网站证书的有效性，并且递归的向上验证，直到验证到CA证书，这样就证明了用户访问的网站是可信的。这个验证机制如下图所示：

注：每个操作系统、第 3 方 Web 浏览器和自定义应用程序都附带 100 多个预安装的受信任根 CA 证书(私钥不会存储在这里，验证证书有效性只需要公钥)。

2 证书的层次结构

一般来说，网站的信任链就只有三层，根证书->中间证书->服务器证书。

1. 根证书是信任根，如果根证书私钥被泄露的话，整条链的所有证书都将作废，所以根证书很少直接颁发服务器证书，都是先给一个中间商颁发证书，然后再通过中间商的私钥为服务器颁发证书，这样即使中间CA的私钥泄露了，也不会影响到根证书。
2. 为了保证根证书的安全，中间证书以一个代理人的角色出现，颁发各种服务器证书。
3. 服务器证书就是我们搭建网站需要申请的。

以qq的域名为例，我们可以到其证书结构：

从上到下即为CA证书，中间证书，服务器证书。

3 服务器证书类型

• EV证书(扩展验证证书)：最昂贵的证书，最高的验证标准。
• OV证书(组织验证证书)：验证组织的身份以及组织的运营位置。
• DV证书(域验证证书)：最低级别的验证，一般可以免费获得。
• UCC证书(多域验证证书)：认证多个域名。
• 单域验证证书

一般比较正规的网站都会使用OV及以上验证证书。

4 一个证书实例

当前，基本所有的证书都遵循X.509证书格式，里面需要包含：

• 证书基本信息:
  1. 版本号
  2. 序列号
  3. 签名算法
  4. 颁发者
  5. 证书有效期：此日期前无效，此日期后无效
  6. 主题
  7. 主题公钥信息：公钥算法，主题公钥
  8. 颁发者唯一身份信息（可选项）
  9. 主题唯一身份信息（可选项）
  10. 扩展信息（可选项）
• 证书签名算法
• 数字签名

我们用chrome打开qq.com，点击上面的小锁，导出may29-2022-1.ias.qq.com证书，用证书查看工具展开详细信息(直接在chrome上面查看也可以)：

主题信息

签发者信息

证书信息

证书链

5 关于证书的一些思考

我可以自己颁发一个根证书并用它来签署其他证书吗？

• 可以的，但是由于你的证书并没有被加载到其他设备或者浏览器中，使用自颁发证书部署的服务并不可信。 连公共wifi会暴露我的https流量吗？
• 不会，https服务所有的流量都是加密的，只有在你的设备上才能解开。 公司可以监控https流量吗？
• 如果使用了公司的设备，是可以的，https的基础是根证书，公司可以将自签名的证书放到你的机器CA列表中。

三 ssl/tls加密协议

ssl/tls协议是一套安全协议，也是https加密的基础。

1 ssl/tls 历史

ssl协议在1994年出现，版本号为1.0，但是由于出生时就有安全漏洞，从未发布过。SSl的第一个版本2.0于1995年发布，一年以后SSL3.0版本问世，与此同时，作为ssl协议的加强版，tls的研发也正在路上，1999年tls v1.0问世，至于为什么叫tls1.0而不是叫ssl3.1。

这里面是有一点八卦的，可以参考：https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html?m=1，课代表总结一下就是上世纪 Netscape/Microsoft一直在争夺浏览器份额，而ssl协议是Netscape公司提出的，Microsoft为了削弱Netscape的影响力，就不想继续沿用ssl这个名字。

ssl3.0被广泛使用到2014年，2014年秋季谷歌团队发现了一个重大的安全漏洞：使用POODLE攻击可以获得明文(https://www.cisa.gov/uscert/ncas/alerts/TA14-290A);此外，tls1.0和tls1.1由于依赖MD5和SHA-1，后来也被建议弃用，如今只有chrome浏览器上只有约0.5%的https连接是建立在tls1.0和1.1上的。

2 ssl/tls连接建立流程

与大家都了解的tcp三次握手类似，ssl/tls连接建立的过程也是一个握手的过程，握手的时机为建立tcp连接后:

之后就是双方协商密钥的过程,协商密钥的算法一般采用ECDH密钥交换算法，相关的一些细节可以查看我之前的文章：密码学小白必知必会，客户端与服务端协的连接建立过程包含验证双方证书和交换密钥两部分，如图所示：

等待协商完成密钥之后，双方使用这个协商好的密钥进行通信，使用wireshark抓包可以看到整个过程：

3 思考

可能有细心的，或者有一些密码学基础的小伙伴会问，为什么客户端不能直接用服务端的公钥对数据进行加密，服务端使用客户端的公钥进行加密？

• 这样貌似也行的通，但是需要注意，现在一般使用的对称加密算法AES是非对称加密RSA性能的两百倍左右，如果全部使用非对称加密，性能损失会非常严重。

附录

1 根证书颁发流程

1. 根证书机构生成公私钥，私钥：pri_key, 公钥pub_key
2. 生成包含机构，有效期，主题，扩展信息等的表单：ca_info
3. 使用pri_key对ca_info+pub_key做SHA256WithRSA(先做SHA256签名，然后做rsa加密)生成根证书

其他证书颁发流程相似。

总结

本文讲述了https的总体流程，包括证书验证和密钥交换部分；也补充了一些https证书的内部信息与细节，如果有疑问，欢迎留言。