HTTPS握手过程

前言

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

一、常见问题/概念

1 X509证书结构中Signature与signatureAlgorithm区别

答：两个字段的值是一样的，具体参考RFC5280

https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.3

2 证书链验证顺序

答：由用户证书->…->CA根证书方向验证

3 通过证书验证身份，并传递可靠的公钥，然后用公钥协商出对称秘钥用来通信？

答： 如果直接传递对称秘钥会增加被破解的风险，特别是私钥泄露后，之前的会话都会被解密（因为私钥/公钥是固定的）。

秘钥交换算法常见的有：

RSA，证书公钥、私钥直接参与密钥交换，私钥泄漏，存在向前攻击问题。

DH、ECDH，证书公钥、私钥参与协商，对于Client，证书公钥作为随机数X1。对于Server，证书私钥作为随机数X2。

DHE、ECDHE，证书公钥、私钥不参与协商，每次握手都会计算随机数X。

很显然，这几种协商算法中，ECDHE是最安全的，即便当前会话的密钥泄漏了，也不影响之前的会话，是前向安全的。所以现在基本都是使用ECDHE算法。

4 为什么不直接使用非对称算法加密数据流？

答： 非对称秘钥效率太低，不适合数据传输；所以握手阶段协商对称密码，之后使用对称加密传输数据。

5 数字证书 (digital certificate)

在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。数字证书一般包含以下内容：

证书所有者的公钥

证书所有者的专有名称

证书颁发机构的专有名称

证书的有效起始日期

证书的过期日期

证书数据格式的版本号

序列号，这是证书颁发机构为该证书分配的唯一标识符

… …

6 数字签名 (digital signature)：

这个概念很好理解，其实跟人的手写签名类似，是为了确保数据发送者的合法身份，也可以确保数据内容未遭到篡改，保证数据完整性。与手写签名不同的是，数字签名会随着文本数据的变化而变化。具体到数字证书的应用场景，数字签名的生成和验证流程如下：

服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等)，得到摘要信息，再用私钥把摘要信息加密，就得到了数字签名

服务器把数字证书连同数字签名一起发送给客户端

客户端用公钥解密数字签名，得到摘要信息

客户端用相同的信息摘要算法重新计算证书摘要信息，然后对这两个摘要信息进行比对，如果相同，则说明证书未被篡改，否则证书验证失败

7 证书链 (certificate chain)：

证书链，也称为证书路径，是用于认证实体合法身份的证书列表，具体到 HTTPS 通信中，就是为了验证服务器的合法身份。之所以使用证书链，是为了保证根证书 (root CA certificate)的安全，中间层可以看做根证书的代理，起到了缓冲的作用。

8 Certificate Revocation Lists (CRL)

CA会定期更新发布撤销证书列表，Certificate Revocation Lists (以下简称CRL)，RFC 5280：Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile。

CRL分布在公共可用的存储库中，浏览器可以在验证证书时获取并查阅CA的最新CRL。

该方法的一个缺陷是撤销的时间粒度限于CRL发布期。只有在计划更新所有当前发布的CRL之后，才会通知浏览器撤销。各家签名CA厂商的策略不一样，有的是几小时，有的是几天，甚至几周;更新不够及时。

并且需要通过http方式下载一个crl列表再校验，效率较低，同时http方式下载也容易被劫持。

9 Online Certificate Status Protocol (OCSP)

在RFC2560X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP的描述中，浏览器从在线OCSP服务器（也称为OCSP Response Server）请求证书的撤销状态，OCSP Server予以响应。

这种方法避免CRL更新延迟问题。同样的，X.509 v3证书的OCSP信息也是存储在拓展信息中，如alipay.com证书那张图的绿色框内部分。

OCSP机制衍生出来的问题

设想一个场景，你是浏览器企业，研发的浏览器在检查证书吊销状态时，得不到OCSP server的响应，你会如何选择？

如果你选择拒绝该证书信息，并且拒绝后续的HTTPS通讯，那么这个方式称之为Hard-fail

如果你选择信任该证书，认为没有被吊销，那么这个方式称之为Soft-fail

如果是hard-fail模式，那浏览器对任何HTTPS服务器访问的先决条件都取决于OCSP Server，这将是一个致命的单点故障，对于具有资深架构设计经验的你来说，你会这么选择吗？

如果是soft-fail模式，取不到OCSP Server的响应就忽略了，那么，要这个机制还有啥意义呢？要你有何用？

OCSP Stapling

OCSP Stapling的方案是解决了CRL、OCSP的缺点，将通过OCSP Server获取证书吊销状况的过程交给Web 服务器来做，Web 服务器不光可以直接查询OCSP信息，规避网络访问限制、OCSP服务器离用户的物理距离较远等问题，还可以将查询响应缓存起来，给其他浏览器使用。由于OCSP的响应也是具备CA RSA私钥签名的，所以不用担心伪造问题。

解决了访问慢的问题

解决了用户隐私泄露的问题

OCSP Must-Staple

面对hard-fail、soft-fail的问题，各家浏览器厂商的态度都不一样。同时，不管浏览器如何选择，都不能满足广大域名用户的需求，那么不如把这个选择交给域名用户自己。

为此，OCSP Must-Staple应运而生了，浏览器必须检测OCSP响应。域名证书创建时，自定义设定启用这个选项，将这个信息打入X.509 v3的扩展中，浏览器读取后，强制进行OCSP检测，走hard-fail模式。

这个规范被起草在 X.509v3 Extension: OCSP Stapling Required draft-hallambaker-muststaple-00 ，不过，暂未被采纳为RFC标准。

10 CSR

CSR是Certificate Signing Request的英文缩写，即证书请求文件，也就是证书申请者在申请数字证书时由CSP(加密服务提供者)在生成私钥的同时也生成证书请求文件，证书申请者只要把CSR文件提交给证书颁发机构后，证书颁发机构使用其根证书私钥签名就生成了证书公钥文件，也就是颁发给用户的证书。

//参考：https://blog.csdn.net/Ki8Qzvka6Gz4n450m/article/details/104230868.

二、握手过程

摘自/转自：

https://blog.51cto.com/u_9843231/2466504.

https://blog.csdn.net/dljthez/article/details/5217765.

https://blog.csdn.net/en_joker/article/details/105533383.

https://laoqingcai.com/tls1.2-premasterkey/.

https://segmentfault.com/a/1190000021559557.

①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

上边两步实现版本、算法协商

③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过， 通讯将断开；如果合法性验证通过，将继续进行第四步。

④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。

⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。

⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为 客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码 ”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。

上边步骤相互确认，产生预主密钥

⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥 用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥 ，同时通知服务器客户端的握手过程结束。

⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥 ，同时通知客户端服务器端的握手过程结束。

⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥 进行数据通讯，同时进行通讯完整性的检验。