Https协议

HTTPS 为什么会出现

一个新技术的出现必定是为了解决某种问题的，那么 HTTPS 解决了 HTTP 的什么问题呢？

HTTPS 解决了什么问题

一个简单的回答可能会是 HTTP 它不安全。由于 HTTP 天生明文传输的特性，在 HTTP 的传输过程中，任何人都有可能从中截获、修改或者伪造请求发送，所以可以认为 HTTP 是不安全的；在 HTTP 的传输过程中不会验证通信方的身份，因此 HTTP 信息交换的双方可能会遭到伪装，也就是没有用户验证；在 HTTP 的传输过程中，接收方和发送方并不会验证报文的完整性，综上，为了结局上述问题（窃听风险、篡改风险、冒充风险），HTTPS 应用而生。

什么是 HTTPS

你还记得 HTTP 是怎么定义的吗？HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol) 协议，它是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范，那么我们看一下 HTTPS 是如何定义的

HTTPS 的全称是 Hypertext Transfer Protocol Secure，它用来在计算机网络上的两个端系统之间进行安全的交换信息(secure communication)，它相当于在 HTTP 的基础上加了一个 Secure 安全的词眼，那么我们可以给出一个 HTTPS 的定义：HTTPS 是一个在计算机世界里专门在两点之间安全的传输文字、图片、音频、视频等超文本数据的约定和规范。 HTTPS 是 HTTP 协议的一种扩展，它本身并不保传输的证安全性，那么谁来保证安全性呢？在 HTTPS 中，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。

HTTPS 做了什么

HTTPS 协议提供了三个关键的指标：

• 加密(Encryption)， HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息。
• 数据一致性(Data integrity)，数据在传输的过程中不会被窃听者所修改，用户发送的数据会完整的传输到服务端，保证用户发的是什么，服务器接收的就是什么。
• 身份认证(Authentication)，是指确认对方的真实身份，也就是证明你是你（可以比作人脸识别），它可以防止中间人攻击并建立用户信任。

有了上面三个关键指标的保证，用户就可以和服务器进行安全的交换信息了。那么，既然你说了 HTTPS 的种种好处，那么我怎么知道网站是用 HTTPS 的还是 HTTP 的呢？给你两幅图应该就可以解释了。

HTTPS 协议其实非常简单，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名，默认端口号443，至于其他的应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。

也就是说，除了协议名称和默认端口号外（HTTP 默认端口 80），HTTPS 协议在语法、语义上和 HTTP 一样，HTTP 有的，HTTPS 也照单全收。那么，HTTPS 如何做到 HTTP 所不能做到的安全性呢？关键在于这个 S 也就是 SSL/TLS 。

什么是 SSL/TLS

认识 SSL/TLS

TLS(Transport Layer Security) 是 SSL(Secure Socket Layer) 的后续版本，它们是用于在互联网两台计算机之间用于身份验证和加密的一种协议。

注意：在互联网中，很多名称都可以进行互换。

我们都知道一些在线业务（比如在线支付）最重要的一个步骤是创建一个值得信赖的交易环境，能够让客户安心的进行交易，SSL/TLS 就保证了这一点，SSL/TLS 通过将称为 X.509 证书的数字文档将网站和公司的实体信息绑定到加密密钥来进行工作。每一个密钥对(key pairs) 都有一个 私有密钥(private key) 和 公有密钥(public key)，私有密钥是独有的，一般位于服务器上，用于解密由公共密钥加密过的信息；公有密钥是公有的，与服务器进行交互的每个人都可以持有公有密钥，用公钥加密的信息只能由私有密钥来解密。

什么是 X.509：X.509 是公开密钥证书的标准格式，这个文档将加密密钥与（个人或组织）进行安全的关联。

X.509 主要应用如下

• SSL/TLS 和 HTTPS 用于经过身份验证和加密的 Web 浏览
• 通过 S/MIME 协议签名和加密的电子邮件
• 代码签名：它指的是使用数字证书对软件应用程序进行签名以安全分发和安装的过程。

通过使用由知名公共证书颁发机构（例如SSL.com）颁发的证书对软件进行数字签名，开发人员可以向最终用户保证他们希望安装的软件是由已知且受信任的开发人员发布；并且签名后未被篡改或损害。

