HTTPS（上）：对称、非对称、哈希、签名与一次 TLS 握手
不堆数学公式，讲清 HTTPS 要解决的三个威胁和四块密码学积木，再一步步拆解 TLS 握手如何用非对称加密安全地协商出对称会话密钥，以及 CA 证书链为什么能防中间人
- 理解明文 HTTP 的三大风险：窃听、篡改、冒充
- 分清对称加密、非对称加密、哈希、数字签名各自解决什么问题
- 理解 CA 与证书链的信任机制，看懂一张证书里有什么
- 能复述 TLS 握手如何兼顾安全与性能（非对称协商、对称通信）
HTTPS 不是「更高级的 HTTP」，是加密的 HTTP
HTTP 默认明文传输：数据在网络上一跳跳经过运营商、路由器、公共 Wi-Fi，任何一个中间环节都能偷看（窃听）、塞广告改内容（篡改）、伪装成银行网站（冒充）。HTTPS = HTTP over TLS，在 HTTP 和 TCP 之间加一层加密通道，同时解决三件事：保密性（别人看不懂）、完整性（改了能发现）、身份认证（你连的确实是这个网站、不是钓鱼）。要理解它怎么做到，先认识四块密码学积木。
四块密码学积木，各管一件事
对称加密快但有个鸡生蛋问题：通信前双方得先有同一把密钥，可密钥怎么安全地传给对方？直接在不安全网络上发密钥，等于没加密。非对称加密解决了分发问题：公钥可以公开，用公钥加密的内容只有对应私钥能解，但它计算慢、不适合加密大量数据。真实的 HTTPS 把两者结合：用非对称加密安全地「协商」出一把对称会话密钥，之后全程用这把对称密钥高速通信——各取所长。哈希则像文件指纹，数据改一个比特指纹就完全不同，用来发现篡改；数字签名是「私钥加密指纹、公钥可验证」，证明发送者身份和内容完整。
问题来了：你怎么知道公钥真的是网站的
假设你连 pygood.com，对方发来一把公钥，你怎么确认它不是中间人伪造的？如果攻击者在你和网站之间各扮演一次对方（中间人攻击 MITM），他可以给你他自己的公钥、冒充网站。解决办法是引入可信第三方——证书颁发机构 CA（Certificate Authority）。网站把自己的公钥和域名等信息交给受信任的 CA，CA 核验域名归属后用自己的私钥签名，生成一张数字证书。你的设备/浏览器内置了全球根 CA 的公钥，能用它逐级验证证书签名，伪造者拿不到 CA 私钥就签不出以假乱真的证书。
证书链（信任从根逐级传导）
根 CA（操作系统/浏览器内置，自带信任，自签名）
└─ 中间 CA（由根 CA 签名）
└─ 站点证书 pygood.com（由中间 CA 签名，含网站公钥/域名/有效期）
浏览器从站点证书一路验签到内置根 CA，任一环对不上就告警「连接不安全」站点证书主要包含：证书对应的域名（含 SAN 主体备用名，可列多个域名）、网站公钥、颁发者（哪个 CA）、有效期起止、签名算法与 CA 的签名。浏览器校验四件事：签名链能否追溯到信任根、访问的域名是否在证书范围内、证书是否在有效期内、证书是否被吊销（CRL/OCSP）。任何一项不过都会弹安全警告。
一次 TLS 握手在做什么
建立 HTTPS 连接时，在 TCP 三次握手之上还要进行 TLS 握手，目的是「认证服务器 + 安全协商出一把只有双方知道的会话密钥」，简化过程如下：
客户端 -> 服务器 : ClientHello（支持的 TLS 版本、加密套件、随机数A）
服务器 -> 客户端 : ServerHello（选定套件、随机数B）+ 站点证书链
客户端 : 用内置 CA 公钥验证证书真伪、校验域名与有效期
客户端 -> 服务器 : 用证书公钥加密「预主密钥」发出（或 ECDHE 交换参数）
双方 : 各用随机数A/B+预主密钥，算出相同的会话密钥
客户端 <-> 服务器: 之后全部用这把对称密钥加密通信（Application Data）现代 TLS（1.2/1.3）普遍用 ECDHE 做密钥协商，它带来一个重要性质叫前向保密：即使将来服务器长期私钥泄露，也解不开过去录制下来的会话，因为每次会话的对称密钥都是临时协商、用完即弃。TLS 1.3 还把握手压缩到 1-RTT、并砍掉了老旧不安全的算法，所以部署时应只保留 TLS1.2/1.3。
为什么 HTTPS 还要 TCP 握手，不是多了一两趟吗（选学）
TCP 三次握手建立的是「可靠字节通道」，TLS 握手建立的是「在这条通道之上的加密信任」，职责不同、缺一不可：没有 TCP 就无法可靠传 TLS 报文，没有 TLS 通道就是明文。为减少往返开销，TLS1.3 支持 1-RTT 甚至会话恢复的 0-RTT（0-RTT 有重放风险、只适合幂等读请求）；HTTP/2、HTTP/3 进一步复用连接、合并握手。理解这些开销，就理解了为什么连接复用（keep-alive）和长连接对移动端体验如此重要。
开发时可以用 openssl 生成「自签名证书」临时启用 HTTPS，但它没有可信 CA 背书，用户浏览器/App 会直接报「不受信任」。生产环境必须用受信任 CA 签发的证书（免费的 Let's Encrypt 即可，下一课讲），绝不能让正式用户点「继续访问不安全网站」。
HTTPS 在传大量业务数据时主要使用对称加密，而用非对称加密来协商会话密钥，主要原因是？
本节小结
HTTPS=HTTP over TLS，解决保密性、完整性、身份认证。四块积木：对称加密(AES)一把密钥快、适合大数据；非对称(RSA/ECC)公私钥对、解决密钥分发但慢；哈希(SHA-256)单向指纹验完整；数字签名私钥签公钥验、证身份与未篡改。公钥可信靠 CA：站点证书由中间CA、根CA逐级签名成证书链，设备内置根CA公钥验签，防中间人；证书含域名(SAN)/公钥/颁发者/有效期/签名，校验签名链、域名、有效期、吊销。TLS握手在TCP之上认证服务器并用非对称/ECDHE协商对称会话密钥，之后对称加密通信，ECDHE提供前向保密，生产只留TLS1.2/1.3。自签名证书仅测试用。
资深工程师加餐
底层原理 · 大厂视角 · 工程经验，点卡片展开
从浏览器到你的应用，一次请求依次经过 DNS 解析、TCP 三次握手、TLS 握手、反向代理、上游应用，再到数据库或缓存，沿原路返回。每一跳都可能是延迟或故障点，所以排错要分层推进：先确认域名解析和端口连通，再看证书是否有效，最后看应用日志与依赖，而不是出问题就先重启。能把链路一层层说清，定位线上故障会快一个数量级。