HTTPS
HTTP存在问题
- 数据明文传输(机密性);
- 无法实现身份验证，数据易被篡改(完整性);
网络安全3要素（重要）
机密性
- 确保信息仅被授权访问，防止未授权泄露或窃取;
完整性
- 保证数据在生成、传输、存储过程中不被篡改或破坏，维持数据的一致性与准确性;
保证 数据 不被 篡改 不被 破坏
可用性
- 保证授权用户随时、可靠的访问系统资源和服务，不会因为遭受攻击而导致服务中断，不能访问;
概述
Hypertext Transfer Protocol Secure 超文本传输安全协议。HTTPS 是 HTTP 的安全增强版本，通过在 HTTP 基础上引入加密与身份验证机制，解决了 HTTP 明文传输的安全隐患，保障数据在客户端与服务器之间的传输安全。
特征
传输基础
基于 TCP 443 端口建立连接，区别于 HTTP 的 TCP 80 端口。
协议组成
HTTPS = HTTP（超文本传输协议） + TLS（传输层安全性协议）
补充：SSL 是 TLS 的前身，目前已被 TLS 取代，日常表述中的 “SSL 证书” 实际为 TLS 证书的俗称。
核心安全能力（基于 TLS 实现）
- 身份验证：支持单向验证（仅验证服务器身份）与双向验证（同时验证客户端与服务器身份），通过证书机制确认通信主体真实身份，有效防范钓鱼站点与中间人冒充攻击。
- 传输加密：采用对称加密 + 非对称加密的混合加密机制：利用非对称加密安全协商会话密钥，再通过对称加密高效加密传输数据，全程以密文形式通信，杜绝数据窃听与明文泄露。
- 数据完整性校验：基于消息认证码、哈希算法等生成数据校验值，通信双方可实时校验数据完整性，及时发现传输过程中的篡改、伪造或丢包问题，保证收发内容完全一致。
主流版本
目前使用最广泛的版本为 TLS 1.2；TLS 1.3 凭借更高的性能和安全性，正逐步成为行业主流。
加密算法类型
对称加密
概述（重要）
- 对称加密是一种加密与解密共用同一密钥的加密技术
核心优点（重要）
- 运算效率极高：算法逻辑相对简洁，加密和解密的计算开销低，处理速度快，适合对海量数据进行加密(快)
主要缺点（重要）
- 密钥传输风险高：通信双方在共享密钥时，若采用明文传输，密钥极易被中间人窃听获取，一旦密钥泄露，所有加密数据都会被破解。
- 缺乏身份验证能力：对称加密仅能保证数据的机密性，无法验证通信双方的真实身份，存在伪装攻击的风险。
常见算法（重要）
- DES、3DES、AES、SM1等
常见算法及特点
| 算法名称 | 核心特点 | 应用现状 |
|---|---|---|
| DES（数据加密标准） | 分组加密算法，密钥长度 56 位 | 安全性已不足，已完全淘汰，仅用于历史系统兼容 |
| 3DES（三重数据加密标准） | 对数据进行 3 次 DES 加密，密钥长度 168 位 | 作为 DES 的过渡方案，安全性有所提升，但效率偏低，正逐步被取代 |
| AES（高级加密标准） | 分组加密算法，支持 128/192/256 位密钥长度，运算速度快、安全性高 | 当前主流算法，广泛用于金融、政务、通信等核心领域 |
| SM1（国产商用密码算法） | 分组加密算法，密钥长度 128 位，算法细节未公开 | 中国商用密码标准，用于涉密信息系统、金融 IC 卡等国产化场景 |
非对称加密
概述
非对称加密是一种加密与解密使用不同密钥的加密技术，这两个密钥是成对生成、彼此关联的密钥对，分别称为 公钥 和 私钥，二者具备 “公钥加密的内容，仅对应私钥可解密；私钥加密的内容，仅对应公钥可解密” 的核心特性。
密钥属性
- 公钥：可完全公开，供任意方获取和使用；
- 私钥：需由持有者严格保管，绝对不能泄露。
两大核心应用场景
- 数据安全传输：发送方用接收方的公钥加密数据，只有接收方的私钥能解密，确保数据仅目标方可见
- 数字签名与身份验证：发送方用自己的私钥加密数据摘要（即签名），接收方用发送方的公钥验证签名，可确认数据未被篡改且发送方身份真实。
数据摘要（也叫消息摘要）是原始数据通过密码学摘要算法（如 SHA-256、SM3）计算出的固定长度的唯一特征值，可以理解为原始数据的 “数字指纹”。
核心优点（重要）
- 无密钥传输泄露风险：通信双方无需传递解密用的私钥，仅需交换公钥，从根源上解决了对称加密的密钥分发安全问题。
- 支持身份验证与不可否认：通过私钥签名、公钥验签的机制，可有效验证通信主体的身份，还能防止发送方事后否认数据发送行为。
主要缺点（重要）
- 运算效率低：算法基于大数分解、椭圆曲线离散对数等复杂数学难题，加密解密的计算开销远高于对称加密，不适合海量数据的直接加密。
- 传输效率，存储效率低：非对称加密的密文长度会随明文长度增加而显著变长，进一步降低了传输和存储效率。
常见算法（重要）
- RSA(主流)、ECC、SM2等
常见算法及特点
| 算法名称 | 核心特点 | 应用现状 |
|---|---|---|
| RSA | 基于大数分解难题，密钥长度可选（2048/4096 位主流），兼容性强 | 全球应用最广泛的非对称加密算法，用于 HTTPS 密钥交换、数字签名、证书签发 |
| ECC（椭圆曲线加密） | 基于椭圆曲线离散对数难题，相同安全强度下密钥长度远短于 RSA（如 256 位 ECC≈2048 位 RSA），运算效率更高 | 移动设备、物联网、区块链等资源受限场景的首选算法 |
| SM2（国产商用密码算法） | 基于椭圆曲线算法，国密标准算法，安全性与 ECC 相当 | 中国政务、金融、国防等领域强制或推荐使用，用于身份认证、数据加密 |
注意：一对公，私钥，只能确保私钥一方的身份。私钥只有一个人有，私钥加密的信息不能伪造，公钥公开，公钥加密的信息可随意伪造。无法保证公钥加密数据的身份 。
摘要算法
概述（重要）
摘要算法是一类密码学哈希函数，能够将任意长度的输入数据（如文本、文件、二进制流），通过散列运算映射为固定长度的、唯一的摘要值（又称哈希值、消息摘要）。该摘要值可视为原始数据的 “数字指纹” ，用于快速校验数据的完整性与一致性。
核心特点
- 无密钥参与
- 不可逆性
- 固定长度输出
- 雪崩效应(原始数据哪怕仅修改 1 个比特（如将 “a” 改为 “b”），生成的摘要值会发生完全不可逆的巨大变化，这是保障数据完整性的关键特性 （唯一)
常用算法（重要）
- MD5、SHA1、SHA256、SHA384、SHA512等
常用算法及安全性说明
| 算法名称 | 摘要长度 | 安全性状态 | 适用场景 |
|---|---|---|---|
| MD5 | 128 位 32 位 | 已被破解，存在严重碰撞漏洞 | 仅用于非安全场景（如文件重复检测），禁止用于数据校验、密码存储 |
| SHA1 | 160 位 | 已被攻破，碰撞攻击可行 | 逐步淘汰，仅兼容老旧系统 |
| SHA256/SHA384/SHA512（SHA-2 系列） | 256/384/512 位 | 当前主流安全算法，无有效破解方法 | 数据完整性校验、密码存储、HTTPS 通信等核心安全场景 |
| SM3（国密算法） | 256 位 | 中国商用密码标准，安全性与 SHA256 相当 |
MD5已被破解说明：
密码学哈希函数的核心安全要求之一是 抗碰撞性—— 即很难找到两个不同的原始数据，生成相同的哈希值。
中国密码学家王小云教授团队公布了 MD5 的碰撞攻击算法，可以通过人工构造的方式，快速生成两个内容完全不同的文件，但它们的 MD5 哈希值完全一致。
MD5 的 “破解”≠ 逆向还原明文
MD5 的 不可逆性 至今没有被直接突破
它的 “破解” 是抗碰撞性失效,意味着 MD5 无法再保证 “哈希值相同 → 原始数据相同”，失去了作为安全校验的核心意义。
摘要算法与哈希算法的核心区别
摘要算法与哈希算法的本质是 “子集与全集” 的关系——所有摘要算法都是哈希算法，但并非所有哈希算法都是摘要算法，二者的核心差异在于是否具备密码学安全属性。
概念
哈希算法（Hash Algorithm）
- 是广义概念，指能将任意长度输入映射为固定长度输出（哈希值） 的一类函数的统称。
- 它的核心目标是 “快速映射” ，不强制要求安全属性，仅需满足计算高效、分布均匀即可。
摘要算法（Message Digest Algorithm）
- 是狭义概念，特指具备密码学安全特性的哈希算法，也叫密码学哈希函数。
- 它的核心目标是 “安全验证” ，在哈希算法的基础上，必须满足严格的安全要求。
哈希算法是 “大家族”，包含了所有 “映射类函数”；摘要算法是这个家族里的 “安全精英”，专门负责数据的安全验证工作。
安全通信案例(接近于实际)
服务器生成一对非对称密钥：服务器公钥、服务器私钥。
服务器将服务器公钥发送给客户端。
客户端随机生成一个对称密钥，作为本次通信的会话密钥。
客户端使用服务器公钥加密会话密钥，并发送给服务器。
服务器使用服务器私钥解密，得到会话密钥。
如果客户端需要进行数字签名，则客户端也需要提前生成一对非对称密钥：客户端公钥、客户端私钥。
客户端将自己的公钥发送给服务器。
客户端对明文计算摘要，再使用客户端私钥对摘要进行加密，生成数字签名。
客户端将“明文 + 数字签名”使用会话密钥（对称密钥）加密后，发送给服务器。
服务器使用会话密钥（对称密钥）解密，得到明文和数字签名。
服务器使用客户端公钥验证数字签名，并比对摘要。(使用公钥 解密数字签名 获得 客户端计算的摘要值)
验签通过后，可以确认数据未被篡改，且数据确实来自对应客户端。
第三人攻击(中间人)
中间人攻击的前提是：攻击者能够监听并拦截客户端与服务器之间的通信。
- 服务器把公钥发送给客户端时，被中间人拦截。
- 中间人不把真实公钥发给客户端，而是把自己的伪造公钥发给客户端。
- 客户端误以为这个公钥就是服务器的公钥，于是使用该公钥加密会话密钥。
- 中间人收到后，可以用自己的私钥解密，拿到会话密钥。
- 然后中间人再用服务器的真实公钥加密会话密钥，转发给服务器。
- 这样客户端和服务器都以为自己在安全通信，实际上所有数据都会先经过中间人。
- 中间人就可以实现数据监听、篡改、再加密转发。
中间人攻击的核心，没有对公钥提供者的身份进行验证
该攻击成立的唯一绝对前提是：客户端无法确认自己收到的公钥，是否真的来自正牌的服务器。因此，所有现代安全协议（如HTTPS/SSL/TLS）的防御都聚焦于此。
服务器不再简单地发送公钥，而是发送一个由可信证书颁发机构（CA） 签名的数字证书。
CA证书
- CA（Certificate Authority） 是受信任的第三方证书颁发机构，负责对实体身份进行审核，并签发数字证书。
- 数字证书 的本质，是由 CA 用自己的私钥签名的电子凭证，用来把“实体身份”与“公钥”绑定起来。
- 数字证书的核心作用是：认证身份、建立公钥信任、防止公钥被伪造或替换。
- 客户端通过验证证书上的 CA 签名、有效期、颁发者及主体信息，可以确认该公钥确实属于目标服务器。
CA 就是一个大家都信任的“权威机构”，专门负责给网站、服务器、用户发“身份证”。
CA证书 的核心作用，就是证明某个公钥确实属于某个网站或服务器。
CA证书的作用：证明身份，证明公钥是真的。
比如：
- 服务器说：“这是我的公钥。”
- 客户端不会直接相信。
- 服务器再拿出 CA 签发的证书。
- 客户端一验证证书，就能确认：
- 这个服务器身份是真的
- 这个公钥确实是它的，不是别人伪造的
简单比喻：
- CA = 公安局 / 权威机构
- 数字证书 = 身份证
- 公钥 = 身份信息的一部分
所以，CA证书本质上就是给公钥做担保，解决‘这个公钥到底是不是对方的’这个问题。
加密、摘要、数字证书案例
·首先搞清楚一个问题：在这个传输案例中，Alice是发送方，Bob是接收方·第一步：Alice将原始数据通过hash算法得出信息摘要，使用Alice的私钥对信息摘要进行签名得到数字签名·第二步：Alice将原始信息和数字签名和自已的证书通过对称加密算法的密钥进行加密得到加密信息·第三步：Alice使用Bob的公钥对对称密钥进行加密得到密钥信封·第四步：Alice将加密信息和密钥信封通过公网传输给Bob·第五步：Bob收到Alice发送的加密信息和密钥信封·第六步：Bob首先将密钥信封通过Bob的私钥进行解密得到对称密钥·第七步：Bob使用对称加密算法的密钥将加密信息进行解密得到原始信息、Alice的数字签名和Alice的证书·第八步：Bob使用相同的hash算法对原始信息进行计算得到信息摘要·第九步：Bob根据Alice的证书中Alice的公钥将Alice的数字签名进行解密得到Alice计算的信息摘要·第十步：Bob通过自己计算的信息摘要和Alice计算的信息摘要进行比对
TLS
第一阶段(客户端->服务器)
Client Hello 客户端发送握手消息
客户端向服务器发送：
- 随机数 M
- 自己支持的加密(对称、摘要等)套件列表
第二阶段(服务器->客户端)
Server Hello 服务器发送握手消息;
服务器向客户端发送：
- 随机数 N
- 选定的加密套件
Certificate ：服务器将证书信息发送给客户端
- 服务器把自己的数字证书发送给客户端。
作用：
- 证明服务器身份
- 让客户端拿到服务器公钥
客户端会验证：
- 证书是否由可信 CA 签发
- 证书是否过期
- 域名是否匹配
- 证书是否被吊销
Server Key Exchange
服务器产生隐藏数X，根据隐藏数生成临时公钥Pubkey(Y),将临时公钥发送给客户端
Server Hello Done 服务器告诉客户端握手报文结束；
第三阶段(客户端->服务器)
Client Key Exchange
1、客户端产生隐藏数W， 通过隐藏数W生成临时公钥Pubkey(V),并将临时公钥V发送给服务器2、 客户端: 客户端隐藏数W + 服务器临时公钥Y -> 预主密钥K
Change Cipher Spec 客户端告诉服务器改变密钥规范
客户端通知服务器：
- 后续开始使用协商出来的密钥和算法进行加密通信
客户端: 客户端随机数M + 服务器随机数N +预主密钥 ->主密钥(对称密钥)
Encrypted Handshake Message 客户端告诉服务器加密握手消息
作用：
- 证明客户端已经正确拿到了密钥
- 说明后续可以正式进入加密通信
第四阶段(服务器->客户端)
New Session Ticket 票据信息
- 客户端下次再连这个服务器时，可以把这个 ticket 带上，服务器如果认可，就可以恢复之前的会话，不用再完整走一遍握手流程。
Change Cipher Spec 服务器告诉客户端改变密钥规范
# 服务器: 服务器隐藏数X + 客户端临时公钥V -> 预主密钥K # 服务器: 服务器随机数 + 客户端的随机数 + 预主密钥 ->主密钥(对称密钥)
Encrypted Handshake Message 服务器告诉客户端加密握手消息
# 后续服务器可以使用主密钥进行数据加密传输
后续使用主密钥进行加密通话。
TLS 密钥协商核心
1. 客户端生成随机数 M，并将 M 发送至服务器。
2. 客户端将自身支持的加密套件列表（含加密算法、哈希算法等组合）发送至服务器。
3. 服务器生成随机数 N，并将 N发送至客户端。
4. 服务器根据安全性优先、兼容性次之的原则，从客户端加密套件列表中选定一套加密方案。
5. 服务器将自身的数字证书（含服务器公钥、证书颁发机构签名等信息）发送至客户端，供客户端验证服务器身份。
6. 服务器生成隐藏数 X（即密钥交换算法的私有隐藏值），基于 X和选定的加密算法生成临时公钥Y，并将 Y 发送至客户端。
7. 客户端生成隐藏数 W，基于 W 和相同加密算法生成临时公钥V，并将V 发送至服务器。
8. 客户端执行密钥计算： - 预主密钥 PMK = 基于隐藏数 W + 服务端公钥Y + 加密算法 计算得出 - 主密钥 MK = 基于客户端随机数M +服务器随机数 N +预主密钥 PMK （主密钥为后续数据传输的对称密钥）
9. 客户端使用主密钥 `MK` 对传输数据进行加密，正式开始加密通信。
10. 服务器执行密钥计算： - 预主密钥 PMK = 基于服务器隐藏数X + V 计算得出 （与客户端计算结果一致） - 主密钥 MK = 基于客户端随机数M +服务器随机数 N +预主密钥 PMK （与客户端主密钥完全相同）
11. 服务器使用主密钥 MK 对传输数据进行加密，完成双向加密通信的建立。
