如果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