• 还可用于文档签名
• 还可用于客户端认证
• 政府签发的电子身份证（详见 www.ssl.com/article/pki…

我们后面还会讨论。

HTTPS 的内核是 HTTP

HTTPS 并不是一项新的应用层协议，只是 HTTP 通信接口部分由 SSL 和 TLS 替代而已。通常情况下，HTTP 会先直接和 TCP 进行通信。在使用 SSL 的 HTTPS 后，则会先演变为和 SSL 进行通信，然后再由 SSL 和 TCP 进行通信。也就是说，HTTPS 就是身披了一层 SSL 的 HTTP。（我都喜欢把骚粉留在最后。。。）

SSL 是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用，比如 SMTP(电子邮件协议)、Telnet(远程登录协议) 等都可以使用。

探究 HTTPS

我说，你起这么牛逼的名字干嘛，还想吹牛批？你 HTTPS 不就抱上了 TLS/SSL 的大腿么，咋这么牛批哄哄的，还想探究 HTTPS，瞎胡闹，赶紧改成 TLS 是我主，赞美我主。

SSL 即安全套接字层，它在 OSI 七层网络模型中处于第五层，SSL 在 1999 年被 IETF(互联网工程组)更名为 TLS ，即传输安全层，直到现在，TLS 一共出现过三个版本，1.1、1.2 和 1.3 ，目前最广泛使用的是 1.2，所以接下来的探讨都是基于 TLS 1.2 的版本上的。

TLS 用于两个通信应用程序之间提供保密性和数据完整性。TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术（如果你觉得一项技术很简单，那你只是没有学到位，任何技术都是有美感的，牛逼的人只是欣赏，并不是贬低）。

说了这么半天，我们还没有看到 TLS 的命名规范呢，下面举一个 TLS 例子来看一下 TLS 的结构（可以参考 www.iana.org/assignments…

ECDHE-ECDSA-AES256-GCM-SHA384

这是啥意思呢？我刚开始看也有点懵啊，但其实是有套路的，因为 TLS 的密码套件比较规范，基本格式就是 密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 组成的一个密码串，有时候还有分组模式，我们先来看一下刚刚是什么意思

使用 ECDHE 进行密钥交换，使用 ECDSA 进行签名和认证，然后使用 AES 作为对称加密算法，密钥的长度是 256 位，使用 GCM 作为分组模式，最后使用 SHA384 作为摘要算法。

TLS 在根本上使用对称加密和 非对称加密 两种形式。

对称加密

在了解对称加密前，我们先来了解一下密码学的东西，在密码学中，有几个概念：明文、密文、加密、解密

• 明文(Plaintext)，一般认为明文是有意义的字符或者比特集，或者是通过某种公开编码就能获得的消息。明文通常用 m 或 p 表示
• 密文(Ciphertext)，对明文进行某种加密后就变成了密文
• 加密(Encrypt)，把原始的信息（明文）转换为密文的信息变换过程
• 解密(Decrypt)，把已经加密的信息恢复成明文的过程。

对称加密(Symmetrical Encryption)顾名思义就是指加密和解密时使用的密钥都是同样的密钥。只要保证了密钥的安全性，那么整个通信过程也就是具有了机密性。

TLS 里面有比较多的加密算法可供使用，比如 DES、3DES、AES、ChaCha20、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK 等。目前最常用的是 AES-128, AES-192、AES-256 和 ChaCha20。

DES 的全称是 Data Encryption Standard(数据加密标准)，它是用于数字数据加密的对称密钥算法。尽管其 56 位的短密钥长度使它对于现代应用程序来说太不安全了，但它在加密技术的发展中具有很大的影响力。

3DES 是从原始数据加密标准（DES）衍生过来的加密算法，它在 90 年代后变得很重要，但是后面由于更加高级的算法出现，3DES 变得不再重要。

AES-128, AES-192 和 AES-256 都是属于 AES ，AES 的全称是Advanced Encryption Standard(高级加密标准)，它是 DES 算法的替代者，安全强度很高，性能也很好，是应用最广泛的对称加密算法。

ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错算法。

