在上一講中，我們已經介紹了Padding Oracle攻擊的背景知識和基本原理。簡單來說，攻擊就是利用密文解密后填充是否正確這一信息，以此得到明文的部分信息甚至恢復出全部明文。在這一講里，我們會按照時間序梳理一遍與此攻擊相關并影響SSL協議安全性的重要學術文章，簡單介紹文章的貢獻，給出其影響及對現實應用的指導意義。
1998年，貝爾實驗室研究員瑞士密碼學家Daniel Bleichenbacher在頂級密碼學會議CRYPTO上發表了一篇名Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS#1的文章，這算是Padding Oracle攻擊的開山之作。文章給出了可用于實際攻擊那些使用了PKCS#1v1.5填充規范的RSA的協議的一種有效方法，這些協議中就包含了當時已被廣泛使用的SSL協議。此外，這篇文章的學術意義還在于，它也第一次表明了考慮加密方案的適應性選擇密文攻擊安全性是有實際意義的，實際中可以發起選擇密文攻擊（對于使用1024bit密鑰加密的密文，恢復出對應明文需要大約一百萬次Oracle查詢，作者對此的描述為though not entirely as efficient）。文中給出的解決方案是，不要使用PKCS#1 1.5版本中的填充方案，而是轉而使用OAEP。
然而在2001年，James Manger在CRYPTO上發表了文章A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS#1 v2.0，結果就是OAEP這種填充機制也是可以進行Padding Oracle攻擊的，并且解密一條1024bit加密的密文，只需要大約1000次Oracle查詢。這里需要額外提一句的是，SSL協議并不支持OAEP填充，所以目前TLS1.2中，使用的填充仍舊是v1.5中的方案。
以上都針對RSA的攻擊，對應在SSL協議中，握手過程交換預主密鑰的消息是攻擊的點。而對于對稱加密方案，首先提出Padding Oracle攻擊的是Serge Vaudenay。在2002年EUROCRYPT上，在瑞士聯邦理工大學（Swiss Federal Institute of Technologies，EPFL）領導安全及密碼實驗室（Security and Cryptography Laboratory，LASEC）的Serge Vaudenay教授在發表了名為Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS . EUROCRYPT 2002的文章，論文中表明Padding Oracle的攻擊思想在對稱密碼領域也是可行的。這打開了Padding Oracle攻擊的一扇新的大門，其意義從后面的文章直接將CBC模式下的Padding Oracle攻擊稱為Vaudenay攻擊就可見一斑。
CBC模式下Padding Oracle的詳細攻擊原理和方法在上一講中已給出了詳細講述，這里還要再提一下的是，在02年的這篇文章中，攻擊者判斷Padding是否正確的依據，是利用Padding檢查不通過和消息驗證碼（Authentication）檢查不通過時，SSL回復的Alert值不同這一特點。但其實Alert值是加密傳送的，所以這個方法并不實際。盡管這樣，在這之后，各個SSL相關的庫都將Padding檢查失敗和Authentication檢查失敗返回的Alert值不做區分。
緊接著在03年，Serge Vaudenay在CRYPTO上發表了文章Password interception in a SSL/TLS Channel，在文章中提出使用時間旁路信息來區分padding檢查失敗和authentication檢查失敗，這是因為在實現時，如果padding檢查失敗，就不會做authentication檢查，因此padding不正確時，服務器的響應時間會比正確時要短，利用這個旁路信息，攻擊者就可以獲得了一個有效的padding oracle。
很自然地，各個庫對應的響應方式就是無論padding檢查正確或失敗，都進行authentication檢查，這樣程序所表現出的時間差異就被彌補了。
這之后很長一段時間，對于SSL協議的Padding Oracle攻擊因為無法在實際中獲取到可用的oracle，就一直沉寂了。直到2013年，Lucky13攻擊的出現才又將padding oracle攻擊帶回大眾的視野，并且引發了很強烈的反響。下面我們就來詳細介紹Lucky13攻擊，看看它是如何又打開一個信息旁路信息通道，使得padding oracle再次生效。
這里需要多提一下的是，14年的POODLE攻擊又將Padding Oracle攻擊推到了風口浪尖，并宣告了SSLv3的死刑，但是這個攻擊只是一個并沒有利用其它的旁路信息，通過連接的繼續與斷開作為padding合法與否的反饋信息，在學術上沒有新的貢獻點，因此只是在工業界掀起了一陣風潮。
下面我們先來簡單回顧一下，Vaudenay攻擊要求攻擊者能夠識別出何時填充是正確的，在TLS中，即使消息驗證失敗也要可以。通常情況下，驗證應該在解密之前做，而TLS顯然沒有這么做，這就導致了在CBC模式下的Padding Oracle攻擊。
Vaudenay最初的攻擊利用的是在填充檢查失敗和驗證失敗時TLS會返回不同的警告值，但顯然這無法構成實際攻擊，因為警告值是加密傳送的。隨后，Vaudenay又發現可以利用時間旁路信息來識別填充是否正確，這是因為若填充不正確則不會執行驗證，服務器所用的時間定會多于填充正確時的時間。修補方法就是不論填充檢查是否成功，都進行驗證。
但是在這種情況下，攻擊者仍舊可以精心構造特定長度的消息，使得服務器在處理填充合法和不合法的情況下，所用的時間是不同的，也就是仍舊可以得到一條時間旁路通道進行攻擊。這就是我們接下來要詳細介紹的Lucky13攻擊。
2013年，AlFardan和Paterson在頂級會議Security&Privacy上發表了文章Lucky Thirteen: Breaking the TLS and DTLS Record Protocols，文中提出了對于全部版本的SSL協議的一種Padding Oracle攻擊方法。
文中利用的旁路信息，仍舊是服務器處理padding正確和不正確的消息時所用的時間，只不過這個時間的不同是因處理不同長度消息時進行消息驗證過程中調用壓縮函數的次數不同造成的。換句話說，壓縮函數的調用次數與消息長度有關，而處理的消息長度值又與填充長度有關，因此填充的合法與否會間接導致壓縮函數的調用次數不同，從而導致服務器處理消息的時間不同。
假設使用TLS_RSA_WITH_AES_128_CBC_SHA密碼套件，有一條待解密消息如下：
ContentType || Version || Length || Civ||C1||C2||C3||C4
|-----1字節-----|-----2字節----|-----2字節----|------16字節 * 5--------|
服務器收到消息后，將5字節的頭消息去掉，解密Civ||C1||C2||C3||C4，解密后的消息長度為64字節，格式如下：
Message || MAC || Padding
在之前的設定中，為消除時間旁路信息，服務器在檢查Padding后，不論Padding是否正確，都進行驗證。因此服務器首先檢查Padding，如果Padding合法，則去掉相應長度的Padding，否則，認為Padding長度為0。之后去掉20字節的MAC，然后驗證MAC，去做HMAC的消息如下：
HMAC( Seq || ContentType || Version || Length_M || Message）
|--8字節--|-----1字節-----| --2字節--|---2字節----|
可以看到在Message前面附加了13字節的內容。下面我們重點關注計算HMAC過程中調用的壓縮函數的次數。HMAC的計算如下：
HMAC(K, m) = H( (K ⊕ opad) || H((K ⊕ ipad)||m) )
若使用SHA1作為哈希函數，那么每個壓縮函數處理的消息長度是64字節（下稱為一個block）。 (K ⊕ ipad)是一個block，如果消息m的長度不是64的倍數，則要先對消息進行填充，填充機制如下：
m || 0x80 || 0x00 … 0x00 || Length(8字節)
可以看出，若消息需要填充，則至少填充9字節。
(K ⊕ ipad)是一個block，因此外層哈希會調用2次壓縮函數，若m填充后是一個block（也就是m至多有55字節）時，則內層哈希函數調用2次壓縮函數，HMAC共有4次調用；否則會共5次調用。
因此攻擊者在看到消息ContentType || Version || Length || Civ||C1||C2||C3||C4后，可以實施如下攻擊：
服務器解密后，Message||MAC||Padding共64字節，此時檢查Padding：
攻擊者將一次壓縮函數調用的時間差作為旁路信息來區分Padding正確與否，進行常規的Padding Oracle攻擊。
很容易想到，針對Lucky13的修補，就是不論可能的Padding是什么，都要用恒定的時間計算MAC。實際中，不同的密碼庫有其不同的實現方法，大概可以分為兩類：
加入dummy function處理，比如當padding不正確時，PolarSSL庫就會計算需要額外執行的壓縮函數數目，然后調用一個叫做md_process的函數;for(j = 0; j < extra_run; j++)
md_process(&ssl->transform_in->md_ctx_dec, ssl->in_msg);
加入dummy data，直接執行壓縮函數，使不論Padding正確與否，都執行可能的最大數目壓縮函數調用，OpenSSL和Mozilla NSS就是采用了這種方式。
這兩種方法單從時間上看，都成功封堵掉了時間旁路這個通道，但是對于利用dummy function的處理方式，若攻擊者能夠通過某種方式得到dummy function是否執行了的信息，則可以仍舊發起Lucky13攻擊，將這個信息用作旁路信息，得到一個Padding Oracle。
上一小節講到，如果攻擊者能夠得到dummy function是否被執行的信息，Lucky13就還可以攻擊成功。今年AsiaCCS上的一篇文章Lucky 13 Strikes Back，就成功地得到了dummy function執行與否的信息，從而讓Lucky13復活。
文章作者構建的攻擊場景是在云中，攻擊者與攻擊目標是運行在同一臺物理機器上的兩個虛擬機。攻擊者運用Flush+Reload的技術，獲取到目標機執行dummy function的情況。從作者給出的結果來看，這個新的旁信息比原本Lucky13攻擊利用的網絡時間旁路信息要更加準確，平均恢復每個字節需要查詢的次數要少。
下面就來簡單說明一下這個關鍵的Flush+Reload技術。它是一種強有力的基于cache的旁路攻擊方法。我們知道cache位于CPU和RAM之間，利用時空局域性原則（principle of locality），將最近訪問的memory中的內容放到緩存中來，以減少平均訪存時間。訪問cache要比訪問memory快很多。因此，Flush+Reload的大致做法就是先將特定的代碼從cache中清除掉，等目標程序執行后，再執行那段代碼，通過加載代碼的時間長短來判斷程序是否在cache中，若是，則說明目標程序也執行了這段代碼。
此外，發起這個攻擊需要滿足以下兩個要求：
這個攻擊相比原本的Lucky13攻擊來說，不需要通過收到服務器的響應去測算所用時間，因此避免了很難處理的網絡通道噪聲，但是仍舊需要處理來自微架構的噪聲（如指令預取等）。此外，對于補丁做得比較到位的庫（如OpenSSL，Mozilla NSS等）此攻擊無法奏效。目前確認受影響的庫包括GnuTLS，PolarSSL和CyaSSL。
要使這個攻擊失效，可以從兩個方面入手，一是密碼庫的實現，對于填充合法和不合法的情況，采用同樣的函數處理，并且保證同樣的執行流（分支不依賴于消息）；另一方面可使Flush+Reload技術失效，比如可以關閉去重功能，對緩存進行分區，或者載入緩存時進行掩碼（基于硬件)。
以上攻擊講完，似乎Padding Oracle攻擊所需的padding oracle已無從尋找，從實現上來講，在padding正確與否時，服務器都盡量做到了響應保持一致。但這并不意味著無法找到差別，畢竟服務器在收到正確的消息后，要完成正常的業務處理，而消息不對時則會拒絕服務。因此，找到一個特殊修改密文的方法使得服務器正常接受，同時最后一個字節可以預測，則就得到了一個可用的padding oracle。
14年的貴賓犬攻擊用到的就是這個思想，但只能對sslv3攻擊成功，是因為它利用了SSLv3消息的不確定填充機制，也就是填充的最后一個字節表示填充的長度，而對填充的其他部分則不做要求。對于密文Civ||C1||C2||C3||C4，若明文長度剛好為分組的倍數，也就是最后一個分組全部都是填充那么將C2到C4的位置，若替換后的密文被服務器接受，則可得知解密后最后一個字節，也就恢復除了C2所對應的明文的最后一個字節。
可見這個攻擊的要求還是較為苛刻的，首先要保證最后一個分組全部都是填充，此外因只能恢復分組的最后一個字節，因此還要設法使待解密字節處在分組的最后一個字節，同時保證最后一個分組全部是填充。
附：這里是一個可用的poc。
SSL的Padding Oracle攻擊就介紹到這里，在下一講中，我們會對SSL中弱PRNG帶來的安全問題進行深入剖析，敬請期待。