HTTPS握手过程、常见问题

DD-WL

已于 2022-12-04 20:25:11 修改

阅读量767

点赞数

分类专栏：杂类 linux 系统文章标签： https 密码学 openssl ssl

于 2021-05-08 17:19:14 首次发布

本文链接：https://blog.csdn.net/weixin_44376670/article/details/116521352

版权

linux 系统同时被 2 个专栏收录

24 篇文章 2 订阅

订阅专栏

杂类

8 篇文章 0 订阅

订阅专栏

前言

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

一、常见问题/概念

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

答：两个字段的值是一样的，具体参考RFC5280
https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.3

2 证书链验证顺序

答：每一个证书都有一个签名，签名由另外一个证书对应的私钥或者证书自己的私钥签名（自签名证书），验证时由用户证书->…->CA根证书方向验证
如：根CA -》CA1 -》CA2 -》服务器
服务器发给客户端的证书链中不仅包含自己的证书，还要包含各个中间CA的证书，本例子中也即CA1和CA2以及服务器自己的证书。
客户端首先验证 CA2 ->服务器这一环，分为以下步骤：

1、从CA2的证书中，拿出CA2的公钥，对服务器证书中的CA2的签名进行解密。
对服务器证书中的明文信息进行hash，使用的hash算法与CA2所使用的hash算法一致。
对比前两步的结果，看其是否相等，若相等则验证通过。
验证通过后，客户端继续验证证书链的下一个环节，即 CA1 -> CA2，与上一个环节大同小异，分为以下步骤：

2、从CA1的证书中，拿出CA1的公钥，对CA2证书中的CA1的签名进行解密。
对CA2证书中的明文信息进行hash，使用的hash算法与CA1所使用的hash算法一致。
对比前两步的结果，看其是否相等，若相等则验证通过。
验证通过后，客户端继续验证证书链的最后一个环节，即根CA -> CA1，注意第一步的不同之处：

3、从自己本地的缓存中，拿出根CA的公钥，对CA1证书中的根CA的签名进行解密。
对CA1证书中的明文信息进行hash，使用的hash算法与根CA所使用的hash算法一致。
对比前两步的结果，看其是否相等，若相等则验证通过。
至此证书验证过程结束。客户端本地会缓存一些少量的，全球都认可的根CA的证书（浏览器或操作系统会自带一些根证书），根CA的证书是自签名的，其中也会包含根CA的公钥。

无论有多少中间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文件提交给证书颁发机构后，证书颁发机构使用其根证书私钥签名就生成了证书公钥文件，也就是颁发给用户的证书。

11、TLS1.3提供三种密钥交换模式

（EC)DHE （DDiffer-Hellman overr either finite fields or elliptic curves）（论文中讨论有限域上椭圆曲线秘钥交换模式）
PSK -Only
PSK with (EC)DHE (暂时还没有实现)

signature_algorithms扩展与ciher_suite

signature_algorithms扩展指定签名/hash算法，ciher_suite只指定了签名算法和MAC算法，未指定签名时的hash算法，里面的sha不是签名时的hash算法，只是用来计算握手消息的MAC算法（finished消息使用）。
参考 https://mirrors.nju.edu.cn/rfc/rfc5246.html#section-7.4.1.4.1

ssl会话复用方式

ssl会话复用: sessionid、session ticket、presharekey（tls1.3版本使用）
1、sessionid由客户端、服务器保存sid和相关密钥信息，复用时在clienthello中携带sid，服务器通过sid查找到上次信息（主要是主密钥），然后双方根据主密钥以及随机数等重新生成对称密钥即可通信。
2、session ticket是首次握手时服务器生成一个ticket发送给客户端保存，tciket主要包含加密后的主密钥信息（客户端无需关心具体内容，客户端一侧的主密钥由客户端自己保存）。复用时客户cllienthello携带ticket，服务器端解密获取主密钥，双方生成对称密钥进行通信。相对于sessionid方式，ticket方式不需要服务端保存会话信息，因为主密钥是解密ticket获得。特别是多服务器集群时，只需要配置相同key即可解密，其他服务器的ticket。（sid方式要想同步其他服务器的会话比较麻烦，需要同步所有相关会话信息）。ticket方式需要定期更新服务器的key，以确保前向性安全。