（其他可自行搜索）

加密分组

对称加密算法还有一个分组模式 的概念，对于 GCM 分组模式，只有和 AES，CAMELLIA 和 ARIA 搭配使用，而 AES 显然是最受欢迎和部署最广泛的选择，它可以让算法用固定长度的密钥加密任意长度的明文。

最早有 ECB、CBC、CFB、OFB 等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和 Poly1305。

比如 ECDHE_ECDSA_AES128_GCM_SHA256 ，表示的是具有 128 位密钥， AES256 将表示 256 位密钥。GCM 表示具有 128 位块的分组密码的现代认证的关联数据加密（AEAD）操作模式。

我们上面谈到了对称加密，对称加密的加密方和解密方都使用同一个密钥，也就是说，加密方必须对原始数据进行加密，然后再把密钥交给解密方进行解密，然后才能解密数据，这就会造成什么问题？这就好比《小兵张嘎》去送信（信已经被加密过），但是嘎子还拿着解密的密码，那嘎子要是在途中被鬼子发现了，那这信可就是被完全的暴露了。所以，对称加密存在风险。

非对称加密

非对称加密(Asymmetrical Encryption) 也被称为公钥加密，相对于对称加密来说，非对称加密是一种新的改良加密方式。密钥通过网络传输交换，它能够确保及时密钥被拦截，也不会暴露数据信息。非对称加密中有两个密钥，一个是公钥，一个是私钥，公钥进行加密，私钥进行解密。公开密钥可供任何人使用，私钥只有你自己能够知道。

使用公钥加密的文本只能使用私钥解密，同时，使用私钥加密的文本也可以使用公钥解密。公钥不需要具有安全性，因为公钥需要在网络间进行传输，非对称加密可以解决密钥交换的问题。网站保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

非对称加密算法的设计要比对称算法难得多（我们不会探讨具体的加密方式），常见的比如 DH、DSA、RSA、ECC 等。

其中 RSA 加密算法是最重要的、最出名的一个了。例如 DHE_RSA_CAMELLIA128_GCM_SHA256。它的安全性基于 整数分解，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

ECC（Elliptic Curve Cryptography）也是非对称加密算法的一种，它基于椭圆曲线离散对数的数学难题，使用特定的曲线方程和基点生成公钥和私钥， ECDHE 用于密钥交换，ECDSA 用于数字签名。

TLS 是使用对称加密和非对称加密的混合加密方式来实现机密性。

混合加密

RSA 的运算速度非常慢，而 AES 的加密速度比较快，而 TLS 正是使用了这种混合加密方式。在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE ，首先解决密钥交换的问题。然后用随机数产生对称算法使用的会话密钥（session key），再用公钥加密。对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换。

现在我们使用混合加密的方式实现了机密性，是不是就能够安全的传输数据了呢？还不够，在机密性的基础上还要加上完整性、身份认证的特性，才能实现真正的安全。而实现完整性的主要手段是摘要算法(Digest Algorithm)

摘要算法

摘要算法也称为单向散列函数、哈希算法或散列算法。它通过把一个单向数学函数应用于数据，将任意长度的一块数据转换为一个定长的、不可逆转的数据。这段数据通常叫作消息摘要。消息摘要代表了原始数据的特征，当原始数据发生改变时，重新生成的消息摘要也会随之变化，即使原始数据的变化非常小，也可以引起消息摘要的很大变化。

散列函数的一些特性：

• 消息的长度不受限制
• 确定性：对于相同的输入（根据同一函数），它必须始终生成相同的散列值，如果两个散列值是不相同的，那么这两个散列值的原始输入也是不相同的， 但是对于不同的输入可能会散列成相同的输出（哈希碰撞），所以不可能从散列值来确定唯一的输入值。
• 均匀性：良好的散列函数应该输入尽可能均匀的映射到输出范围上。
• 单向性：在加密应用程序中，通常期望散列函数实际上是不可逆的。

因此，消息摘要算法可以敏感地检测到数据是否被篡改。消息摘要算法再结合其他算法就可以用来保护数据的完整性。

