HTTPS 可以理解为「在 HTTP 之下先铺好一条安全的传输通道」。 现代实践中，这条通道通常由 TLS（常被口语称作 SSL/TLS）提供：在 TCP 连接之上协商密钥、验证身份，然后才把 HTTP 请求与响应放进加密载荷里。 本文区分三道常见问题：机密性、完整性、身份验证，并说明它们各自不解决什么。

入门：HTTPS 解决了哪三类问题

  • 机密性（Confidentiality）：中间人难以读懂载荷内容；但不等于「服务器内部不可见」——服务端解密后一切与明文 HTTP 相同。
  • 完整性（Integrity）：载荷被篡改时，TLS 记录层通常会检测失败，连接报错而非静默接收错误内容。
  • 身份验证（Authentication）：客户端通过证书链验证「对方是否持有对应域名的公钥」；这是渠道身份，不等于「页面内容可信」或「用户输入合法」。

深入：TLS 握手你在排障时会遇到什么

  • 证书链不完整或过期：浏览器报证书错误；中间证书缺失、系统时间错误也是常见原因。
  • SNI 与多站点共 IP：同一 IP 上多个 HTTPS 站点依赖客户端在握手时带上 Server Name Indication；缺失或错误会导致证书不匹配。
  • 协议/cipher 不匹配：老旧客户端与仅启用 TLS 1.3 的服务端之间可能无法握手，表现为 handshake failure。

HTTPS 没有替你做的事

它不自动防 XSS、CSRF、SQL 注入——这些是应用层语义与输入校验问题； 它不保证 CDN 背后的源站配置正确； 它也不等同于「网站合法合规」——钓鱼站同样可以滥用 DV 证书。 理解边界有助于把安全预算花在正确层级。

与 HTTP、DNS 的关系

浏览器先要解析域名（见 DNS），再建立 TCP，再做 TLS，最后才发出 HTTP 请求。 任一步失败都会在开发者工具或证书界面留下不同线索。

TLS 版本、套件选择与证书策略请以 IETF TLS 相关 RFC、浏览器根证书策略及你所用服务器文档为准；厂商术语「SSL」多为历史称呼。

与其它主题的衔接

继续阅读 HTTP 状态码、Cookie 与 Session、REST。 远程登录加密类比见 SSH 密钥。