隨著越來越多的網絡業(yè)務由明文HTTP轉向加密HTTPS協(xié)議，針對HTTPS的DDoS攻擊也呈快速增長趨勢，包括針對SSL/TLS握手交互的攻擊和針對HTTPS業(yè)務的攻擊。HTTPS的DDoS防護一直是業(yè)界的一個難題，本文介紹HTTPS的DDoS攻擊原理和危害，并給出防護思路和防護實踐。
一、引言
DDoS（Distributed Denial of Service，分布式拒絕服務）攻擊的主要目的是讓指定目標無法提供正常服務，甚至從互聯(lián)網上消失，是目前最強大、最難防御的攻擊之一。DDoS，常見網絡和應用層的攻擊經過長時間的對抗研究，對協(xié)議和報文內容的分析，已經形成了成熟的解決方案。
但隨著用戶對安全性要求的增強，以及一些政策性的強制性要求（比如蘋果appstore對HTTPS的強制要求），越來越多的網絡服務主動或被動的將自己的服務由HTTP切換到HTTPS。HTTPS協(xié)議在網絡上傳輸加密的報文，傳統(tǒng)的內容檢測技術失去了效果；由于處理HTTPS連接的巨大資源消耗，讓HTTPS的DDoS攻擊成本較低，危害性卻較大。
本文介紹常見的針對HTTPS的DDoS攻擊原理，通過HTTPS的原理介紹攻擊的特別之處；給出常見的防護思路和針對性防護實踐。
二、HTTPS的DDoS攻擊原理
2.1 HTTPS協(xié)議簡介
傳統(tǒng)的HTTP協(xié)議采用明文傳輸信息，存在被竊聽和篡改的風險；SSL/TLS提供了身份驗證、信息機密性和完整性校驗功能。HTTPS基于HTTP開發(fā)，使用SSL/TLS進行加密的信息交互，在交互協(xié)議上使用了TCP、SSL/TLS和HTTP三種常見的協(xié)議。
針對HTTPS的DDoS攻擊也主要從TCP協(xié)議、SSL/TLS協(xié)議和HTTP協(xié)議三個方面來進行的，下面分別介紹。
2.2 TCP協(xié)議的攻擊
此類攻擊比較常見，即是普通的針對HTTPS服務器發(fā)起的SYN-Flood、ACK-Flood等，用以消耗服務器的TCP連接等資源。這類攻擊不涉及HTTPS特有的協(xié)議，所有承載在TCP協(xié)議之上的服務都可能收到此類攻擊。
2.3 SSL/TLS協(xié)議的攻擊
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算法進行密鑰交換的過程如下：
客戶端加密隨機數m，計算c=m^e mod n并將c發(fā)送給服務器，服務器解密隨機數m=c^d mod n；如果e和d大小差不多的話，那么客戶端和服務器的計算量是基本對等的。但現實中e和d大小差別很大，e一般是一個固定的小素數，當前普遍使用65537(0x10001)，而根據e計算出來的d就是一個很大的值，如下圖RSA2048做出的證書（modules表示n，publicExponent表示e，privateExponent表示d）。
根據RSA算法第7步流程，服務器的解密消耗遠大于客戶端。一方面基于歷史原因，e不能設置的過大（最大為32位數）；另一方面為了安全性考慮，d又不能選擇的太小，一般和n的位數差不多[1]。
雖然有算法來大量減小服務器計算m的CPU消耗[2]，但經過實際測試，使用RSA2048作SSL/TLS密鑰交換算法時，服務器在SSL/TLS握手階段的CPU消耗大約是客戶端的6倍。
根據上面描述的握手不對稱性，攻擊者通過不斷與服務器新建SSL/TLS握手，或建立SSL/TLS后不斷的重協(xié)商密鑰（比如著名的THC-SSL-DOS），即可以較小代價將服務器打癱。更嚴重者，客戶端可以不用計算c，而是提前準備一個c’，讓服務器做大量無效但昂貴的計算后，才發(fā)現本次SSL/TLS通信失敗。這種情況下，極少量的攻擊者即可讓服務器假死。
2.4 HTTP協(xié)議的攻擊
針對HTTP協(xié)議的攻擊涉及兩個方面：一方面通過發(fā)送大量加密或提前準備的垃圾HTTP加密報文，以消耗服務器對稱解密性能；另一個方面消耗服務器處理HTTP連接或附加的其他數據庫等資源；
HTTPS的DDoS防護思路
3.1 HTTPS防護概述
根據第二章介紹常見的針對HTTPS的DDoS攻擊，HTTPS的DDoS防護也先從TCP、SSL/TLS和HTTPS協(xié)議三個方向來討論。另外，HTTPS防護是一個系統(tǒng)性的工程，涉及到SSL證書管理等工作，下面分別介紹。
3.2 TCP協(xié)議攻擊的防護
經過多年的防護積累，業(yè)界針對TCP協(xié)議的DDoS攻擊有比較豐富的防護算法。針對TCP-Flood，綠盟科技抗DDoS產品有自研的反向探測算法，不用斷正常流量的連接，也能有效識別虛假源。針對肉雞發(fā)起的攻擊可通過針對源限速或根據綠盟科技的威脅情報做過濾。
3.3 SSL/TLS協(xié)議攻擊的防護
SSL/TLS攻擊通常是攻擊源已經通過了TCP協(xié)議防護，是一個真實的客戶端。單獨考慮SSL/TLS協(xié)議的計算型攻擊，沒有太好的辦法。在DDoS防護設備上，可根據客戶端發(fā)起密鑰交換的次數來識別異�？蛻舳�，此方法對THC-SSL-DOS還比較有效。
3.4 HTTP協(xié)議攻擊的防護
針對HTTP協(xié)議的攻擊，業(yè)界有一些通用的HTTP防護算法，比如302跳轉、java script驗證和圖片驗證等，以將正常用戶和肉雞程序區(qū)分。但HTTP防護算法需要得到解密后的HTTP明文信息，防護設備需要跟蹤與客戶端的每個HTTPS連接，最終還是回到SSL/TLS性能問題。
3.5 通用HTTPS防護的問題
當前針對HTTPS使用的SSL/TLS協(xié)議及之上的DDoS防護一般是做代理防護，比如CDN廠商，通過龐大的集群，消化掉攻擊流量。待防護的HTTPS服務器將證書和私鑰交給DDoS防護代理方，客戶端對服務器的訪問轉化為：客戶端訪問防護代理方，然后防護代理方再訪問服務器（HTTPS或HTTP都可），客戶端和服務器的通信內容在防護代理方是明文的，防護代理方可以通過報文內容分析做進一步的防護。這種防護方法存在的問題在于：
用戶需要將自己服務器使用的證書和私鑰提供給防護代理方；
客戶端和服務器的通信內容對防護代理方是明文可見的，失去了HTTPS的機密性原則。
3.6 優(yōu)化的HTTPS防護
本節(jié)從HTTPS的整理業(yè)務邏輯考慮，綠盟科技抗DDoS防護設備（簡稱為ADS）作為代理處理客戶端發(fā)起的TCP和SSL/TLS握手，通過豐富的HTTP協(xié)議驗證算法單次驗證客戶端的合法性。將有HTTPS業(yè)務交互，并通過HTTP算法交互驗證的客戶端識別為合法用戶，其后續(xù)報文直接放行。
HTTPS服務器提供的是應用層服務，SSL/TLS連接只是HTTP業(yè)務訪問之前的中間步驟，正常用戶不會只做SSL/TLS連接，而不進行后續(xù)的HTTP加密報文交互。對于多次SSL/TLS連接后，仍不能通過HTTP算法驗證的客戶端，后續(xù)報文直接丟棄或將其加入黑名單。通過這種HTTPS交互全局視圖，將攻擊者逐步排除。
驗證流程如下：客戶首先在ADS設備上導入需防護HTTPS服務器的SSL證書和私鑰（一般導入一對和服務器上不一樣的證書私鑰，不導入的話，將使用ADS自帶的缺省SSL證書私鑰）；當HTTPS攻擊發(fā)生時，ADS截獲客戶端的HTTPS連接，通過SSL和HTTP算法驗證客戶端的合法性；驗證通過的合法客戶端后續(xù)報文，ADS直接放行其與服務器通信。
相對于完全代理方式，ADS針對HTTPS的DDoS防護的優(yōu)點：
ADS可以對HTTPS業(yè)務報文解密后，基于現有豐富的HTTP算法來防護 HTTPS攻擊；
客戶導入的證書，只是為了讓瀏覽器不告警，客戶可以導入一個和服務器上不一樣的證書，比如域名驗證(DV)證書，這樣即可規(guī)避一些法律政策問題；
ADS也可只做客戶端合法性驗證，不對流量進行解密防護。
3.7 擴展防護思路
針對HTTPS連接在客戶端和服務器的計算差異，提高客戶端的計算消耗量，以減小攻擊者在單位時間內能發(fā)起的訪問請求，可以一定程度遏制攻擊企圖。Client Puzzle協(xié)議（CPP）[3]是一個很好的參考，服務器發(fā)送一個數學問題給客戶端，在得到客戶端發(fā)送過來的答案之前，不允許客戶端的下一步操作，客戶端需要花費大量CPU來解決此數學問題。
四、結束語
HTTPS防護是業(yè)界的一大難題，本文介紹了HTTPS的DDoS攻擊場景和防護難點，給出常見的防護HTTPS的DDoS攻擊思路，并介紹了綠盟科技ADS技術團隊在防護HTTPS攻擊上的思路和實踐。
經營性網站備案信息
可信網站信用評價
網絡警察提醒您
誠信網站
中國互聯(lián)網舉報中心
網絡舉報APP下載