finishd消息用对称密钥加密

签名算法与密钥交换算法不一定一致

如可以使用ECDHE交换密钥，使用RSA算法签名

RSA\DHE\ECDHE三种交换秘钥算法区别

1、基于RSA算法交换密钥是通过非对称加密传输对称密钥，此方式具有明显确定，不具备前向性安全，即：一旦证书私钥泄露或被破解后，历史交互数据都可以被解密。（不推荐使用）
2、DHE\ECDHE两种交换密钥方式在握手过程中并不传递真正的对称密钥，中间人获取所有握手消息、且即时获取了证书私钥也无法得到对称密钥，具有完全前向性安全。（DH和ECDH是不具备前向性安全的版本，因为此时服务器端的对称密钥参数是固定值，一旦泄露就可以解密历史数据）
详细算法原理参考： https://blog.csdn.net/weixin_60297362/article/details/123056506
https://blog.csdn.net/s2603898260/article/details/120339398

server_key_exchange使用证书私钥签名

可以保证客户端收到的key为真实的（key不需要保密，中间人知道了也没办法生成对称密钥，因为c/s两端才有椭圆曲线对应的私钥）。

证书是私钥签名，公钥验证。证书中保存的是公钥

https://blog.csdn.net/taoqick/article/details/105167474

clinet/server随机数

是为了和（pre master key或ecdh等参数）一起生成最后对称密码，增加密码随机程度，增加破解难度。

为什么需要使用证书签名？

非对称秘钥交换（包括DHE、ECDHE）可以保证消息不会被解密，但并不能真正解决安全问题，因为中间人可以伪装和C/S交互。只有在身份验证的情况下才能保障安全（确保客户端或服务器收到的证书是真正的公钥，而不是中间人的假公钥）。证书签名就是为了解决验证问题，因为证书是由签发机构的私钥加密，只有对应的公钥才能解密，而这个私钥只有签发机构自己知道，所以可以证明不是伪造的。

常见算法

RSA/ECC是非对称加密算法， DHE是密钥交换机机制不是加密算法，ECDHE是基于ECC的DHE变本。

DH/ECDH相对与DHE/ECDHE一般指服务端的私钥是固定的，这样一旦私钥泄露，会造成前向性安全。而E版本每次都是动态生成的，不会造成历史数据安全。即使知道了私钥也没用。

ECDHE相对DHE效率更高，计算速度更快，也增加了可逆难度（ECDHE的运算是把DHE中模幂运算替换成了点乘运算，速度更快，可逆更难。）

ECC算法的数学理论非常深奥和复杂，在工程应用中比较难于实现，但它的单位安全强度相对较高，它的破译或求解难度基本上是指数级的，黑客很难用通常使用的暴力破解的方法来破解。RSA算法的特点之一是数学原理相对简单，在工程应用中比较易于实现，但它的单位安全强度相对较低。因此，ECC算法的可以用较少的计算能力提供比RSA加密算法更高的安全强度，有效地解决了“提高安全强度必须增加密钥长度”的工程实现问题。

ECC证书常用于嵌入式或移动设备中，以提高带宽利用率等。

//参考资料：
https://blog.csdn.net/Ki8Qzvka6Gz4n450m/article/details/104230868.
https://mirrors.nju.edu.cn/rfc/rfc7925.html
https://blog.csdn.net/fitaotao/article/details/122536726
https://blog.csdn.net/qq_35448165/article/details/113528155
TLS1.3的整个协议的文档规范请参照 RFC 8846
https://blog.csdn.net/gdfhhj/article/details/87206305
https://blog.csdn.net/taoqick/article/details/105167474