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的流程
小林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 握手）。