https ddos攻击——由于有了认证和加解密 后果更严重 看绿盟的产品目前对于https的ddos cc攻击需要基于内容做检测
如果web服务器支持HTTPS,那么进行HTTPS洪水攻击是更为有效的一种攻击方式，一方面，在进行HTTPS通信时，web服务器需要消耗更多的资源用来进行认证和加解密，另一方面，一部分的防护设备无法对HTTPS通信数据流进行处理，也会导致攻击流量绕过防护设备，直接对web服务器造成攻击。
HTTPS的DDoS攻击防护
随着越来越多的网络业务由明文HTTP转向加密HTTPS协议，针对HTTPS的DDoS攻击也呈快速增长趋势，包括针对SSL/TLS握手交互的攻击和针对HTTPS业务的攻击。HTTPS的DDoS防护一直是业界的一个难题，本文介绍HTTPS的DDoS攻击原理和危害，并给出防护思路和防护实践。
文章目录
一、引言
DDoS（Distributed Denial of Service，分布式拒绝服务）攻击的主要目的是让指定目标无法提供正常服务，甚至从互联网上消失，是目前最强大、最难防御的攻击之一。DDoS，常见网络和应用层的攻击经过长时间的对抗研究，对协议和报文内容的分析，已经形成了成熟的解决方案。
但随着用户对安全性要求的增强，以及一些政策性的强制性要求（比如苹果appstore对HTTPS的强制要求），越来越多的网络服务主动或被动的将自己的服务由HTTP切换到HTTPS。HTTPS协议在网络上传输加密的报文，传统的内容检测技术失去了效果；由于处理HTTPS连接的巨大资源消耗，让HTTPS的DDoS攻击成本较低，危害性却较大。
本文介绍常见的针对HTTPS的DDoS攻击原理，通过HTTPS的原理介绍攻击的特别之处；给出常见的防护思路和针对性防护实践。
二、HTTPS的DDoS攻击原理
2.1 HTTPS协议简介
传统的HTTP协议采用明文传输信息，存在被窃听和篡改的风险；SSL/TLS提供了身份验证、信息机密性和完整性校验功能。HTTPS基于HTTP开发，使用SSL/TLS进行加密的信息交互，在交互协议上使用了TCP、SSL/TLS和HTTP三种常见的协议。
图2.1 HTTP协议示意图
针对HTTPS的DDoS攻击也主要从TCP协议、SSL/TLS协议和HTTP协议三个方面来进行的，下面分别介绍。
2.2 TCP协议的攻击
此类攻击比较常见，即是普通的针对HTTPS服务器发起的SYN-Flood、ACK-Flood等，用以消耗服务器的TCP连接等资源。这类攻击不涉及HTTPS特有的协议，所有承载在TCP协议之上的服务都可能收到此类攻击。
2.3 SSL/TLS协议的攻击
SSL/TLS握手过程涉及非对称加密算法，对称加密算法和散列算法，其中非对称加解密是非常重量的计算消耗性工作。而大部分非对称加密算法在实际使用中，服务器的计算量远大于客户端，下面以最常使用的非对称加密算法RSA介绍，其原理如下：
| 1. 选择一对不同的、位数差不多且足够大的素数p和q；
2. 计算n=p*q； 3. 计算φ(n)=(p−1)(q−1); 4. 取一个与φ(n)互质的数e，1<e<φ(n); 5. 计算d，使得d*e≡1modφ(n)； 6. 公钥为（n，e），私钥为（n，d）； 7. 消息m加密c=m^e mod n, 解密为m=c^d mod n |
SSL/TLS使用RSA算法进行密钥交换的过程如下：
图2.2 RSA密钥交换过程
客户端加密随机数m，计算c=m^e mod n并将c发送给服务器，服务器解密随机数m=c^d mod n；如果e和d大小差不多的话，那么客户端和服务器的计算量是基本对等的。但现实中e和d大小差别很大，e一般是一个固定的小素数，当前普遍使用65537(0x10001)，而根据e计算出来的d就是一个很大的值，如下图RSA2048做出的证书（modules表示n，publicExponent表示e，privateExponent表示d）。
图2.3 RSA证书公私钥参数
根据RSA算法第7步流程，服务器的解密消耗远大于客户端。一方面基于历史原因，e不能设置的过大（最大为32位数）；另一方面为了安全性考虑，d又不能选择的太小，一般和n的位数差不多[1]。
虽然有算法来大量减小服务器计算m的CPU消耗[2]，但经过实际测试，使用RSA2048作SSL/TLS密钥交换算法时，服务器在SSL/TLS握手阶段的CPU消耗大约是客户端的6倍。
根据上面描述的握手不对称性，攻击者通过不断与服务器新建SSL/TLS握手，或建立SSL/TLS后不断的重协商密钥（比如著名的THC-SSL-DOS），即可以较小代价将服务器打瘫。更严重者，客户端可以不用计算c，而是提前准备一个c’，让服务器做大量无效但昂贵的计算后，才发现本次SSL/TLS通信失败。这种情况下，极少量的攻击者即可让服务器假死。
2.4 HTTP协议的攻击
针对HTTP协议的攻击涉及两个方面：一方面通过发送大量加密或提前准备的垃圾HTTP加密报文，以消耗服务器对称解密性能；另一个方面消耗服务器处理HTTP连接或附加的其他数据库等资源；
HTTPS的DDoS防护思路
3.1 HTTPS防护概述
根据第二章介绍常见的针对HTTPS的DDoS攻击，HTTPS的DDoS防护也先从TCP、SSL/TLS和HTTPS协议三个方向来讨论。另外，HTTPS防护是一个系统性的工程，涉及到SSL证书管理等工作，下面分别介绍。
3.2 TCP协议攻击的防护
经过多年的防护积累，业界针对TCP协议的DDoS攻击有比较丰富的防护算法。针对TCP-Flood，绿盟科技抗DDoS产品有自研的反向探测算法，不用断正常流量的连接，也能有效识别虚假源。针对肉鸡发起的攻击可通过针对源限速或根据绿盟科技的威胁情报做过滤。
3.3 SSL/TLS协议攻击的防护
SSL/TLS攻击通常是攻击源已经通过了TCP协议防护，是一个真实的客户端。单独考虑SSL/TLS协议的计算型攻击，没有太好的办法。在DDoS防护设备上，可根据客户端发起密钥交换的次数来识别异常客户端，此方法对THC-SSL-DOS还比较有效。
3.4 HTTP协议攻击的防护
针对HTTP协议的攻击，业界有一些通用的HTTP防护算法，比如302跳转、JavaScript验证和图片验证等，以将正常用户和肉鸡程序区分。但HTTP防护算法需要得到解密后的HTTP明文信息，防护设备需要跟踪与客户端的每个HTTPS连接，最终还是回到SSL/TLS性能问题。
3.5 通用HTTPS防护的问题
当前针对HTTPS使用的SSL/TLS协议及之上的DDoS防护一般是做代理防护，比如CDN厂商，通过庞大的集群，消化掉攻击流量。待防护的HTTPS服务器将证书和私钥交给DDoS防护代理方，客户端对服务器的访问转化为：客户端访问防护代理方，然后防护代理方再访问服务器（HTTPS或HTTP都可），客户端和服务器的通信内容在防护代理方是明文的，防护代理方可以通过报文内容分析做进一步的防护。这种防护方法存在的问题在于：
- 用户需要将自己服务器使用的证书和私钥提供给防护代理方；
- 客户端和服务器的通信内容对防护代理方是明文可见的，失去了HTTPS的机密性原则。
3.6 优化的HTTPS防护
本节从HTTPS的整理业务逻辑考虑，绿盟科技抗DDoS防护设备（简称为ADS）作为代理处理客户端发起的TCP和SSL/TLS握手，通过丰富的HTTP协议验证算法单次验证客户端的合法性。将有HTTPS业务交互，并通过HTTP算法交互验证的客户端识别为合法用户，其后续报文直接放行。
HTTPS服务器提供的是应用层服务，SSL/TLS连接只是HTTP业务访问之前的中间步骤，正常用户不会只做SSL/TLS连接，而不进行后续的HTTP加密报文交互。对于多次SSL/TLS连接后，仍不能通过HTTP算法验证的客户端，后续报文直接丢弃或将其加入黑名单。通过这种HTTPS交互全局视图，将攻击者逐步排除。
验证流程如下：客户首先在ADS设备上导入需防护HTTPS服务器的SSL证书和私钥（一般导入一对和服务器上不一样的证书私钥，不导入的话，将使用ADS自带的缺省SSL证书私钥）；当HTTPS攻击发生时，ADS截获客户端的HTTPS连接，通过SSL和HTTP算法验证客户端的合法性；验证通过的合法客户端后续报文，ADS直接放行其与服务器通信。
相对于完全代理方式，ADS针对HTTPS的DDoS防护的优点：
- ADS可以对HTTPS业务报文解密后，基于现有丰富的HTTP算法来防护 HTTPS攻击；
- 客户导入的证书，只是为了让浏览器不告警，客户可以导入一个和服务器上不一样的证书，比如域名验证(DV)证书，这样即可规避一些法律政策问题；
- ADS也可只做客户端合法性验证，不对流量进行解密防护。
3.7 扩展防护思路
针对HTTPS连接在客户端和服务器的计算差异，提高客户端的计算消耗量，以减小攻击者在单位时间内能发起的访问请求，可以一定程度遏制攻击企图。Client Puzzle协议（CPP）[3]是一个很好的参考，服务器发送一个数学问题给客户端，在得到客户端发送过来的答案之前，不允许客户端的下一步操作，客户端需要花费大量CPU来解决此数学问题。
四、结束语
HTTPS防护是业界的一大难题，本文介绍了HTTPS的DDoS攻击场景和防护难点，给出常见的防护HTTPS的DDoS攻击思路，并介绍了绿盟科技ADS技术团队在防护HTTPS攻击上的思路和实践。
五、参考文献
[1]HTTPS://en.wikipedia.org/wiki/Wiener%27s_attack
[2] HTTP://www.di-mgt.com.au/crt_rsa.html
[3]HTTPS://en.wikipedia.org/wiki/Client_Puzzle_Protocol
