1. HTTPS协议概述
咱们直接开始。HTTPS，全称是HTTP Over TLS，说白了就是给HTTP穿了层加密外套。我个人习惯把它理解为“安全的HTTP”。你想想看，HTTP明文传输，谁都能偷看；加了TLS之后，数据在传输过程中经过加密、完整性校验和服务端身份认证，这才叫真正能用在生产环境里的Web协议。
发展历史
HTTPS的历史并不长，但演进速度很快。我记得最早接触SSL还是在一家老牌电商公司做渗透测试，那时候网站还在用SSL 2.0，随便抓个包都能看到明文会话……嗯，那都是二十多年前的事了。
下面是HTTPS关键里程碑，我用表格梳理了一下：
| 版本 | 发布年份 | 核心变化 |
|---|---|---|
| SSL 1.0 | 1994（未公开） | Netscape内部设计，因安全缺陷从未正式发布 |
| SSL 2.0 | 1995 | 首个公开版本，但存在弱密钥、无完整性检验等严重问题 |
| SSL 3.0 | 1996 | 修复了大量漏洞，引入HMAC，成为后续基础 |
| TLS 1.0 | 1999 | IETF标准化，与SSL 3.0基本兼容但进行了强化 |
| TLS 1.1 | 2006 | 防御CBC攻击，增加隐式IV |
| TLS 1.2 | 2008 | 支持SHA-256、AEAD密码套件，至今仍在广泛使用 |
| TLS 1.3 | 2018 | 大幅简化握手、移除不安全算法、仅支持前向安全 |
一个避坑建议： 我曾经在项目中看到有人把“TLS”和“SSL”混用，部署了“SSL”配置却不知道服务端实际跑的已经是TLS 1.2。其实从TLS 1.0开始，SSL这个名称就被官方废弃了。建议你在Nginx、Apache里全部写成
ssl_protocols TLSv1.2 TLSv1.3;，别再用SSLv3了。
应用场景
现在的Web环境，HTTPS已经不是一个可选项，而是必需品。你想想看，哪些场景必须上HTTPS？
- 电商交易：信用卡号、优惠券、订单信息，泄漏一个就是事故。
- 金融业务：网银、支付接口、余额查询，明文简直是自毁长城。
- 用户登录：密码、Session 、OAuth授权码，必须全程加密。
- API接口：尤其是RESTful API和GraphQL，承载业务核心数据，不能裸奔。
- 隐私合规：GDPR、个人信息保护法等都明确要求传输加密。
其实还有一个容易被忽略的场景——中间人攻击防护。我记得有一次给一家初创公司做安全审计，他们内部CRM系统用的是自签名证书，结果员工在公司WiFi下被DNS劫持，连到了钓鱼网站，输进去的密码全丢了……这就是没有健全的CA验证导致的。所以生产环境一定要用受信任的CA签发的证书。
工作原理概述
HTTPS的核心是TLS协议。TLS工作在HTTP和TCP之间，它做三件事：身份认证、密钥协商、数据加密。
下面这张图展示了最基本的TLS 1.2握手流程（我刻意简化了一些细节，方便你快速建立整体认知）：
简单解释一下上面几个步骤：
- Client Hello：客户端告诉服务器它支持的TLS版本、密码套件、以及一个随机数。
- Server Hello + Certificate：服务器选好版本和套件，把自己的数字证书发过来（证书内含公钥）。
- Client Key Exchange：客户端验证证书后，生成预主密钥，用服务器公钥加密后发过去。
- ChangeCipherSpec + Finished：双方根据预主密钥和随机数算出会话密钥，并发送一个验证消息，确认后续通信都使用这个密钥加密。
- 加密的HTTP数据传输：握手完成，之后的HTTP请求和响应全部基于对称加密传输。
核心要点： HTTPS的握手阶段使用了非对称加密来安全交换密钥，而后续大量数据传输则采用对称加密。这样既保证了密钥分发的安全，又兼顾了性能。现在TLS 1.3把握手从2-RTT降到了1-RTT（甚至0-RTT），性能提升非常明显。
常见陷阱： 我曾经遇到过因为配置了过短的DH参数（比如1024位）导致握手非常慢且不安全的情况。现在生产环境建议至少使用2048位的DH group，或者直接用ECDHE密钥交换。另外，证书链不完整也会导致握手失败，很多开发者只上传了叶子证书，忘了中间CA，结果安卓手机上成功、苹果手机上失败……这个坑我踩过不止一次。
好了，关于HTTPS的概述就这些。记住一点：HTTPS不是银弹，它只保护传输过程，不保护服务端和客户端自身的安全。但如果没有HTTPS，整个Web安全体系就像没穿裤子的裸奔——你想想看是不是这个道理？