摘要算法你不清楚的话，MD5 你应该清楚，MD5 的全称是 Message Digest Algorithm 5，它是属于密码哈希算法(cryptographic hash algorithm)的一种，MD5 可用于从任意长度的字符串创建 128 位字符串值。尽管 MD5 存在不安全因素，但是仍然沿用至今。MD5 最常用于验证文件的完整性。但是，它还用于其他安全协议和应用程序中，例如 SSH、SSL 和 IPSec。一些应用程序通过向明文加盐值或多次应用哈希函数来增强 MD5 算法。

什么是加盐？在密码学中，盐就是一项随机数据，用作哈希数据，密码或密码的单向函数的附加输入。盐用于保护存储中的密码。例如

什么是单向？就是在说这种算法没有密钥可以进行解密，只能进行单向加密，加密后的数据无法解密，不能逆推出原文。

我们再回到摘要算法的讨论上来，其实你可以把摘要算法理解成一种特殊的压缩算法，它能够把任意长度的数据压缩成一种固定长度的字符串，这就好像是给数据加了一把锁。

除了常用的 MD5 是加密算法外，SHA-1(Secure Hash Algorithm 1) 也是一种常用的加密算法，不过 SHA-1 也是不安全的加密算法，在 TLS 里面被禁止使用。目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。

SHA-2 的全称是Secure Hash Algorithm 2 ，它在 2001 年被推出，它在 SHA-1 的基础上做了重大的修改，SHA-2 系列包含六个哈希函数，其摘要（哈希值）分别为 224、256、384 或 512 位：SHA-224, SHA-256, SHA-384, SHA-512。分别能够生成 28 字节、32 字节、48 字节、64 字节的摘要。

有了 SHA-2 的保护，就能够实现数据的完整性，哪怕你在文件中改变一个标点符号，增加一个空格，生成的文件摘要也会完全不同，不过 SHA-2 是基于明文的加密方式，还是不够安全，那应该用什么呢？

安全性更高的加密方式是使用 HMAC，在理解什么是 HMAC 前，你需要先知道一下什么是 MAC。

MAC 的全称是message authentication code，它通过 MAC 算法从消息和密钥生成，MAC 值允许验证者（也拥有秘密密钥）检测到消息内容的任何更改，从而保护了消息的数据完整性。

HMAC 是 MAC 更进一步的拓展，它是使用 MAC 值 + Hash 值的组合方式，HMAC 的计算中可以使用任何加密哈希函数，例如 SHA-256 等。

现在我们又解决了完整性的问题，那么就只剩下一个问题了，那就是认证，认证怎么做的呢？我们再向服务器发送数据的过程中，黑客（攻击者）有可能伪装成任何一方来窃取信息。它可以伪装成你，来向服务器发送信息，也可以伪装称为服务器，接受你发送的信息。那么怎么解决这个问题呢？

认证

出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的，如何确定你自己的唯一性呢？我们在上面的叙述过程中出现过公钥加密，私钥解密的这个概念。提到的私钥只有你一个人所有，能够辨别唯一性，所以我们可以把顺序调换一下，变成私钥加密，公钥解密。使用非对称密码算法和摘要算法，就能够实现数字签名，从而实现认证。

申请CA 签发的流程，如上图：

• 首先在服务端生成密钥对（公钥和私钥），并将服务端公钥和身份信息（例如服务器信息、公司信息等）生成证书请求文件（Certificate Signing Request，CSR）即证书签名申请，服务端私钥保存在自己服务器；
• 然后申请证书时需要将你证书的CSR文件提交给CA认证中心审核， CA 会对这些信息进行 Hash 计算，得到一个 Hash 值；
• 再然后 CA 会使用自己的私钥（CA私钥）将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如上图右边部分：

• 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
• 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

注意：生成数字签名使用的私钥加密用的是CA密钥，而不是服务端生成的密钥

证书链

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

对于这种三级层级关系的证书的验证过程如下：

• 客户端收到 http://baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 http://baidu.com 证书是否可信。于是，客户端根据 http://baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。
• 请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。
• “GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 http://baidu.com 证书的可信性，如果验证通过，就可以信任 http://baidu.com 证书。

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 http://baidu.com 证书，于是客户端也信任 http://baidu.com 证书。

