众所周知，HTTPS 是 HTTP 安全版，HTTP 的数据以明文形式传输，而 HTTPS 使用 SSL/TLS 协议对数据进行加密，确保数据在传输过程中的安全。
那么，HTTPS 是如何做到数据加密的呢？这就需要了解 SSL/TLS 协议了。
SSL/TLS 协议
HTTPS 在 HTTP 的基础上，加入了 SSL/TLS 加密层。
SSL/TLS 协议位于应用层和传输层之间，为数据传输提供安全支持。SSL（Secure Sockets Layer）是网景公司开发的安全协议，TLS（Transport Layer Security）是 IETF 制定的新一代安全协议，TLS 是 SSL 的后续版本。
由于历史原因，虽然现在的协议版本已是 TLS，但人们依然习惯称之为 SSL，特别是在讨论 HTTPS 的安全机制时
SSL/TLS 协议负责对传输的数据进行加密，确保数据安全，那么，具体是怎么加密的呢？下面将详细介绍 SSL/TLS 握手协议中的密钥交换和建立加密通道的过程。
加密
首先，我们需要了解加密算法，加密算法分为两大类：对称加密和非对称加密。
对称加密
产生一个密钥，可以用其加密，也可以用其解密
常用算法：AES、DES、3DES、RC4、Blowfish、Twofish…
示例：
服务端生成一个 key1，第一次具体的通信之前，客户端发送请求给服务端，服务端把 key1 发给客户端，客户端保存 key1。
之后客户端发送信息给服务端就用 key1 加密。服务端收到信息后，用 key1 解密。
隐患:
如果第一次通信传输密钥时，key1 就被窃听者获取到了，后续窃听者可以用 key 解密和篡改信息。
非对称加密
产生一对密钥，公钥和私钥，公钥加密，私钥解密。公钥一般是公开的，私钥一般要保留在服务器端。
常用算法：RSA、ECC（椭圆曲线加密）、DSA、Diffie-Hellman…
示例：
服务端生成公钥和私钥，正式通信前，服务端把公钥发给 A。后续客户端使用公钥加密信息，服务端用私钥解密。
而在实际应用中，非对称加密算法通常与对称加密算法结合使用：
客户端拿到公钥 key1 后，生成一个对称加密的密钥 key2，经过公钥 key1 加密传给服务端，服务端有私钥可以解密得到 key2。
之后用 key2 加密解密传输数据。
隐患：
在最开始客户端和服务端沟通公钥 key1 时，窃听者可以保存公钥 key1，自己再生成一对 key3，把公钥 key3 给客户端。
客户端使用公钥加密 key2，但它使用的公钥是 key3，窃听者可以解密获取 key2，再把 key2 用 key1 加密给服务端。
后续通信都是由 key2 加密的，但是窃听者知道了 key2，可以对内容进行解密和篡改。
CA：证书颁发机构 Certificate Authority
要想解决上述隐患，关键是要确保获取的公钥途径是合法的，因此需要引入证书颁发机构（CA）。
先了解一些基本概念：
-
PKI (Public Key Infrastructure) 公钥基础设施
它是一个标准，在这个标准之下发展出的为了实现安全基础服务目的的技术统称为 PKI。
-
CA：(Certificate Authority) 证书颁发机构
它是一个权威的第三方机构。
-
PKI 和 CA 的关系
PKI 负责提供创建、吊销、分发以及更新密钥对与证书的服务，它需要一些证书颁发机构 CA(Certificate Authority) 才能运行。 简单的说，PKI 就是浏览器和 CA。
CA 证书颁发和使用流程
-
服务端向第三方机构 CA 提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）
-
CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
-
如信息审核通过，CA 会向申请者签发认证文件–证书。
-
客户端向服务器发出请求时，服务端返回证书文件;
证书里面包含： 服务器的地址（明文存储）、 证书颁发机构、私钥加密的公钥 key1、私钥加密的证书签名 …
由于证书中的服务器公钥 key1、证书签名是通过 CA 的私钥加密的，所以，其他终端只能通过 CA 的公钥解密读取，但无法重新加密伪造。
-
客户端读取证书中的相关的明文信息，① 采用相同的散列函数计算得到信息摘要，② 利用对应 CA 的公钥解密签名数据，③ 对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法;④ 客户端然后验证证书相关的域名信息、有效时间等信息;
-
客户端会内置信任 CA 的证书信息(包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。
证书签名
上面提到的证书签名的算法是公开的，它的目的是让拿到证书的终端可以验证证书的合法性，防止证书被篡改。
这个签名是基于证书中的内容（例如，持有者的公钥、有效期等），使用 CA 的私钥加密生成。
当其他实体（如客户端或服务器）接收到证书时，可以使用 CA 的公钥来验证签名的有效性。如果签名有效且证书内容没有被篡改，则证明该证书是由可信的 CA 签发的。
证书签名生成和验证的具体流程：
-
哈希计算：CA 使用一个哈希算法（如 SHA-256、SHA-384、SHA-512 等）对证书的内容（如公钥、证书的有效期、颁发者信息等）进行哈希运算。这样可以得到一个固定长度的摘要（即哈希值），该摘要能够唯一地表示证书的内容。
-
加密签名：CA 使用自己的私钥对该哈希值进行加密，生成数字签名。
-
最终生成的证书会包含：证书主体（包括公钥、证书的元数据等）、CA 的签名（数字签名）
-
因为算法、证书内容等信息是公开的，所以，其他终端可以使用 CA 的公钥来解密签名，然后将解密出来的哈希值，与使用算法计根据这些公开内容算出来的哈希值进行对比，如果一致，则证明证书没有被篡改，证书是合法的。
使用证书的流程
- 客户端向服务器发出请求时，服务端返回证书文件，内容包含：服务器的地址（明文存储）、证书颁发机构、私钥加密的公钥 key1、私钥加密的证书签名 …;浏览器拿到证书后会根据证书里的颁发机构信息，使用内置的 CA 公钥解密证书签名，验证证书的合法性。
- 客户端生成对称加密的密钥 key2，使用证书中的公钥 key1 加密 key2，发送给服务端，服务端用私钥解密得到 key2。之后使用 key2 加密传输数据。
如果在第一步时，证书被篡改呢？
如上图，证书被篡改后，因为公钥 key1 和证书签名是使用 CA 的私钥加密的，他们无法被篡改。其他信息被篡改后，证书签名解密出来的哈希值与计算出来的哈希值不一致，证书会被判定非法。
后续通信时，key2 因为是用公钥 key1 加密的，也始终无法被篡改。
总结： SSL/TLS 握手协议中的密钥交换和建立加密通道的过程
- 浏览器拿证书
在建立连接时，浏览器会向服务器发送请求（如 GET 请求），然后服务器会返回其 SSL/TLS 证书。这个证书包含了服务器的公钥、证书颁发机构（CA）的签名，以及其他相关信息。 - 浏览器验证证书
浏览器会检查服务器的证书是否有效，验证证书是否由可信的证书颁发机构（CA）签发，以及证书中的公钥是否匹配预期的服务器。如果证书有效，浏览器继续进行下一步；否则，浏览器会显示警告或中断连接。 - 浏览器生成对称加密密钥（key2）
浏览器会生成一个对称加密密钥（key2），通常称为会话密钥或共享密钥。这是用来加密和解密后续通信的密钥。 - 用服务器的公钥加密对称加密密钥（key2）并发送给服务器
浏览器将生成的对称加密密钥（key2）用 服务器的公钥（key1） 加密，并发送给服务器。此时，只有服务器能够使用其私钥解密获取到密钥（key2）。 - 服务器使用 key2 加密和解密数据
一旦服务器解密得到了对称加密密钥（key2），浏览器和服务器就可以使用该对称密钥（key2）来加密和解密数据。所有后续的通信数据将使用这个对称加密密钥来保护数据的机密性和完整性。