什么是 HTTPS？HTTPS 和 HTTP 到底差在哪？

什么是 HTTPS？

HTTPS（Hypertext Transfer Protocol Secure）是运行在 TLS 加密连接之上的 HTTP。它保留 HTTP 的请求与响应规则，同时用 TLS 提供加密、身份验证和完整性保护，降低网页数据被窃听、网站被冒充以及内容被篡改的风险。

HTTP 负责规定浏览器与服务器如何传输 URL、请求头、表单和网页内容；TLS 负责在这些数据进入网络前加密，并在到达连接另一端后解密。HTTPS 不是另一套网页语义，而是把 HTTP 放进一条经过认证和保护的传输通道。

一句话总结：HTTP 解决“网页数据如何传”，HTTPS 进一步解决“传输时如何避免被偷看、冒充和修改”。

HTTP 为什么不适合传输密码和隐私数据？

传统 HTTP 的核心风险是应用层内容默认以明文传输。处在传输路径上的设备或攻击者一旦能够观察流量，就可能读到请求地址、Cookie、表单内容和返回页面；若还能主动干预流量，则可能修改响应或把用户引向恶意内容。

例如，你在 HTTP 登录页面提交用户名和密码，请求可能依次经过本地网络、路由器、公共 Wi-Fi 和运营商网络。不能把“平时没人查看”当成安全保证，因为协议本身没有为内容提供机密性和完整性保护。

HTTP 的风险不只发生在咖啡店 Wi-Fi。被入侵的路由器、错误配置的代理、恶意热点，以及能够劫持网络路径的攻击者，都可能成为中间人。只要页面涉及账号、Cookie、聊天记录、验证码或支付信息，就不应通过 HTTP 传输。

HTTPS 和 HTTP 到底差在哪？

HTTPS 与 HTTP 的核心差异不在网页功能，而在连接是否经过 TLS 保护。常见端口分别是 443 和 80，但端口只是惯例，不能单独证明连接是否安全。

HTTPS 不会隐藏所有网络元数据。网络观察者通常仍能看到通信双方的 IP 地址、连接时间和流量大小；域名也可能通过 DNS 或握手信息暴露，具体取决于是否使用加密 DNS、ECH 等机制。因此，HTTPS 提供的是连接内容保护，不是匿名通信。

HTTPS 解决了哪三类风险？

HTTPS 的核心作用可以分为三类：机密性、身份验证和完整性。

1. 加密防窃听：请求和响应被加密后，截获数据包的人无法直接读取正文、Cookie 或表单内容。
2. 身份验证防假冒：浏览器验证服务器证书，确认连接的公钥与正在访问的域名之间存在可信绑定。
3. 完整性保护防篡改：现代 TLS 使用带认证的加密算法；数据被修改、伪造或破坏时，校验会失败，连接不会把它当作有效内容接受。

这三项能力缺一不可。只有加密而没有身份验证，浏览器可能与攻击者建立一条“很安全”的加密连接，然后把密码直接交给假网站；只有身份验证而没有加密，沿途设备仍然可以读取内容。

HTTPS 如何用数字证书验证网站身份？

数字证书把域名、服务器公钥、有效期和签发者等信息绑定在一起。公开网站的证书通常由证书颁发机构（Certificate Authority，CA）签发，浏览器或操作系统通过内置的根证书信任库验证证书链。

证书不是一张“网站绝对可信”的奖状。它主要证明：控制该证书私钥的一方获得了对应域名的证书，并且证书链可追溯到当前设备信任的根 CA。CA 通常验证域名控制权，不会替用户判断网站的商业行为、内容质量或是否属于钓鱼活动。

浏览器检查 HTTPS 证书时会检查什么？

浏览器会检查证书链能否连接到受信任根证书、证书是否在有效期内、访问域名是否包含在证书允许的名称中，并验证握手签名。浏览器也会结合证书状态、算法策略和本地安全规则作出判断。

常见错误包括：

• 证书过期或尚未生效：当前时间不在证书有效期内。
• 域名不匹配：证书签给 example.com，访问的却是未被覆盖的其他域名。
• 证书链不可信：缺少中间证书，或签发根不在设备的信任库中。
• 自签名证书：证书由服务器自己签发，浏览器无法从默认信任库确认其身份。
• 私钥或证书状态异常：证书被撤销、私钥泄露或使用了浏览器拒绝的旧算法。

自签名证书并不等于“没有加密”。它仍可以建立加密连接，但在没有预先分发和信任该证书的情况下，浏览器无法可靠确认对端身份，因此会警告用户。企业内网和本地开发可以使用自建 CA，但必须安全地把根证书配置到受控设备中。

TLS 握手是怎样建立加密连接的？

TLS 握手的目标不是直接传输网页，而是协商协议参数、验证服务器身份，并让双方推导出后续加密所需的会话密钥。现代网站通常使用 TLS 1.3，其完整消息比“四步法”更严谨。

