HTTPS的基本理解以及加密流程
目录
HTTP 和 HTTPS的区别
HTTP的问题
HTTPS
TLS和SSL的关系
HTTPS的流程
数字证书的验证
1. 证书申请（服务端 → CA）
2. CA 签发证书
3. 客户端验证证书
4. 密钥交换与加密通信
客户端验证数字证书的具体流程
问题1：CA对服务端公钥是进行加密还是签名？
问题2: 为什么不用非对称加密传输所有数据？
为什么非对称加密比对称加密开销大？
问题3: 如何防止 CA 被篡改？
预主密钥（Pre-Master Secret）
TLS 四次握手流程（TLS1.2版本+RSA算法）
密码套件编辑
交互的包个数
消息类型
编辑
1. Client Hello
2. Server Hello
3. Certificate（证明）
4. Server Hello Done
5. Client Key Exchange（客户端密钥交换）
6. Change Cipher Spec（更改密码规范）
7. Finished
8. Change Cipher Spec
9. Finished
TLS是几次握手（不同版本）
RSA 和 ECDHE 的区别（密钥交换算法）
握手流程对比
RSA 密钥交换（TLS 1.2 示例）
ECDHE 密钥交换（TLS 1.2/1.3 示例）
总结
TLS 1.3 版本的变化
HTTP 和 HTTPS的区别
菜鸟教程：HTTP 与 HTTPS 的区别
HTTP（HyperText Transfer Protocol：超文本传输协议）和HTTPS（HyperText Transfer Protocol Secure：超文本传输安全协议）是两种用于在互联网上传输数据的协议。它们的主要区别在于数据传输的安全性。
HTTPS是在 HTTP 协议之上添加了 TLS/SSL 加密层，因此它可以与任何 HTTP 版本结合使用。
区别：
- HTTP：无加密协议。传输的数据是明文的，因此不具备保护用户隐私或防止数据被篡改的机制。如果你通过 HTTP 访问网站，所有的数据（如用户名、密码等）都可能被窃取。
- HTTPS：是基于 HTTP 协议的加密版本，它使用 SSL/TLS 加密协议（安全套接层/传输层安全协议）对数据进行加密数据，并使用数字证书进行身份验证。通过加密和身份验证机制，确保数据在传输过程中不会被窃听、篡改或伪造。
使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
- HTTP：默认使用 80 端口。
- HTTPS：默认使用 443 端口。
- HTTP：由于没有加密和解密操作，HTTP 的性能相对较高，传输速度更快。
- HTTPS：由于 SSL/TLS 加密和解密需要计算过程，HTTPS 的性能略低于 HTTP。
HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP三次握手 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议。
- HTTP：现代浏览器逐渐减少对 HTTP 的支持，谷歌等搜索引擎已经明确表示，HTTPS 会在搜索排名中获得更高的优先级。某些浏览器还会对 HTTP 网站标注“不安全”。
- HTTPS：被所有主流浏览器广泛支持，并且作为“安全”网站的标志。许多浏览器（如 Chrome）会在地址栏显示一个绿色的锁图标，表示网站是通过 HTTPS 保护的。
点击f12：（b站也有这个）
HTTP的问题
HTTP 由于是明文传输，所以安全上存在以下三个风险：
- 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
- 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
- 冒充风险，比如冒充淘宝网站，用户钱容易没。
HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。
TLS 协议是如何解决 HTTP 的风险的呢？
- 信息加密： HTTP 交互信息是被加密的，第三方就无法被窃取；
- 校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
- 身份证书：证明淘宝是真的淘宝网；
HTTPS
HTTPS（HyperText Transfer Protocol Secure）是 HTTP 的安全扩展，通过使用 TLS（Transport Layer Security）或其前身 SSL（Secure Sockets Layer）协议，加密 HTTP 的通信内容，确保数据在传输过程中的机密性和完整性。HTTPS 继承了 HTTP 的核心特性，包括 HTTP 的无状态性。
TLS和SSL的关系
- SSL（Secure Sockets Layer）：由 Netscape 公司在 1990 年代开发，包括 SSL 2.0 和 SSL 3.0，但由于严重的安全漏洞（如 POODLE 攻击），现在已被完全弃用。
- TLS（Transport Layer Security）：是 SSL 的继任者，由 IETF（互联网工程任务组）标准化，目前主流版本是 TLS 1.2 和 TLS 1.3。TLS 1.0（1999）→ TLS 1.1（2006）→ TLS 1.2（2008）→ TLS 1.3（2018）。
总结：
TLS 是 SSL 的升级版，现代网络（如 HTTPS）都使用 TLS，但习惯上仍有人称其为 "SSL 证书"。
HTTPS的流程
B站：『面试问答』：HTTPS的加密过程是怎样的？——编程十万问
B站：HTTPS是什么？加密原理和证书。SSL/TLS握手过程——技术蛋老师
小林coding：3.3 HTTPS RSA 握手解析
小林coding：3.4 HTTPS ECDHE 握手解析
HTTPS 连接建立分为两个阶段：
- TCP 三次握手：建立基础连接。
- SSL/TLS 握手：验证服务器身份和协商加密算法等参数，然后再进行数据传输。
HTTPS传输流程中包含的内容：1. 公钥证书认证：这一步的目的是为了保证客户端获得的是正确的、未被篡改的服务端公钥，防止客户端得到的服务端密钥是被中间人攻击过的2. 使用非对称加密交换对称加密的密钥3. 使用对称加密传输实际的数据
数字证书的验证
服务端获得证书、客户端校验证书流程：
1. 证书申请（服务端 → CA）
- 服务端生成密钥对：服务端先生成自己的非对称密钥对。
- 提交 CSR（证书签名请求）：服务端向CA（证书颁发机构）提交CSR（包含公钥、域名、组织信息等），不发送私钥。
2. CA 签发证书
- CA验证身份：CA通过域名所有权、企业资质等验证服务端身份。
- 生成证书：CA用自己的私钥对服务端的公钥和相关信息签名，生成数字证书。证书内容包含：服务端公钥 + 域名 + 有效期 + CA 签名。
3. 客户端验证证书
- 服务端发送证书：在 TLS 握手阶段，服务端将证书（server.crt）发送给客户端。
- 客户端验证证书链：
- 用 CA 的公钥（CA的公钥已提前设置在操作系统/浏览器中）验证证书签名是否合法。
- 检查证书是否过期、域名是否匹配、是否被吊销。若验证通过，客户端确认服务端公钥可信的，而不是中间人发送的恶意的公钥（最主要的就是证明这一步内容）。
4. 密钥交换与加密通信
- 非对称加密（仅用于密钥交换）：
- 客户端生成预主密钥（Pre-Master Secret），用服务端的公钥加密后发送。
- 服务端用自己的私钥解密获取 Pre-Master Secret。
- 对称加密（用于数据传输）：双方用 Pre-Master Secret 生成会话密钥（如 AES 密钥），后续所有数据用对称加密传输。
客户端验证数字证书的具体流程
1. 获取证书
- 客户端（如浏览器）在TLS握手时，从服务端接收到数字证书。
- 证书包含两部分：
- 明文部分：服务端的公钥、域名、有效期、颁发者（CA信息）等。
- 签名部分：CA对证书明文内容的数字签名（由CA私钥生成）。
证书是公开的：服务端公钥、域名等信息本身就是明文存储在证书中，签名只是为了证明这些内容未被篡改。
2. 重新计算哈希值
- 客户端对证书的明文部分使用相同的哈希算法（如SHA-256）计算哈希值，得到一个新的哈希结果。
3. 解密签名获取原始哈希
- 客户端使用CA的公钥（已预置在操作系统或浏览器的信任库中）解密证书的签名部分，得到CA当初生成的原始哈希值。
- 关键点：这里解密的是CA对哈希值的签名，而不是解密整个证书。
4. 比对哈希值
- 将客户端自己计算的哈希值与解密得到的原始哈希值进行比对：如果一致：说明证书内容未被篡改，且确实由该CA签发。如果不一致，证书可能被篡改或伪造，客户端会终止连接并提示风险（如浏览器显示“证书无效”）。
5. 提取服务端公钥
- 验证通过后，客户端直接从证书的明文部分获取服务端的公钥（无需从签名中还原，公钥本来就是明文存储的）。
- 该公钥将用于后续的密钥交换（如RSA加密Pre-Master Secret或ECDHE密钥协商）。
总结：
问题1：CA对服务端公钥是进行加密还是签名？
CA 对服务端的公钥做的事是签名，而不是加密。CA 的签名是为了防篡改（验证证书完整性），而非保密。服务端公钥本就是公开的，无需加密。
注意：签名和加密是两回事
| 特性 | 签名（Signing） | 加密（Encryption） | |
| 目的 | 验证数据的完整性和来源真实性（防篡改、防伪造）。 | 保护数据的机密性（防止泄露）。 | |
| 操作方 | 用私钥生成签名，用公钥验证签名。 | 用公钥加密数据，用私钥解密数据。 | |
| 数学过程 | 对数据哈希值用私钥计算签名（非对称算法）。 | 用公钥加密原始数据（非对称算法或混合加密）。 | |
| 典型应用 | 数字证书、代码签名、区块链交易。 | HTTPS会话密钥交换、加密通信内容。 |
问题2: 为什么不用非对称加密传输所有数据？
非对称加密（如 RSA）计算开销大，对称加密（如 AES）速度快 1000 倍以上。
为什么非对称加密比对称加密开销大？
- 数学运算复杂：非对称加密（如RSA、ECC）基于大数分解、离散对数等复杂数学问题，计算量远超对称加密（如AES）的简单位运算。
- 密钥长度差异：非对称加密需更长的密钥保证安全（如RSA-2048位），而对称加密仅需256位即可达到相同安全强度，处理的数据量更小。
- 功能定位不同：非对称加密专用于密钥交换和身份认证（如TLS握手），而对称加密专注高效数据加密，两者分工明确。
问题3: 如何防止 CA 被篡改？
CA 的公钥提前预埋在操作系统/浏览器中。
预主密钥（Pre-Master Secret）
预主密钥是 TLS 握手过程中由客户端生成的一个临时随机数，用于最终生成对称加密的会话密钥。它是 TLS 安全通信的核心，但本身并不是直接用于加密数据的密钥，而是生成主密钥（Master Secret）的“种子”。
核心目的：通过动态生成的临时密钥，确保每次会话（一次会话包含多次数据交换）的加密密钥独立，即使攻击者拿到服务器的长期私钥，也无法解密过去的通信。
预主密钥的生成与使用流程：
目的：在客户端和服务端之间安全协商出一个共享密钥（对称加密密钥），用于后续通信加密。
预主密钥不是对称密钥，而是生成对称密钥的原材料。它通过非对称加密（如 RSA 或 ECDHE）安全传输，确保只有服务端能解密。
- 客户端生成预主密钥
在 TLS 握手期间，客户端随机生成一个 48 字节的预主密钥（TLS 1.2 标准）。
每个会话的预主密钥都不同，防止即使长期私钥泄露后，历史通信仍可被解密
2. 客户端加密并发送预主密钥
客户端用服务端的公钥（来自证书）加密 Pre-Master Secret，发送给服务端。
3. 服务端解密预主密钥
服务端用自己的私钥解密获取 Pre-Master Secret。
4. 生成主密钥（Master Secret）
客户端和服务端各自用之前的三个随机数生成相同的会话密钥：Client Random、Server Random、Pre-Master Secret（前两个是握手阶段交换的随机数）
客户端和服务器各自独立使用以下三个输入，通过 PRF（伪随机函数，如 TLS 1.2 的 PRF-SHA256） 计算会话密钥：
Master Secret = PRF( Pre-Master Secret, "master secret", Client Random + Server Random )
- 输入顺序和标签固定：字符串 "master secret" 是固定的标签，确保会话密钥的生成过程一致。
- 结果唯一性：只要三个随机数相同，双方计算出的会话密钥必然相同。
为什么每次会话的预主密钥都不同？
前向安全性（Forward Secrecy）：如果预主密钥是固定的或可预测的，攻击者截获历史通信并事后破解服务器的私钥后，就能解密所有过去的会话。
动态生成：每次 TLS 握手时，客户端都会随机生成一个新的预主密钥（例如通过安全的伪随机数生成器 CSPRNG），确保不同会话的密钥完全独立。
TLS 四次握手流程（TLS1.2版本+RSA算法）
TLSv1.2 握手过程基本都是需要四次，也就是需要经过 2-RTT 才能完成握手，然后才能发送请求，而 TLSv1.3 只需要 1-RTT 就能完成 TLS 握手。
完整的流程图：
TLS1.2四次握手：
- 客户端发送 Client Hello：请求建立TLS连接，并发送支持的TLS协议版本、一个随机数、支持的加密方法列表。
- 服务端收到消息后，回应 Server Hello：确认使用的TLS版本、一个随机数、加密方法、服务器的公钥数字证书。
- 客户端收到服务端回应后，验证数字证书是否合法，如果证书受信任，或者用户接受该不受信的证书，客户端生成一个48字节的随机数作为预主密钥，并用证书中的提供的服务器公钥加密，发送给服务器。同时客户端还会发送握手结束通知，通知消息中会把之前所有内容数据做一个摘要，用来供服务端检验。
客户端会根据这三个随机数通过算法生成会话密钥，这个会话密钥就是双方接下来进行对称加密的密钥。
三个随机数的比较：
| 随机数 | 生成方 | 传递阶段 | 长度 | 作用 |
| Client Random | 客户端 | Client Hello（明文） | 32字节 | 参与主密钥计算，防止重放攻击。 |
| Server Random | 服务端 | Server Hello（明文） | 32字节 | 参与主密钥计算，增强随机性。 |
| Pre-Master Secret | 客户端 | Client Key Exchange（加密） | 48字节 | 密钥材料的核心来源。 |
4. 服务端收到客户端的回复后，通过协商的加密算法将客户端发送过来的随机数解密出来，然后使用和客户端同样的算法，根据签名的三个随机数计算出会话密钥。同时，服务端也会发送握手结束通知，通知消息中会把之前所有内容的数据做一个摘要，用来供客户端检验。至此，整个握手阶段全部结束。
接下来客户端和服务端使用生成的同一个会话密钥进行普通的HTTP通信，只不过，用会话密钥把发送的信息进行对称加密。
简短总结，以 TLS 1.2 + RSA 密钥交换为例：
- 客户端发送Client Hello：支持的版本、随机数、加密套件
- 服务端发送Server Hello：确认版本、随机数、数字证书、选择的加密套件
- 客户端发送 Finished：计算主密钥 → 派生会话密钥 → 加密 Finished 消息（包含握手摘要）。
客户端验证证书：检查 CA 签名、域名、有效期等。若合法，生成 Pre-Master Secret，用服务器公钥加密后通过 Client Key Exchange 发送。
4. 服务端解密 Pre-Master Secret，生成相同主密钥和会话密钥，验证 Finished 后回复自己的 Finished。
TLS 1.3 和 TLS1.2 相比的区别：
- 无 RSA 密钥交换：Pre-Master Secret 通过 ECDHE 临时参数计算，无需加密传输。
- 合并消息：Server Hello 可能直接附带 Finished，减少交互次数（1-RTT）。
整体来看，SSL/TLS工作流程通过四个方式保证安全性：
- 通过CA证书体系交换服务器的公钥来验证服务器的合法性。通过数字签名，确保数据的完整性，防止数据被篡改
- 通过非对称加密算法，交换用于对称加密的会话密钥，保证密钥的安全传输
- 通过对称加密算法，加密HTTP的数据进行正常的网络通信
密码套件
交互的包个数
标准 TLS 1.2 握手（RSA 密钥：RSA 非对称加密的密钥对）：
完整流程：4 次交互，2 RTT
| 步骤 | 方向 | 发送的消息类型 | 包数量 | |
| 第一次交互 | 客户端 → 服务端 | Client Hello | 1 个包 | |
| 第二次交互 | 服务端 → 客户端 | Server Hello、 Certificate、 Server Hello Done | 1 个包（合并发送） | |
| 第三次交互 | 客户端 → 服务端 | Client Key Exchange、Change Cipher Spec、Finished | 1 个包（合并发送） | |
| 第四次交互 | 服务端 → 客户端 | Change Cipher Spec、Finished | 1 个包（合并发送） |
TLS握手的过程中，发送的总包数是4个：4 个网络包（客户端和服务端各发送 2 次，每次可能合并多个消息）。
合并发送：TLS 允许将多个消息合并到一个 TCP 包中发送（如服务端将 Server Hello、Certificate、Server Hello Done 合并为 1 个包）。
消息类型
1. Client Hello
- 发送方：客户端
- 作用：发起 TLS 握手，声明支持的加密参数。
- 包含内容：
- TLS 版本（如 TLS 1.2）。
- 随机数（Client Random，32 字节）。
- 支持的加密套件列表（如 AES256-GCM-SHA384）。
- 其他扩展（如 SNI 域名、支持的椭圆曲线等）。
2. Server Hello
- 发送方：服务端
- 作用：确认加密参数，返回协商结果。
- 包含内容：
- 选择的 TLS 版本和加密套件。
- 随机数（Server Random，32 字节）。
- 会话 ID（用于会话恢复）。
- 其他扩展（如选中的椭圆曲线）。
3. Certificate（证明）
- 发送方：服务端
- 作用：向客户端发送服务器的数字证书，证明身份。
- 包含内容：
- 服务器的公钥证书链（从叶子证书到中间 CA，可能包含根证书）。
- 证书中的公钥用于后续密钥交换（如 RSA 公钥加密 Pre-Master Secret）。
服务端证书包含的公钥主要用于以下场景：
- RSA 密钥交换：客户端用该公钥加密 Pre-Master Secret。
- ECDHE 密钥交换：公钥仅用于验证签名（若证书使用 RSA/ECDSA 签名），密钥交换本身通过临时椭圆曲线参数完成。
4. Server Hello Done
- 发送方：服务端
- 作用：通知客户端“服务端握手消息已发送完毕”。
- 关键点：
- 这是一个空消息，仅作为标志位。
- 客户端收到后开始验证证书并准备密钥交换。
5. Client Key Exchange（客户端密钥交换）
- 发送方：客户端
- 作用：传递密钥交换所需信息（具体内容取决于加密套件）。
- 典型场景：
- RSA 密钥交换：发送用服务器公钥加密的 Pre-Master Secret（48 字节随机数）。
- ECDHE 密钥交换：发送客户端的临时椭圆曲线公钥参数。
6. Change Cipher Spec（更改密码规范）
- 发送方：客户端
- 作用：通知服务端“后续消息将使用协商的会话密钥加密”。
- 关键点：
- 这是一个独立于握手协议的消息（属于 Change Cipher Spec 协议）。
- 之后客户端发送的 Finished 消息会被加密。
7. Finished
- 发送方：客户端
- 作用：验证握手过程完整性，确认密钥正确性。
- 包含内容：
- 所有之前握手消息的摘要（HMAC 值）。
- 首次加密消息：用协商的会话密钥加密。
- 安全意义：若服务端能解密并验证此消息，说明密钥一致且握手未被篡改。
8. Change Cipher Spec
- 发送方：服务端
- 作用：通知客户端“后续消息将使用会话密钥加密”。
- 对称性：与服务端的 Finished 消息配套出现。
9. Finished
- 发送方：服务端
- 作用：服务端对握手完整性的最终确认。
- 包含内容：
- 所有握手消息的摘要（HMAC）。
- 用会话密钥加密，客户端解密验证后完成握手。
TLS是几次握手（不同版本）
TLS 握手的次数取决于协议版本和密钥交换方式，不同版本的 TLS 握手流程差异较大。
RSA 和 ECDHE 的区别（密钥交换算法）
密钥交换算法，因为考虑到性能的问题，所以双方在加密通信数据时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。
TLS 握手过程中，RSA 和 ECDHE（Elliptic Curve Diffie-Hellman Ephemeral） 是两种不同的密钥交换机制，它们在安全性、性能和前向保密性（Forward Secrecy）上有显著区别。
密钥交换算法的核心目标是：让通信双方在不安全的网络中，安全地协商出一个共享的密钥（通常用于后续对称加密）
握手流程对比
RSA 密钥交换（TLS 1.2 示例）
- 客户端发送 ClientHello（支持的密码套件，如TLS_RSA_WITH_AES_128_GCM_SHA256）。
- 服务器回复 ServerHello + RSA 公钥证书。
- 客户端生成预主密钥（Pre-Master Secret），用服务器公钥加密后发送。
- 服务器用 RSA 私钥解密获取预主密钥。
- 双方根据预主密钥生成会话密钥。
问题：
- 若服务器私钥泄露，所有历史通信可被解密（无前向保密性）。
- RSA 加解密计算成本高（尤其是 2048-bit 以上密钥）。
ECDHE 密钥交换（TLS 1.2/1.3 示例）
- 客户端发送 ClientHello（支持 ECDHE 套件，如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）。
- 服务器回复 ServerHello + 证书 + ECDHE 参数（椭圆曲线、临时公钥）。
- 客户端生成临时 ECDHE 公钥，发送给服务器。
- 双方通过椭圆曲线迪菲-赫尔曼算法计算共享密钥（无需加密传输）。
- 基于共享密钥生成会话密钥。
优势：
- 前向保密性：临时密钥（Ephemeral）用完即弃，即使服务器私钥泄露，历史会话仍安全。
- 性能更高：256-bit ECC 安全性 ≈ 3072-bit RSA，但计算量更小。
TLS 1.3 中 ECDHE 密钥交换的完整流程（没细看）：
TLS 1.3 对密钥交换进行了大幅简化，仅支持前向保密的密钥交换算法（如 ECDHE），并实现了 1-RTT（单次往返）握手。以下是详细流程：
总结
| 特性 | RSA 密钥交换 | ECDHE 密钥交换 |
| 密钥交换原理 | 客户端用服务器公钥加密预主密钥 | 通过椭圆曲线迪菲-赫尔曼临时交换生成共享密钥 |
| 前向保密性 | 不支持 | 支持（每次会话生成临时密钥） |
| 计算性能 | 服务器解密开销大（非对称计算） | 更快（椭圆曲线计算效率高于 RSA） |
| 密钥长度安全性 | 2048-bit RSA ≈ 112-bit 安全性 | 256-bit ECDHE ≈ 128-bit 安全性 |
| TLS 1.3 支持 | 已废弃 | 唯一支持的密钥交换方式 |
前向保密性（Forward Secrecy）：RSA：预主密钥由服务器公钥加密，一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法ECDHE：每次会话生成临时密钥，共享密钥不依赖服务器私钥，即使私钥泄露，历史会话仍安全密钥交换：RSA：用证书公钥加密 Pre-Master Secret。ECDHE：证书公钥仅用于身份认证，临时密钥单独交换。
TLS 1.3 版本的变化
- 废除 RSA 密钥交换：TLS 1.3 仅支持前向保密的密钥交换（如 ECDHE）。
- 简化握手：ECDHE 参数在首轮交互中传递，减少 RTT（1-RTT 握手）。