摘要：# HTTPS网站被CC攻击，为什么防护方案总“掉链子”？ 你肯定遇到过这种情况：网站明明上了高防，SSL/TLS证书也配得妥妥的，可一遇到攻击，业务还是卡成PPT。后台一看，CPU和内存都挺正常，但用户就是死活打不开页面。 这事儿我去年在帮一个电商平…

HTTPS网站被CC攻击，为什么防护方案总“掉链子”？

你肯定遇到过这种情况：网站明明上了高防，SSL/TLS证书也配得妥妥的，可一遇到攻击，业务还是卡成PPT。后台一看，CPU和内存都挺正常，但用户就是死活打不开页面。

这事儿我去年在帮一个电商平台做应急的时候，就真真切切地撞上了。他们技术负责人当时急得直挠头：“我们上了高防IP，流量都过清洗了，怎么登录接口还是崩了？”

说白了，问题就出在HTTPS协议下的SSL/TLS握手攻击上。很多防护方案，对付普通的HTTP洪水攻击还行，一碰到这种专攻握手环节的“精致”攻击，就容易露怯。

一、握手攻击：专打防护的“七寸”

咱们先抛开那些复杂的术语。你可以把HTTPS访问想象成一次秘密会谈。

普通访问（HTTP）就像在咖啡馆公开聊天，谁都能听见。而HTTPS呢，相当于双方先进入一个隔音密室（建立加密通道），再开始谈正事。进密室前，得有套复杂的“对暗号”流程——这就是SSL/TLS握手。

这套流程本身是为了安全，但它有个特点：特别耗服务器的“脑子”（CPU资源）。

一次完整的TLS握手，服务器端要做非对称解密、验证证书、生成会话密钥等等。有数据测算过，完成一次TLS握手消耗的计算资源，大约是处理普通HTTP请求的15倍以上。

攻击者就盯上了这个“软肋”。

他们不傻乎乎地猛刷页面（那种攻击容易被流量清洗识别），而是不断地发起“握手请求”，卡在最后一步之前。就像有无数人轮流去敲密室的门，对暗号对一半就跑了，让你的保安（服务器）一直忙着开门、核对、再关门，累到虚脱，根本没工夫接待真正的客人（正常用户）。

二、为什么你的防护会“失灵”？

我见过不少配置，问题往往不是没上防护，而是配错了，或者想简单了。

1. 高防IP/高防CDN的“盲区”

很多高防服务，默认的防护策略是针对HTTP流量的。当流量以HTTPS形式到达高防节点时，如果节点没有配置有效的SSL卸载或深度解密检测，它其实看不到流量里具体是什么请求。

它只能看到一堆加密的HTTPS连接请求，分不清哪个是真人想握手，哪个是攻击者在“假敲门”。为了不影响正常业务，它不敢轻易拦截，结果攻击流量就被“原样”透传到你的源站服务器了。

2. WAF的规则“滞后”

WAF（Web应用防火墙）是个好东西，但它的规则库通常是基于已知的攻击特征和业务逻辑。对于这种纯粹消耗计算资源的握手攻击，如果攻击源IP是分散的（比如来自僵尸网络），每个IP只发起少量请求，就很难触发基于频率的通用CC规则。

等WAF根据异常行为学习出规则来，你的服务器可能已经扛了十几分钟了——对电商或游戏来说，这十几分钟就是灾难。

3. 源站隐藏“白忙活”

源站隐藏是防DDoS的常见思路，把真实IP藏起来。但对付握手攻击，有时候作用有限。因为攻击者的目标可能根本不是找到你的IP进行流量轰炸，而是直接针对你已公开的业务域名（比如官网、API域名）发起连接攻击。域名总是要解析的，一解析，流量就过来了。

三、破局点：从“堵洪水”到“筛访客”

所以，防御这种攻击，思路得变。不能只想着在管道口堵大水，还得学会在门口快速分辨谁是来捣乱的。

1. 启用“SSL卸载”或“全链路HTTPS”

这是治本的方法之一。在高防或CDN节点上开启SSL卸载功能，让加密流量在防护节点上就被解密。这样，防护设备就能像分析HTTP一样，看清HTTPS流量里的具体内容（URL、参数等），从而精准识别出恶意握手请求。

当然，这对防护节点的性能要求高，而且需要你把SSL证书托管到防护平台。有些客户对证书安全有顾虑，这就需要权衡了。

2. 设置更灵活的“挑战”机制

对于突然激增的HTTPS连接请求，不能一刀切。可以在防护层面设置一个“挑战响应”。

• 首包丢弃/延迟响应： 对新建连接的第一个SYN包或Client Hello报文，随机延迟响应或丢弃一部分。真人的浏览器或APP会自动重试，而很多攻击工具缺乏完整的重试逻辑，一下就暴露了。
• JA3指纹校验： 这个有点技术含量，但很实用。TLS握手时，客户端会发送一个包含自身信息（如支持的加密套件）的“Client Hello”包。不同浏览器、APP甚至攻击工具，这个包的指纹（JA3指纹）是相对固定的。可以建立一个合法客户端的指纹库，对不匹配的、特别是大量出现的陌生指纹连接，进行严格限速或验证。

3. 源站服务器的“最后防线”优化

防护不可能100%，源站自己也得有点“自保能力”。

• 调整Web服务器参数： 比如Nginx的worker_processes、worker_connections，以及针对SSL的ssl_session_cache、ssl_session_timeout。合理设置能提升握手处理效率，并让合法用户的重复握手更快（利用会话复用）。
• 限制单IP连接数： 在服务器或前置的负载均衡器上，对单个IP地址可建立的HTTPS连接数进行限制。虽然攻击者可以用代理IP池，但能增加其成本。
• 考虑硬件加速卡： 对于计算压力特别大的业务，比如金融、游戏，可以考虑采用支持SSL硬件加速的服务器或负载均衡设备，把加密解密的计算负载从CPU上卸载掉。

四、说点大实话

最后聊点实在的。安全防护，从来不是买个盒子、开个服务就一劳永逸的。它更像是一场“攻防成本”的博弈。

攻击者的技术也在进化，专找各种协议和方案的缝隙。HTTPS下的握手攻击，就是这种“精细化”攻击的典型。

所以，如果你的业务真的重要，别再只盯着流量图表看了。定期做一次真正的“攻防演练”，模拟一下这种握手攻击，看看你的防护链条到底会在哪一环断掉。有时候，一次演练发现的问题，比看一年监控报表都有用。

防护方案PPT上吹得再猛，真到被打的时候，能扛住才是硬道理。毕竟，用户可不会听你解释“我们正在遭受一种复杂的TLS握手耗尽攻击”——他们只会觉得，你的网站，又挂了。

行了，关于这个“精致”的麻烦，今天就先聊到这。如果你也遇到过类似问题，或者有更好的野路子，欢迎聊聊。