一次简化的 TLS 1.3 握手可以分为四个阶段：

1. 浏览器发送 ClientHello：携带支持的 TLS 版本、密码套件、随机数和临时密钥交换参数（key share）等信息。
2. 服务器发送 ServerHello：选择 TLS 版本和密码套件，并返回自己的临时密钥交换参数。双方据此计算同一个共享秘密，再派生握手密钥。
3. 服务器证明身份：服务器发送证书链，并用证书对应的私钥对握手上下文签名。浏览器检查证书链、域名、有效期和签名。
4. 双方确认握手：双方验证 Finished 消息；通过后，再从握手秘密派生应用数据密钥，用于加密 HTTP 请求与响应。

上图把服务器的多条握手消息压缩为“ServerHello + 证书”，便于理解往返方向。按 TLS 1.3 的实际消息结构，证书和 CertificateVerify 位于 ServerHello 之后，并由已经派生出的握手密钥保护。

“公钥加密会话密钥”是哪一种握手？

“浏览器生成会话密钥，再用证书公钥加密并发给服务器”描述的是历史上 TLS 1.2 可用的 RSA 密钥交换简化模型，不是现代 TLS 1.3 的默认流程。

这张图适合理解非对称加密如何保护密钥交换，但要注意两个限制：TLS 1.3 已移除静态 RSA 密钥交换；现代握手通常使用临时（椭圆曲线）Diffie-Hellman，即 ECDHE。此时双方交换的是临时公钥参数，真正的会话密钥不会直接在网络上传输，证书私钥主要用于签名并证明服务器身份。

因此，理解现代 HTTPS 时应记住：证书用于认证，临时密钥交换用于协商秘密，密钥派生函数再生成实际的对称加密密钥。

HTTPS 为什么同时使用非对称加密和对称加密？

HTTPS 采用混合密码系统，是因为身份认证、密钥协商和大批量数据传输对算法的要求不同。

• 非对称密码机制适合身份签名和密钥协商。服务器保存私钥，对外提供证书与公钥，但相关计算成本高于对称加密。
• 对称加密适合持续传输网页数据。双方使用派生出的会话密钥，通过 AES-GCM 或 ChaCha20-Poly1305 等 AEAD 算法同时实现加密与完整性校验。
• 密钥派生函数把握手得到的共享秘密与握手上下文转换成不同方向、不同用途的密钥，避免所有阶段共用一把密钥。

所以“HTTPS 使用非对称加密”只说对了一部分。大部分 HTTP 请求和响应实际由高效的对称算法保护，非对称密码机制主要工作在身份验证和握手阶段。

什么是前向保密？

前向保密（Forward Secrecy）是指：即使服务器的长期证书私钥日后泄露，攻击者也不能仅凭这把私钥解密过去录下的会话流量。

它依赖 ECDHE 等临时密钥交换机制。每次握手都创建短期私钥，完成密钥协商后丢弃；服务器证书私钥负责为临时交换参数提供身份签名，而不是直接解开所有会话秘密。

“会话密钥每次都不同”本身并不足以保证前向保密。旧式 RSA 密钥交换虽然也会生成新的会话秘密，但攻击者如果先记录流量、以后再获得服务器私钥，就可能解开历史握手。TLS 1.3 强制采用具备前向保密能力的临时密钥交换，正是重要的安全改进之一。

HTTPS 会明显拖慢网页吗？

对大多数现代网站，HTTPS 的额外开销通常不是主要性能瓶颈。TLS 1.3 的完整首次握手通常需要一次额外往返（1-RTT），恢复已有会话时还可以减少握手成本；连接复用则会把握手成本分摊到多个请求上。

实际性能由网络延迟、服务器位置、证书链大小、连接复用、页面资源数量和缓存策略共同决定。现代 CPU 通常能高效完成 AES-GCM 或 ChaCha20-Poly1305，但高并发服务仍应监控握手 CPU、连接数和证书配置，而不是假设加密完全没有成本。

主流浏览器通常只在加密连接上启用 HTTP/2，并通过 QUIC + TLS 1.3 使用 HTTP/3。多路复用、头部压缩和更好的丢包处理可能带来更明显的收益，因此真实页面中的 HTTPS 并不必然比 HTTP 慢。

TLS 1.3 的 0-RTT 可以让恢复连接更快，但早期数据存在重放风险，不适合直接承载转账、下单等不可重复操作。性能优化不能绕过业务层的幂等与防重放设计。

地址栏有锁，就代表网站可信吗？

不代表。锁形图标或连接安全信息只说明当前浏览器与该域名之间使用了 HTTPS，并且证书验证通过；它不保证网站经营者善意、页面内容真实或下载文件安全。

钓鱼网站同样可以注册近似域名并申请免费证书。用户访问 paypa1.example 时，即使地址栏显示连接安全，证书也只是在证明连接目标确实是这个拼错的域名。

