1. 先搞清楚HTTP 和 HTTPS 到底差在哪在聊 HTTPS 加密之前得先承认一个事实HTTP 本身不是坏东西它只是一个“裸奔”协议。你发出去的每一个字都像写在明信片上经过的每一台路由器、每一个运营商节点都能顺手看一眼甚至改一笔。登录密码、支付信息、聊天内容如果只靠 HTTP 传输等于把这些全部暴露在一条不设防的马路上。HTTPS 里的那个 S全称其实是 SSL/TLS它是一整套加密协议的统称。HTTPS HTTP TLS。TLS 帮我们解决三件事第一把内容加密让偷看的人看到的是乱码第二加完整性保护内容只要被改一个字节接收方立刻能发现第三带上身份证明确认你连的服务器是真的不是冒牌货。很多人以为官网加个 S 只是为了显得正规其实它对搜索排名有影响对登录、支付、订单这类敏感页面更是刚需。2018 年之后Chrome 直接把所有 HTTP 页面标记成了“不安全”逼着一大批网站做了整体迁移。这个过程的本质就是把原来裸奔的数据装进一个带锁的信封里。我见过不少同学分不清“加密”和“签名”的区别。加密是防止别人看懂签名是证明这东西是你写的、没被篡改过。HTTPS 协议里两个都要——加密以对称加密为主签名以非对称加密为主搭配起来才组成了完整的 TLS 流程。你可以这样理解加密等于把一封信放进保险柜签名相当于在信封上盖了带专属指纹的封泥。2. 加密的两种流派对称加密和非对称加密2.1 对称加密一把钥匙开一把锁对称加密很好理解加密和解密用的是同一把钥匙。比如你和朋友约定一个规则“每个字母往后挪 3 位”这本质就是一种最简单、最原始的对称加密。现代意义上的对称加密算法有 AES、DES、3DES其中 AES 是绝对的主流。对称加密最大的优点是快。一台普通服务器跑 AES 加解密每秒能处理几 GB 数据性能开销几乎可以忽略。但它的麻烦也很明显两个人要通信得先把这把钥匙安全送到对方手里才行。如果钥匙在传输途中被人截走那后面加密得再牢固也没用。这个问题在密码学里叫“密钥配送问题”只靠对称加密在开放的互联网上几乎无解。2.2 非对称加密一大一小两把钥匙非对称加密的原理是生成一对钥匙一把叫公钥可以公开给全世界一把叫私钥只留在自己手里。用公钥加密的东西只能用对应的私钥解开反过来用私钥加密签名的东西只能用对应公钥验证。RSA、ECC椭圆曲线密码都属于这个阵营。打个比方这就像街上放着一个信箱任何人都能往里面投信信箱口就是公钥但打开信箱取信的那把钥匙只有你一个人有那就是私钥。别人想给你传消息用你的公钥把消息一锁即使中途被截获没有你的私钥也读不了内容。非对称加密的安全性更高但代价是慢。同样加密一段数据RSA 比 AES 慢上百倍。所以真实世界里不会用非对称加密去加密所有通信数据而是走一条混合路线先用非对称加密安全地传递一个临时生成的对称密钥再用这个对称密钥去加密后续所有数据。2.3 为什么 HTTPS 两种都要这就是 HTTPS 加密的精髓所在对称加密负责“跑量”非对称加密负责“安全地分配跑量的钥匙”。TLS 握手阶段用非对称加密把会话密钥安全送到两端之后的数据全程用会话密钥做对称加密。既解决了密钥配送问题又兼顾了性能和安全。顺带提一句密钥长度不是越长越好。1024 位的 RSA 已经被认为不安全2048 位是底线关键业务普遍用 4096 位。但密钥越长握手和签名的计算开销就越大。这也是为什么现在越来越多站点转向 ECC 算法——256 位的 ECC 提供的安全强度大约等于 3072 位的 RSA握手速度却快不少。3. HTTPS 通信过程一次最简单易懂的 TLS 握手3.1 一次握手到底发生了什么当你打开浏览器访问一个 HTTPS 网站背后发生的事情可以用七步讲清楚以 TLS 1.2 为例浏览器发出 ClientHello我支持这些 TLS 版本和加密算法这是我的随机数 A。服务器回应 ServerHello好我们就用 TLS 1.2 AES_128_GCM 这套组合这是我的随机数 B这是我的数字证书。浏览器验证服务器证书。证书域名是否匹配、是否过期、签发它的 CA 是否可信任何一个环节有问题浏览器都会亮出大红屏警告。浏览器生成一个随机数 C也就是 pre-master secret用服务器证书里的公钥加密后发给服务器。服务器用自己的私钥解开拿到随机数 C。双方根据 A、B、C 三个随机数按照既定算法各自算出一个一模一样的会话密钥。从这一刻起双方用这个会话密钥做对称加密正式开始安全通信。很多人卡在第 4 步为什么还要额外用一个随机数 C因为 A 和 B 都是明文传输的不保密C 才是通过非对称加密安全传递的是真正让双方唯一共享的秘密。会话密钥由 A、B、C 共同派生任何第三者拿不到 C自然就算不出会话密钥。这里我踩过一个坑抓包工具如果想解密 HTTPS 流量必须在浏览器里提前配置信任它自己的 CA 证书否则你看到的全是密文什么有效信息都分析不出来。表面上看是抓到了流量实际上只是抓到了一个打不开的盒子。这个问题后面展开讲。3.2 TLS 1.3握手更快也更省心TLS 1.2 的完整握手需要一次往返1-RTTTLS 1.3 把流程压缩到了 0-RTT客户端在第一个包里就把自己的密钥协商参数发过去服务器直接就能算出会话密钥中间的往返省掉了。但 0-RTT 存在重放攻击风险所以只建议普通页面访问使用付款、下单、改密这类操作最好不要开。TLS 1.3 还砍掉了一批老旧加密套件RSA 密钥交换、SHA-1 这类带历史包袱的东西被直接淘汰。如果你的服务器还在用 TLS 1.2 RSA 密钥交换浏览器会不断提示“连接不够安全”。目前比较合理的配置是最低支持 TLS 1.2优先 TLS 1.3加密套件只保留 ECDHE AES_GCM 这条最稳的路。实际体验上TLS 1.3 的握手过程可以简化为两步ClientHello 带上客户端支持的密钥协商参数ServerHello 立刻返回服务器的参数和证书然后两边各自算出会话密钥不用等第二次往返。第一次连接完成后客户端还能用 session ticket 恢复会话再次访问时延迟几乎为零。4. 证书和 CA凭什么相信你连的服务器是真的4.1 数字证书里到底写了什么HTTPS 握手里有一个关键环节服务器要把自己的证书发给浏览器。证书不是一张简单的身份证而是一段结构化数据里面包含以下核心字段域名信息、服务器公钥、证书有效期、签发者 CA以及 CA 对所有这些字段的数字签名。浏览器拿到证书以后要做四件事第一检查域名是否匹配当前的访问地址第二检查有效期第三顺着证书链找到 CA 根证书第四用根证书里的公钥去验证签名是否有效。全部通过才算建立基本信任。整个过程不需要用户做任何操作浏览器自动完成。这里有一个常见误区自签名证书同样能实现加密所以有人觉得“我自己签一个证书既能练手又不用花钱”。没错技术上它能加密但浏览器不认。因为证书的信任链条靠的是 CA 背书自签名的根证书不在浏览器内置可信列表里浏览器会直接拦截。内网测试可以手动导入自签名证书到系统信任库但线上面向用户的站点绝不能这么干。4.2 证书链和中间人攻击一个完整的证书链长这样根 CA 证书 - 中间 CA 证书 - 服务器证书。浏览器只内置根 CA中间 CA 和服务器证书由站点在握手时一起发过去。如果攻击者想伪造一个正规网站的证书理论上他必须拿到根 CA 的私钥而根 CA 的私钥通常藏在离线机房甚至硬件加密机里基本不可能泄露。这就是证书体系抵抗中间人攻击的根本逻辑。中间人攻击是 HTTPS 最典型的威胁场景攻击者在你和服务器之间插了一个隐形中转站让它跟你建立 TLS同时它也跟目标服务器建立 TLS两边看起来都正常实际上数据全被它过了一道。防它的核心手段就是上面说的证书验证闭环。这也是为什么在公共 WiFi 下使用 HTTPS 依然相对安全——除非用户自己手动点了“继续访问”否则证书校验失败时几乎不可能突破。但凡事有例外。如果用户设备里被装入了攻击者控制的根证书整个信任链就崩塌了。这种手法常被企业网络审计和抓包工具使用在电脑里安装一个自己的 CA再伪装成任何网站。所以不要随便导入来路不明的根证书也别在公共电脑上轻易点“信任此证书”之类的弹窗。4.3 免费证书和付费证书怎么选Lets Encrypt 这类免费证书如今占了主流90 天自动续期个人站、中小项目完全够用。泛域名证书可以覆盖 *.example.com 下所有子域名很适合开发环境。企业对外核心服务建议上 OV 或 EV 证书这类证书不仅验证域名还验证企业资质能显著提升用户信任度。EV 证书近几年在 Chrome 里的视觉标识虽然被弱化了但审核流程和信任级别依然最高。还有几个选型上的坑值得提前知道证书续期不是“到期了再换个新的”很多老站点遇到的问题是证书本身有效但浏览器提示不受信任原因往往是证书链不完整服务器只发了叶子证书没发中间证书。排查方式是用 openssl s_client 查看实际下发的证书链必要时手动把 Intermediate 证书拼进 fullchain 再配置到服务器上。5. 实战部署与排查HTTPS 落地会踩哪些坑5.1 从零给网站加上 HTTPS以一台 Nginx 加域名已经解析好的环境为例比较省心的方案是用 acme.sh 申请 Lets Encrypt 证书curl https://get.acme.sh | sh acme.sh --issue -d example.com -d www.example.com --webroot /var/www/html acme.sh --install-cert -d example.com \ --key-file /etc/nginx/ssl/example.com.key \ --fullchain-file /etc/nginx/ssl/example.com.pem \ --reloadcmd systemctl reload nginx然后在 Nginx 配置里增加一个监听 443 的 server 块server { listen 443 ssl; server_name example.com www.example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384; }部署完成后建议再补三个动作第一配置 HSTS 响应头让浏览器强制走 HTTPS降低协议降级攻击的风险第二把 HTTP 请求 301 重定向到 HTTPS第三确认 acme.sh 的自动续期任务已经写好 cron避免证书到期后网站打不开。我最初部署时遇到过一个问题证书在浏览器抽检里明明有效但某些老设备全部提示“证书不受信任”。后来定位到是服务器下发的证书链不完整只有 leaf 证书没有中间证书。老设备不缓存中间证书直接判断链条断裂。解决办法是把 fullchain 文件按照正确顺序拼接完整确保所有中间证书都在里面。5.2 混合内容为什么页面锁头还是变灰很多站点证书配置没问题但地址栏锁头就是灰色甚至显示“不安全”罪魁祸首通常是混合内容。所谓混合内容指的是页面本身通过 HTTPS 加载但里面引用的图片、JS、CSS、iframe 仍然走 HTTP 地址。浏览器会加载部分资源但整体连接不再被视为安全页面有的浏览器会直接拦截。排查方式很简单打开浏览器开发者工具切换到 Console 或 Network 面板页面运行后会自动标出哪些请求仍是 HTTP。逐个改成 HTTPS 地址即可。如果不想一个个改源码也可以在 Nginx 配置里对响应头加上 Content-Security-Policy: upgrade-insecure-requests让浏览器自动把页面里的 HTTP 请求升级成 HTTPS。不过这种方式只能治标资源源站本身不支持 HTTPS 时仍然会加载失败。5.3 抓包与测试工具JMeter 和 Wireshark 怎么处理 HTTPS做接口测试的同学大概率绕不开这两个场景JMeter 录制 HTTPS 脚本以及 Wireshark 分析 HTTPS 流量。先说 JMeter。JMeter 作为代理捕获浏览器请求时如果目标是 HTTPS它会给浏览器颁发一个自己的证书浏览器里必须提前信任这个证书否则连接建立不起来。正确操作是在 JMeter 中配置 HTTP(S) Test Script Recorder导出它的 CA 证书到浏览器并导入到“受信任的根证书颁发机构”列表。这一步完成后录制流量才能正常否则录到的全是握手失败或错误码。再说 Wireshark。想解密 HTTPS 流量前提是必须拿到 TLS 会话密钥。Chrome 和 Firefox 支持把会话密钥导出到文件设置环境变量 SSLKEYLOGFILE 指向该文件路径Wireshark 在 Preferences - Protocols - TLS 里指定这个文件后就能看到解密后的 HTTP 明文。这是排查接口问题、分析第三方依赖请求的利器。不过这条路只对支持 SSLKEYLOGFILE 的浏览器有效。移动 App 内部发出的 HTTPS 流量在没有 root 权限或调试证书的情况下基本解不开这也是移动端抓包最头疼的地方。5.4 证书过期、时钟漂移、版本不匹配三种高频报错日常开发中HTTPS 报错最频繁的三类场景第一种是证书过期第二种是系统时钟不准导致有效期校验失败第三种是 TLS 版本不匹配导致握手失败。证书过期处理起来比较直接登录服务器检查到期时间并续期acme.sh 的 renew 命令可以一键处理。时钟漂移的问题占比不高但一旦发生很隐蔽——你在浏览器里看证书明明在有效期内访问却报错排查半天发现是电脑时间快了 5 分钟重新同步时间后立刻恢复。移动端还有缓存问题证书更新后旧会话仍在缓存里清缓存或重启应用优先级反而最高。TLS 版本不匹配常见于老系统对接新标准客户端只支持 TLS 1.0服务器只开了 TLS 1.2 以上握手直接失败。排查命令是 openssl s_client -connect domain:443 -tls1_2先看对方支持哪些协议版本再决定给服务端开启兼容版本还是让客户端升级库。类似“驱动程序无法通过使用安全套接字层(SSL)加密与 SQL Server 建立安全连接”这类报错本质上也是服务端协议版本或证书信任配置出了问题同样可以用 s_client 去对应端口探测一步步缩小范围。6. 加密算法全家桶从 AES、国密到量子加密6.1 现代密码学三件套对称算法、非对称算法、哈希聊到 HTTPS 加密背后是一整个密码学家族。对称加密里最通用的是 AESTLS 1.2 和 1.3 的加密套件里几乎都有 AES-GCM。ChaCha20 在移动端和 ARM 设备上速度更占优Google 为了照顾没有 AES 硬件加速的设备专门推过它。非对称加密方面RSA 和 ECC 平分秋色RSA 生态更成熟ECC 性能更好。哈希函数则用于证书签名和完整性校验主流是 SHA-256。类型算法典型用途现状对称加密AES数据加密TLS 通信负载主流标配对称加密SM4数据加密国内合规场景国密标准非对称加密RSA密钥交换、证书签名2048 位起步非对称加密ECC密钥交换、证书签名效率更优逐步主流摘要算法MD5完整性校验已淘汰不用于安全场景摘要算法SHA-256证书签名、指纹校验当前安全基线这里要特别提醒一句MD5 曾经非常流行但因为碰撞攻击已经被淘汰出安全体系了。现在它只适合做文件完整性校验、数据库非敏感字段的散列这类场景。凡涉及证书、签名、口令保护的场景都不要再和 MD5 沾边。6.2 国密 SM 系列国内加密生态的重要成员国内商用密码领域自有一套算法体系SM1对称硬件实现参数不公开、SM2非对称用于签名、加密、密钥交换256 位、SM3摘要输出 256 位、SM4对称分组加密128 位密钥。SM2 和 SM3 在金融、政务、央企内网里已经基本成为标配很多等保测评要求用的就是这些国密算法。但国密算法和主流开源生态的兼容性有点头疼OpenSSL 1.1.1 之后才部分支持 SM2/SM3/SM4默认还不开启。如果要在 Nginx 上启用国密双证书得使用支持国密的 OpenSSL 分支编译或者通过铜锁Tongsuo、BoringSSL 变种这类方案实现。对普通企业和个人用户来说短期内国际标准算法的证书依然是浏览器生态的主流但如果你涉及政企业务提前了解 SM2 的证书签发流程和双证书配置方法很有价值。6.3 量子计算、IBE 与 HTTPS 的未来变量量子计算对 RSA、ECC 这类非对称算法是降维打击。Shor 算法可以在多项式时间内完成大整数分解这意味着一旦大规模量子计算机成型现在基于 PKI 的整个 HTTPS 证书体系将面临崩塌。后量子密码学PQC的目标就是设计能够抵御量子攻击的新算法。NIST 在 2024 年已经发布了首批标准化算法基于格密码的 Kyber 是焦点未来几年会逐步进入 TLS 协议栈。IBEIdentity-Based Encryption基于身份的加密是另一类值得关注的非对称加密拓展。它不需要预先传输公钥直接用邮箱地址、用户名这类身份字符串派生公钥私钥由可信第三方PKG生成。这套机制在物联网、即时通信这类不便预置证书的场合很有潜力但私钥托管引入的信任风险很难回避所以大规模普及还有距离。对这些新技术建议保持关注但不要急着迁移等生态成熟后再切换更稳妥。7. 几个实操技巧和避坑备忘最后把零碎但好用的经验集中起来当成检查清单送给你这些体现的都是真实场景里的教训。第一自签名证书可以用于内网实验但别部署到线上。线上必须以受信任 CA 签发的证书为准且保证证书链完整。验证命令是 openssl s_client -connect example.com:443重点看返回的证书链里是否包含完整的中间证书。第二HSTS 要谨慎。一旦服务器返回 Strict-Transport-Security 响应头浏览器会长时间记住“该域名必须走 HTTPS”。如果站点 HTTPS 配置还不够稳定就启用 HSTS用户想降级回 HTTP 都被拦住反而容易造成访问故障。正确的做法是等 HTTPS 完全稳定运行一阵子再把 max-age 参数调上去。第三别把 HTTPS 简单看成“安全补丁”它也有性能成本。TLS 握手有往返开销图片等静态资源尽量交给 CDN 的 HTTPS 节点同时开启 HTTP/2 多路复用和 WebP 压缩能明显降低首屏延迟。TLS 1.3 的 0-RTT 虽然快但不要在资金变动、权限变更这类请求里开防重放的优先级远高于节省的那点毫秒。第四证书续期这件小事自动化程度决定安逸程度。Lets Encrypt 现在是 90 天一期acme.sh 默认自带续期任务但上线前必须确认定时任务真的在跑。千万别等到浏览器弹出红屏才去续证书——那说明真实用户已经替你踩了一遍坑了。第五遇到证书相关报错第一时间先确认时间。系统时钟差几分钟就能让一个明明在有效期内的证书变得“不可信”。在排查复杂 TLS 问题前先同步时间、清除浏览器缓存往往能省掉一大半冤枉时间。
