基础问答

问：HTTP 和 HTTPS 有什么区别？

答：1. HTTPS 是 HTTP + SSL/TLS 协议的一个组合，使用 SSL/TLS 加密，相对更安全。2. 端口使用不同，HTTP 使用 80 端口，HTTPS 使用 443 端口。3. HTTPS 由于加密设计需要多次握手，HTTP 则没有这个问题，性能相对更高。4. HTTPS 需要 SSL 证书。5. HTTP 明文传输，HTTPS 加密传输。

‍

扩展延伸

HTTPS 的本质实际上可以概括为："HTTP over TLS/SSL"，通过加密和认证，解决了 HTTP 存在的窃听，篡改，冒充的问题。

加密

HTTPS 的加密机制是对称加密和非对称加密组合。

非对称加密：在 HTTPS 握手阶段，使用公钥加密，私钥解密，处理好密钥协商的问题，客户端从 SSL 证书中获取服务器公钥，将随机生成的对话密钥加密后发送给服务器，服务器使用私钥解密后便可以得到会话密钥。
对称加密：在数据的传输阶段，使用握手阶段协商的密钥加密传输数据。

对于 TLS1.3 来说，简化了握手的流程，只需要 1RTT（往返时间）即可完成密钥的协商，比 TLS1.2 更高效（TLS1.2 是 2RTT）

‍

加密算法

HTTP 本身无加密机制，但在与 TLS 结合形成 HTTPS 后，会依赖一些加密算法保障安全，这里提供一些典型的加密算法：

非对称加密算法
- AES：目前 HTTPS 主流算法，支持 128 位、256 位密钥长度，安全性高且性能优，TLS1.2/1.3 均默认推荐（如 AES-GCM 模式）
- DES：早期算法，仅 56 位密钥，安全性极低，目前已被禁用
- 3DES：对 DES 的改进，通过三次加密提升安全性，但密钥长度仍有限（112 位），性能低于 AES，仅用于兼容老旧系统。
对称加密算法
- RSA：应用最广泛的非对称算法，支持 1024 位、2048 位、4096 位密钥，用于 HTTPS 握手阶段的预主密钥加密（服务器公钥加密），但计算开销较大，TLS1.3 中逐渐被更高效的算法替代。
- ECC：椭圆曲线加密，TLS1.3 推荐算法，相同安全性下密钥长度远小于 RSA（如 256 位 ECC 安全性≈3072 位 RSA），计算速度快，适合移动设备、物联网等资源受限场景（常见如 secp256r1、secp256k1 曲线）。
- DSA：仅用于数字签名（如证书签名），不支持数据加密，应用场景较窄，目前已被 ECC 和 RSA 替代。

‍

摘要算法

数字摘要，实际就是一个哈希算法，通过对数据计算生成固定长度的摘要值，用于验证数据是否被篡改，应用场景十分广泛，如果你在开源项目看的多，会发现很多开源的项目在提供文件下载的同时，会提供一个哈希值，如 sha256 等等，提供给用户用于校验文件是否在分发过程中被篡改。

这种算法无法通过摘要值反推内容，不同的原始数据生成的哈希值基本不可能相同，而且长度固定，也就是所谓的单向、唯一、定长。

常见算法有：

MD5：生成 128 位摘要，早期用于文件校验（如 HTTP 静态资源校验），但存在碰撞漏洞 （不同数据可生成相同 MD5），目前仅用于非安全场景（如文件唯一标识），禁止用于密码存储、数据加密校验。
SHA-1：生成 160 位摘要，安全性高于 MD5，但 2017 年被证实存在碰撞风险，TLS1.3 已禁用 SHA-1，目前仅用于老旧系统兼容（如早期 SSL 证书签名）。
SHA-2 系列：目前主流安全算法，包括 SHA-256（256 位摘要）、SHA-384（384 位摘要）、SHA-512（512 位摘要），抗碰撞性强，用于 HTTPS 证书签名（如 EV 证书采用 SHA-256 签名）、TLS 握手阶段的 "Finished" 消息校验、HTTP 静态资源完整性校验（如 HTML 中 <link rel\="stylesheet" href\="style.css" integrity\="sha256-xxx">）。
SHA-3 系列：SHA-2 的补充算法，采用全新算法结构，安全性更高，但目前应用较少，主要用于对安全性要求极高的场景（如金融级数据校验）。

在 HTTP 场景中主要有以下几个应用：

静态资源完整性校验：前端引入 HTTP/HTTPS 资源时，通过 integrity 属性指定资源的摘要值（如 SHA-256），浏览器下载后计算摘要值对比，不一致则拒绝加载（防范 CDN 劫持、资源篡改）；
API 接口签名：后端接口要求客户端对请求参数（如时间戳、参数值）计算摘要（如 SHA-256+HMAC），服务器接收后重新计算摘要对比，验证请求是否被篡改、是否为合法客户端发送；
HTTPS 证书校验：CA 机构颁发证书时，用自身私钥对证书内容 + 摘要算法（如 SHA-256）签名，客户端验证时用 CA 公钥解密签名，再对证书内容计算摘要，对比是否一致（确认证书未被篡改）。

‍

HTTPS 完整握手流程

客户端发送 Client Hello 消息：这套消息包含支持的 TLS 版本、加密信息、一个随机数 A
服务端回应 Server Hello 消息：确认 TLS 版本、加密信息、一个随机数 B 和 SSL 证书
客户端验证证书：客户端通过 CA 公钥验证证书合法性，这一步防范的是中间人伪造，同时这一步先生成预主密钥（premaster secret），然后用服务器公钥加密后发送给服务器。
服务器解密预主密钥（premaster secret）：用私钥解密得到密钥，结合随机数 A、B，生成会话密钥，用于后续的对称加密。
双方确认加密通道：客户端和服务器分别用会话密钥加密 "Finished" 消息，确认对方能正常解密，握手完成。
数据传输：后续所有 HTTP 请求 / 响应均用会话密钥加密传输

‍

面试追问

HTTPS 为什么需要证书？

核心的目的是防范中间人攻击，如果没有 CA 证书，中间人就可以伪造证书发送给客户端，在客户端一侧无法分清真假，就会出现将加密后的会话密钥发送给中间人。而 CA证书是由权威机构颁发的，包含了服务器的公钥和机构的签名，客户端可以通过本地内置的 CA 根证书来验证签名，确认服务器身份。
HTTPS 有什么性能优化的方式？
1. 协议优化：使用 TLS 1.3 减少握手次数，同时在无需兼容的时候，禁用老的加密套件
2. 证书优化：使用 EV 证书增强信任或多域名证书减少证书数量，开启 OCSP Stapling 避免客户端单独查询证书吊销状态
3. 连接优化：使用 HTTP/2 ，利用多路复用减少连接数，启用 Session Resumption 复用会话，避免重复握手
HTTPS 虽然安全，但是我的网站只是个静态网站，使用 HTTP 是不是就行了？

理论上是这样，可以不需要 HTTPS，但是目前搜索引擎会优先收录 HTTPS 站点，会影响我们站点的 SEO，其次目前主流浏览器对于 HTTP 站点会标记不安全，对于用户来说，这一个不安全提示可能会直接导致站点流量大量回落。所以除非是内部的一些无敏感信息的站点，只要对外的站点，尽可能都使用 HTTPS。
为什么不能用 MD5 加密密码？

因为存在漏洞，一段 MD5 可能有不同的内容，对于攻击方，可以通过明文不同但是 MD5 相同的密码来绕过验证，而且破解的成本相对来说比较低，可以直接用彩虹表来快速破解。