总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 http://baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

火狐浏览器会在浏览器中内置一些根证书，操作系统里一般也会内置一些根证书，比如我的 MAC 电脑里内置的根证书有这么多：

这样的一层层地验证就构成了一条信任链路，整个证书信任链验证流程如下图所示：

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

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

https工作流程

• 用户在浏览器发起HTTPS请求（如 juejin.cn），默认使用服务端的443端口进行连接；
• HTTPS需要使用一套CA数字证书，证书内会附带一个公钥Pub，而与之对应的私钥Private保留在服务端不公开；
• 服务端收到请求，返回配置好的包含公钥Pub的证书给客户端；
• 客户端收到证书，校验合法性（身份认证、数据一致性），主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示HTTPS警告信息，如果通过则继续；
• 客户端生成一个用于对称加密的随机Key（会话密钥），并用证书内的公钥Pub进行加密，发送给服务端；
• 服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key；
• 服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端；
• 客户端使用随机Key对称解密密文，得到HTTP数据明文；
• 后续HTTPS请求使用之前交换好的随机Key进行对称加解密。

其中，公钥Pub与之对应的私钥Private是服务端生成的一对密钥，用于交换会话密钥。

Q&A

Q：中间人既然可以替换证书中的公钥，那数字签名可否替换，中间人是否可以通过证书中声明的哈希算法对明文生成摘要，然后结合自己的私钥伪造数字签名，这样客户端认证时不一样能通过么？

A：数字签名是由CA机构的私钥加密生成的，客户端通过内置CA机构的公钥进行解密，你替换数字签名客户端通过CA机构的公钥是解密不出来的，除非你能拿到CA机构的私钥伪造数字签名，但这是不可能的。

Q：SSL链接与TCP链接谁先建立？

A：TCP链接先于SSL链接建立，只有TCP链接先建立才能交换会话密钥（没有建立TCP通信通道怎么能利用通道交换会话密钥呢）

Q：HTTPS必须在每次请求中都要进行SSL握手传递会话密钥吗？

A：并不是。SSL是逻辑上独立于运输层的，并且是面向连接的，所以不管进行几次https请求，也不管tcp连接有没有更新，只要客户和服务器的SSL连接没有终止并且双方没有丢失这段SSL连接的识别号，客户和服务器之间就可以一直使用握手阶段生成的对称密钥进行应用层通信。只有重新进行SSL连接时才会再握手。

现在主流TLS协商会话密钥的方式都是Perfect Forward secrecy, 比如ECDHE。每次TLS握手都产生临时公钥，每次的TLS会话的对称加密密钥都不一样。Firefox/Chrome浏览器里会把会话密钥保存在环境变量SSLKEYLOGFILE中。

Q：什么是中间人攻击？
A：中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，并且能执行双向身份认证。参考中间人攻击原理与实践

总结

本篇文章我们主要讲述了 HTTPS 为什么会出现 ，HTTPS 解决了 HTTP 的什么问题，HTTPS 和 HTTP 的关系是什么，TLS 和 SSL 是什么，TLS 和 SSL 解决了什么问题？如何实现一个真正安全的数据传输？通过本文你应该了解到以下几点：

• 服务端生成的密钥对用于跟客户端协商安全交换会话密钥；
• https通过摘要算法确保数据（这个数据是指数字证书中的证书内容，比如服务端公钥）一致性；
• https通过（非对称加密算法（利用CA的密钥对）+ 摘要算法）生成数字签名，在客户端不忽略证书校验的条件下，可以确保服务端身份，使得证书不能被中间人伪造；
• 中间人攻击是利用两端身份认证的漏洞伪造一个受信的中间服务控制两端的整个会话通信

参考：

数字签名、公钥、私钥、CA证书之间的关系

HTTPS中间人攻击实践（原理·实践）

HTTPS是怎么保证数据安全传输的？

《大前端进阶 安全》系列 HTTPS详解（通俗易懂）

看完这篇 HTTPS，和面试官扯皮就没问题了

华为云申请SSL证书

浏览器如何验证HTTPS证书的合法性？

HTTPS必须在每次请求中都要先在SSL层进行握手传递秘钥吗？