不同浏览器的界面也在变化，有些浏览器已经用“站点控制”图标代替传统小锁。可靠的判断方式是同时核对完整域名、页面来源和操作意图；遇到证书警告时，不要为了继续访问而随意选择忽略。

哪些场景必须使用 HTTPS？HTTPS 又保护不到哪里？

公开网站原则上都应默认使用 HTTPS；涉及登录、支付或个人信息时，更不应提供 HTTP 降级入口。HTTPS 的边界是浏览器与 TLS 终止点之间的传输连接，它不能代替服务器、终端和业务系统的整体安全。

必须使用 HTTPS 的典型场景包括：

• 网上银行、电商支付、证券和保险服务。
• 邮箱、社交平台、即时通信和云盘登录。
• 企业后台、管理控制台、API 和内部系统。
• 传输密码、Cookie、身份证号、银行卡号、验证码或健康数据的页面。
• 下载软件、更新包或配置文件的页面，避免内容在途中被替换。

HTTPS 不能独立解决这些问题：

结论是：**HTTPS 是网站安全的必要条件，但不是充分条件。**它解决传输链路上的主要风险，不能替代应用安全、数据安全和终端安全。

HTTPS 为什么已经从可选项变成默认项？

HTTPS 已成为现代 Web 的基础配置。浏览器会对 HTTP 页面显示“不安全”提示，Service Worker、部分设备 API 等安全上下文能力也要求 HTTPS；HTTP/2 和 HTTP/3 的主流浏览器部署同样以加密连接为主。

证书自动签发与续期降低了部署门槛，CDN、云平台和反向代理也普遍提供 HTTPS 配置。网站仍需要处理自动续期、HTTP 到 HTTPS 重定向、HSTS、混合内容和 TLS 版本等问题，不能只申请一张证书就结束维护。

对于普通用户，判断顺序应是：确认网址以 https:// 开头，核对完整域名，再查看浏览器的连接安全信息。对于网站维护者，正确目标是全站 HTTPS、禁用过时 TLS 版本、自动续期证书，并避免页面继续加载 HTTP 图片或脚本。

常见问题

HTTPS 里的 S 代表什么？

S 代表 Secure。HTTPS 的完整名称是 Hypertext Transfer Protocol Secure，它表示 HTTP 通过 TLS 安全连接传输，而不是给 HTTP 请求格式增加一个简单的加密字段。

SSL 和 TLS 有什么区别？

SSL 是 TLS 的前身。SSL 2.0 和 SSL 3.0 已被淘汰，现代 HTTPS 使用 TLS；“SSL 证书”仍是行业中的习惯叫法，实际部署的通常是供 TLS 使用的 X.509 数字证书。

HTTPS 能隐藏访问的域名和 IP 地址吗？

不能完全隐藏。目标 IP 地址通常对网络路径可见；域名可能出现在 DNS 查询或 TLS 的服务器名称信息中。加密 DNS 和 ECH 可以减少部分域名暴露，但 HTTPS 本身不是匿名工具，也不会隐藏连接时间和流量大小。

免费 HTTPS 证书安全吗？

只要证书由浏览器信任的 CA 正确签发并使用合适的 TLS 配置，免费证书与付费证书可以提供相同级别的传输加密。价格差异通常来自验证类型、服务支持、保险或管理功能，不代表付费证书使用了天然更强的会话加密。

自签名证书可以用于生产环境吗？

面向普通公众的网站通常不应直接使用自签名证书，因为访问者的浏览器默认不信任它。受控企业内网可以建立私有 CA，并把根证书安全分发到受管设备；关键是建立可验证的信任链，而不只是“有一张证书”。

HTTPS 页面为什么还会提示“不安全”？

常见原因包括证书过期、域名不匹配、证书链不完整，以及 HTTPS 页面继续加载 HTTP 脚本、图片或接口形成“混合内容”。浏览器可能直接阻止高风险混合内容，网站应把所有子资源和 API 一并迁移到 HTTPS。

总结：HTTPS 是 HTTP 加上一条经过认证的加密通道

HTTPS 是运行在 TLS 之上的 HTTP。它通过加密降低窃听风险，通过数字证书和握手签名验证服务器身份，再通过带认证的加密算法发现数据篡改。

现代 TLS 1.3 通常使用临时 ECDHE 协商共享秘密，用证书私钥证明服务器身份，再为网页数据派生高效的对称加密密钥。HTTPS 保护的是传输过程，不保证网站善意，也不能防止服务器数据库、业务代码或用户设备被攻破。

最终可以这样记：HTTP 定义通信内容，TLS 保护通信通道，HTTPS 是两者结合后的安全 Web 基础。

参考标准

• RFC 9110：HTTP Semantics
• RFC 8446：The Transport Layer Security (TLS) Protocol Version 1.3
• MDN：Transport Layer Security
• MDN：Secure contexts