HTTPS学习总结

最近在学习https，读了两本https相关书籍，将理解和吸收的部分总结一下。

1 前言

超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS)

如今，越来越多的网站采用 https 协议进行数据通信。https 是在 http 基础之上，采用传输层安全层 (TLS) 或安全套接字层 (SSL) 对通信数据进行加密，从而保证数据传输的安全。

众所周知，新技术产生是为了弥补旧技术的缺陷，那 http 协议存在着哪些问题呢？

首先，http 全称超文本传输协议，在互联网早期，主要是为了方便学术交流，传递简单的 HTML 文本，数据采用明文形式在网络上传输。随着互联网技术的快速发展，网站的功能越来越丰富，人们可以在网站上完成购物、支付、转账等，http 协议在这样的使用场景下便存在着巨大的安全风险。常见的攻击方式便是中间人攻击，黑客可以利用 http 的安全漏洞窃取网络传输的数据，然后篡改，伪造请求等，从而谋取利益。

http存在的问题如下：

1、数据明文传输

http 协议采用明文的形式传输，意味着只要进行网络数据抓包，便可以获取用户数据。例如采用 Fiddler 对网络传输发送与接受的数据包进行截获、编辑、重发等操作，以此获取用户的数据。

常见的中间人攻击，黑客利用工具对请求数据进行拦截，再伪造请求发送至服务器，来达到不可告人的目的。如生活中处处使用的公共WiFi，如果用户连上了黑客搭建的恶意WiFi，再通过此WiFi登录各种应用、网站，此时黑客便可以抓取数据，获取用户的账号、密码等重要数据。

2、无法验证通信双方身份

http 在数据通信过程中，客户端和服务端无法确认对方的身份，只要请求和响应数据格式正确，就可以正常通信。无法验证身份意味着通信过程中有第三方介入，充当中间人对信息拦截转发，客户端和浏览器都是直接和中间人进行通信，这就存在极大的安全风险。

3、无法判断数据是否篡改

客户端和服务端在通信过程中，http 协议无法确认信息的完整性，即使请求或响应的内容遭到篡改，也没有办法获悉。

2 https 协议

针对上诉 http 协议的三个缺点，https 协议做了如下优化：

1、数据传输加密

• 数据传输过程不采用明文，而是加密之后再传输。

2、信息完整性检验

• 通过数字签名解密后的信息摘要验证数据的完整性。

3、身份认证

• 利用数字证书鉴别通信方身份的合法性。

接下来将介绍 https 协议中涉及的基本要素，SSl/TLS，加解密，数字签名，数字证书。

2.1 SSL/TLS

首先，https 并不是一种新的协议，而是 http + SSL/TLS 组合而来的（如图所示），在 http 和 tcp 之间加入SSL/TLS 协议，通过 SSL/TLS 对数据进行加密和解密，从而保证数据的安全性。

