HTTPS 本身不提供绝对安全，但它是当前互联网传输层最可靠的基础防护机制
HTTPS 的安全性取决于 TLS 协议实现、证书生命周期管理、密钥强度、服务端配置及客户端信任锚的完整性。它解决的是传输过程中的机密性、完整性与服务器身份认证三大问题，而非端到端全链路安全。例如，若私钥泄露、CA 被入侵、证书未及时吊销、或客户端忽略证书错误（如点击“继续访问”），HTTPS 保护即被绕过。TLS 1.3 已移除不安全协商机制（如 RSA 密钥交换、弱密码套件），但旧版本 TLS 1.0/1.1 仍存在于部分遗留系统中，构成实际风险。HTTPS 安全性不覆盖应用层漏洞（如 XSS、CSRF）、DNS 污染、BGP 劫持、终端恶意软件或社会工程攻击。浏览器对证书的验证逻辑严格遵循 RFC 5280 和 CA/B Forum Baseline Requirements，但仅当根证书预置正确、OCSP/CRL 检查启用且响应可信时，身份真实性才成立。
TLS 握手完成后的加密通道无法防止服务端明文日志记录、数据库泄露或 API 接口未鉴权等后端缺陷。
HTTPS 是必要条件，不是充分条件。
关键依赖项失效即导致 HTTPS 失效
- 私钥泄露：任何未受硬件保护（HSM/TPM）的私钥存储方式均存在被盗风险； - 证书吊销滞后：CRL 分发延迟或 OCSP Stapling 配置缺失，使已撤销证书在数小时至数天内仍被接受； - 根证书信任链污染：操作系统或浏览器信任库中混入非权威 CA（如企业中间人代理、恶意根证书）； - SNI 泄露：传统 TLS 1.2 握手中 Server Name Indication 明文传输，暴露目标域名，虽不破坏加密，但影响隐私。浏览器强制策略持续收紧
Chrome 自 2024 年起拒绝 SHA-1 签名证书；2025 年起要求所有新签发证书必须使用至少 2048 位 RSA 或 256 位 ECDSA 密钥，并启用 OCSP Stapling。Firefox 与 Safari 同步执行类似策略。不满足的站点将触发“连接不安全”警告，且不可忽略（EV 证书标识已全面移除）。| 维度 | 参考标准 | 工程师建议 |
|---|---|---|
| 协议版本 | TLS 1.3 强制启用，禁用 TLS 1.0/1.1 | 使用 OpenSSL 3.0+ 或 BoringSSL，禁用降级协商 |
| 证书类型 | CA/B Forum BR v2.8，支持自动化验证 | 优先选用 DV SSL证书 实现快速部署与自动续期 |
| 密钥管理 | RFC 8659（密钥轮换）、NIST SP 800-57 | 私钥生成于 HSM，证书有效期 ≤ 398 天（Let’s Encrypt 当前上限） |
常见问题
Q：自签名证书能否用于生产环境？ A：不能。浏览器无对应根证书，会触发硬性拦截；无法通过 CA/B Forum 合规审计，不满足 PCI DSS、GDPR 等合规要求。Q：HTTP 重定向到 HTTPS 是否足够安全？
A：不够。首次请求仍以明文发出，可能被劫持并阻止重定向（SSL Stripping）。必须启用 HSTS（Strict-Transport-Security 头），且预加载至浏览器 HSTS Preload List。
Q：CDN 后端是否需要 HTTPS？
A：需要。源站与 CDN 节点间若为 HTTP，存在中间人篡改风险；应配置私有 CA 或双向 TLS 认证。
Q：国密算法能否替代国际标准？
A：可作为补充，但不兼容主流浏览器。仅在政务、金融等明确要求 SM2/SM3/SM4 的封闭场景中独立使用，需搭配 国密SSL证书 与专用客户端。
京公网安备11010502031690号
网站经营企业工商营业执照