SSL 是网景公司为了解决 HTTP 的安全问题 ，于1994 年创建了 SSL 协议 ， 作为浏览器的一个扩展，主要应用于 HTTP 。 SSL 协议有三个版本，分别 是 SSL vl 、SSL v2 、SSL v3 。1996 年，IETF (Internet Engineering Task Force ）组织在 SSL v3 的基础上进一步标准化了该协议， 微软为这个新协议取名 TLS ，TLS 一共出现过三个版本，1.1、1.2 和 1.3 ，目前最广泛使用的是 TLS 1.2。

https 协议安全的核心在于 SSL/TLS，TLS / SSI 协议核心就三大步骤 ：身份认证、密钥协商、数据加密 。TLS/SSL 的功能实现主要依赖于三类基本算法：摘要算法 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于摘要算法验证信息的完整性。TLS/SSL 本身不能校验通信方的合法性，引入数字证书后才能验证通信方的真实性。

2.2 加密

https在传输数据过程中采用对称加密和非对称加密两种形式。在密钥协商阶段采用的是非对称加密，数据传输过程则采用对称加密。

对称加密

加密和解密使用同一个密钥。常见的算法： DES，3DES，AES (128bits, 192bits, 256bits, 384bits) 。

对称加密的优点是加密和解密速度快，但加密和解密采用相同的密钥，如果密钥泄漏，即使数据加密，也能够被解密出来。

非对称加密

非对称性加密，加密解密的过程使用不同的密钥。常见的非对称加密算法有，RSA，DH，ECC，DSA。密钥分为公钥与私钥：

• 公钥：从私钥中提取产生；可公开给所有人；pubkey
• 私钥：通过工具创建，使用者自己留存，必须保证其私密性；secret key；

特点：公钥加密，私钥解密，私钥加密，公钥解密。

非对称加密的优点是加解密采用不同的密钥，私钥保存在服务端，不容易泄漏，数据加密之后不容易被破解，但加密数据时间较长。

如果浏览器和服务器通信仅采用非对称加密，一旦页面数据量大，加解密时间过长，会导致页面加载速度较慢。而如果仅采用对称加密，在首次进行数据传输时，需要服务端和客户端保存相同的密钥，对称密钥在传输过程中依旧存在中间人攻击，对称密钥容易被截取。

于是，基于对称加密和非对称加密的特点，https采用了两种方式共同对数据进行加密。

2.3 数字证书

数字证书由第三方权威机构颁发，作用是验证服务端身份合法性，类似于我们的身份证。颁发数字证书的机构为Certificate Authority，简称 CA 机构。

采用 https 协议的网站，在浏览器地址栏上有一个小锁🔒，点击小锁，可以看到数字证书具体信息。以掘金网为例，数字证书包含的信息主要有：证书的颁发机构，颁发的对象，证书有效期，公钥，签名算法，信息摘要算法，证书链等信息。

如下图，掘金网的数字证书由RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1机构颁发，数字证书中的公钥是采用 RSA 算法生成的，并且数字签名采用的sha256和RSA生成。

证书申请

网站要使用 https 协议，需要先向 CA 机构申请证书。

申请流程如下（如图）：

• 网站需要准备一套私钥和公钥，私钥留着自己使用；（CA 机构也可以直接生成私钥和公钥）
• 网站向 CA 机构申请证书，在申请之前，需要提交 CSA 文件。CSA文件包含两部分：1. 生成证书必需的信息，比如域名、公钥；服务器实体的证明材料 ，比如企业的纳税编号、邮件地址等信息。
• CA 通过线上、线下等多种渠道来验证网站所提供信息的真实性，如公司是否存在、企业是否合法、域名是否归属该企业等；
• 如信息审核通过，CA 会向网站签发认证的数字证书，包含了网站的公钥、组织信息、CA 的信息、有效时间、证书序列号等，这些信息都是明文的，同时包含一个 CA 生成的数字签名。数字签名是采用摘要算法（如sha256）将数字证书信息生成信息摘要，再采用CA机构自己的私钥加密信息摘要，生成数字签名。

证书类型

服务器向CA机构申请数字证书时，按照审核的严格程度分为，DV, OV, EV 三种类型证书。

• DV 证书

  DY ( Domain Validated）证书是最常见的一种证书类型 ，申请证书的 CSR 请求会包含域名信息 ，CA 机构 获取 CSR 请求后，从中取出域名，校验域名的所有权，如果域名所有者就是证书申请者，代表身份审核通过，申请者有权申请该域名（包含子域名）对应的证书。

• OV 证书

  对于 OV ( Organization Va lid ated ）证书 ，CA 机构会对申请者的身份进行严格的审核 ，从而给用户（浏览器〉提供更安全的信任。CA 根据严格的标准会审核申请者身份，比如说审核申请者的企业资质、企业地址等消息，确保申请者的身份是真实的。一般来说，企业和政府机构一般会申请 ov 证书，由于审核申请者的身份需要时间，申请 ov 证书完成的时间比 DV 证书申请完成的时间要长 。

• EV证书

  对于 EV ( Extended Validation ）证书， CA 机构会对申请者的身份进行更严格的审核，对于 CA 机构来说，CA 机构会严格根据 CA/Browser 论坛制定的标准审核申请者的身份，该标准称为 Baseline Requirement 标准，是由浏览器厂商、 CA 等机构创建的。

证书链

数字证书用于校验通信方的身份是否真实可靠，检验数字证书可以判断证书是由某个CA机构颁发。假如CA机构不可靠，那CA机构颁发的数字证书也不可靠的，因此也需要验证 CA 机构的身份。

如何校验CA机构的真实性呢？

目前采用的是将权威 CA 机构的数字证书内置于操作系统内（浏览器也会自带信任的证书），浏览器假设内置的证书全都是合法的，在此基础上，通过内置证书去检验网站的数字证书的合法性。但是CA机构众多，不可能都内置于系统中，并且 CA 机构成立或者撤销，更新操作系统的证书是很麻烦的过程。

于是人们采用一个折中的方案，即证书链校验机制。 CA 机构分为两种，根 CA 机构和中间 CA 机构。根 CA 机构负责认证中间 CA 机构，给中间 CA 机构颁发证书，中间 CA 机构又可以认证其他 CA 机构，而根CA机构的证书是自己给自己颁发，属于自签名证书。网站的证书来自于中间 CA 机构，这样就形成了一个证书链，你可以沿着证书链从用户证书追溯到根证书。

数字证书验证

数字证书的校验我分为两个步骤，一个是证书链的检验，一个是服务器实体证书的检验。

1、证书链检验

浏览器在向服务端发送请求时，会得到服务器返回的数字证书。通常情况下服务器也会配置完整的证书链，将中间CA 机构的证书一同发送到浏览器。如果服务器没有配置完整的证书链，只包含服务器本身的证书，浏览器会从服务器实体证书中获取 CA 密钥标识符，进而获取上一级中间证书文件，然后通过中间证书中的 CA 密钥标识符不断迭代直到获取根证书 。 服务器发送完整证书链的好处在于提高握手速度，浏览器无须额外再去寻找其他中间证书，能够加快 HTTPS 握手过程。

浏览器不能充分信任服务器发送的证书链文件，需要确保每个证书（除了根证书）的签发者（ issuer ）是它的上一级证书（证书链的上部）的使用者（ subject ） ，如果不符合该条件，证书校验失败 。 浏览器校验数字证书链的过程是迭代签名校验。

• 浏览器从服务器实体证书的上 一级证书（ 比如 B 证书 〉获取公钥，用来校验服务器实体证书的签名，校验成功则继续，否则证书校验失败。
• 浏览器从 B 证书的上一级证书（ 比如 C 证书）获取公钥，用来校验 B 证书的签名，校验成功则继续，否则证书校验失败 。
• 该校验过程不断选代 ， 直到浏览器发现某张证书的签发者和使用者是同 一个人，代表找到了根证书，校验根证书的签名和校验非根证书的签名是不一样的，校验根证书签名使用的公钥就在根证书中，而校验其他非根证书签名使用的公钥来自上一级证书 ， 根证书使用自己的公钥验证签名 ，如果校验成功就代表完整的证书链校验成功。

2、服务器实体证书检验

服务器证书的检验主要包括两个部分，第一部分就是验证证书的有效期，这部分比较简单，因为证书里面就含有证书的有效期，所以浏览器只需要判断当前时间是否在证书的有效期范围内即可。

第二部分就是验证数字证书是否被吊销了。通常有两种方式，一种是下载吊销证书列表 -CRL (Certificate Revocation Lists)，第二种是在线验证方式 -OCSP (Online Certificate Status Protocol) 。

当然，证书校验的过程不止这两个部分，还包括域名检验、证书扩展检验等等。

总之，通过证书链和服务器证书的检验之后，浏览器就会确认服务端的身份可信，随即就会进入下一步密钥协商和数据通信了。

思考：

1、如果黑客攻击用户，给用户系统安装恶意的根证书，此时整个证书校验过程就变的不可靠了，是否会存在这种情况呢，如何防范？

2、如果黑客采用某种手段欺骗 CA 机构搞到了一张真的数字证书，那这个数字证书检验也变得不可靠了。

3、假设浏览器已经判断出证书无效，貌似浏览器不会中断连接，而是弹出警告，要是用户忽略警告，点击继续访问，那还是存在着通信风险，这种情况是浏览器厂商将风险转交给用户来自行判断。

总体而言，数字证书并非绝对的安全可靠。

2.4 数字签名

数字签名由颁发数字证书的 CA 机构生成，通过数字签名可以检验信息的完整性，确认签名者的身份。要生成数字签名，首先需要采用摘要算法对证书信息进行单向计算，生成一个特定长度的字符串，又称信息摘要，然后采用 CA 机构的私钥加密生成数字签名。

摘要算法

摘要算法是将任意长度的输入转化为定长输出的算法。摘要算法的结果经常被简称为散列（ hash）。摘要算法具有以下特性：

• 抗原像性（单向性） 给定一个散列，计算上无法找到或者构造出生成它的消息。
• 抗第二原像性（弱抗碰撞性） 给定一条消息和它的散列，计算上无法找到一条不同的消息具有相同的散列。
• 强抗碰撞性 计算上无法找到两条散列相同的消息

常见的摘要算法有MD5，SHA-1，SHA-2, 目前 SHA-1被证明不够安全，推荐使用 SHA-2。

通过摘要算法将证书的信息生成信息摘要，但凡修改证书文件的任一信息，生成的信息摘要也会不同。如果两次证书信息生成的信息摘要不一致，那就表明信息被修改过，因此摘要算法可以验证信息的完整性。

签名验证

浏览器验证签名的过程是沿着证书链向上验证，检验每一层级证书的真实性。

首先，CA 机构利用自己的私钥对证书信息摘要进行加密得到数字签名。私钥是唯一的，只有颁发证书的机构拥有，而公钥是公开的，在CA机构的证书中，浏览器通过证书链拿到。

然后，浏览器在拿到服务器证书中的数字签名时，从上一级的CA 机构的数字证书中拿到公钥进行解密，会得到一个信息摘要，同时采用摘要算法将服务器证书的信息生成一个信息摘要，然后对比两个信息摘要，如果一致，则表明没有被修改，身份认证成功，不一致，则认证失败。

3 https 通信过程

通过前面的基本介绍，讲述了 https 协议的加密、数字证书及数字签名的基本知识，接下来将整个 https 通信流程完整的梳理一遍。

HTTPS整个流程如上图所示：

我个人将 https 的通信过程划分为两个阶段，第一个是握手阶段，第二个是真正的数据加密传输阶段。握手阶段主要是进行身份验证和密钥协商。

握手阶段：

0. 浏览器生成一个随机数 client_random，同时发送密码套件。密码套件是密码学算法组合 ，简单的讲就是浏览器支持哪些加密算法。
1. 服务器接受浏览器发送的随机数、密码套件，然后从密码套件中选择后续加密要使用的算法，同时再生成一个随机数 server_random，然后将选择的密码套件、随机数和服务器的数字证书一同发送给浏览器。此时服务器和浏览器便各自拥有两个随机数。
2. 拿到数字证书后，就可以对服务端的身份进行验证。验证数字证书有两个步骤，验证数字证书链和服务端数字证书。证书链一般通过服务器发送，通过证书链获取到各级CA机构的数字证书，最顶级的CA机构证书内置于浏览器或操作系统中。证书链的验证过程是利用数字签名去迭代检验，根证书的公钥和私钥都在证书中，属于自签名证书，自己验证自己。证书链的验证完成就是验证服务器的证书是否合法，包括有效期，是否吊销等等。
3. 数字证书验证通过后，浏览器生成一个随机数 pre_master，又称预主密钥。然后利用服务器证书中的公钥加密预主密钥，传给服务端。服务端拿到数据之后用自己的私钥解密，获取 pre_master。此时服务器和浏览器各自拥有三个随机数，client_random，server_random，pre_master，然后将三者结合起来采用协商好的算法生成主密钥 master_key。这个主密钥就是后续数据传输过程对称加密的密钥，至此握手阶段结束。

数据传输：

0. 浏览器采用 master_key 和对称加密算法加密要传输的数据，传送给服务端。
1. 服务端利用 master_key 解密数据，然后将响应数据加密，发送给浏览器。
2. 浏览器采用 master_key 解密数据。
3. 后续传输过程重复上述步骤。

注意：

上述的https握手过程简化了流程，实际上https（或者SSL/TLS）握手过程不仅是上述这么简单。如果想了解更加细致的流程，可以参考《深入浅出HTTPS从原理到实战》第8章或者《HTTPS权威指南》第2章。

4 https安全性

前面讲了这么多，一直在强调 https 传输的安全性，那有了 https ，数据通信就一定安全吗？

正所谓道高一尺魔高一丈，https 并不能保证绝对的安全，只是增加的黑客攻击的难度和成本。https 攻击也存在一些攻击手段，例如心脏流血 (Heartbleed )、SSL 剥离 (SSL Stripping)、降级攻击、虚假证书等等。总之，https协议已经能满足绝大部分的场景，当然，如果要保证极高的安全性，还得结合其他的安全防范策略。关于网络安全这块没有具体研究过，就不作说明了。

5 总结

本文主要是介绍了 https 通信过程以及相关知识点，主要是方便我自己学习和总结。本人才疏学浅，本着最好的学习方式就是将学习的东西能够输出出来，写下了这篇文章。由于缺少实际的经验，上述内容主要是阅读网上的文章和书籍总结而来，或许存在理解不到位的情况，请读者自行判断和验证。关于https的具体细节，可以参考结尾的参考文献。

前端学习之路漫长又有趣，“路漫漫其修远兮，吾将上下而求索”！

参考文献

《深入浅出HTTPS从原理到实战》作者 虞卫东。

《HTTPS权威指南》作者 Ivan Ristic，杨洋、李振宇译。

《 浏览器工作原理与实践》极客时间，李兵，https章节。