15.1 概要

SSL(Secure Socket Layer)是由Netscape為了安全的web瀏覽提出的密碼協(xié)議。目前標(biāo)準已被升級為由IETF提出的被收錄在RFCs中的TLS（Transport Lay Security）所替代。SSL的說法依然通用，盡管有時其實是在說TLS鏈接。從現(xiàn)在開始，本書中使用TLS的說法，除非是對舊的SSL標(biāo)準做描述。

它最初也是最主要的目標(biāo)是在互聯(lián)網(wǎng)或者其他不安全的媒介中安全地傳輸字節(jié)。它是一個混合的密碼學(xué)系統(tǒng)：它既是用了非對稱加密又使用了對稱加密。例如，非對稱算法如簽名算法被用作節(jié)點的身份認證，公鑰加密或者DH密鑰交換算法被用作商議共享密鑰或者認證證書。對稱方面，流密碼（原生的或者是采用某種模式的塊密碼）被用來對傳輸中的真實數(shù)據(jù)進行加密，MAC算法被用來對這些數(shù)據(jù)進行認證。

15.2 握手

降級攻擊

SSL2.0 中犯了一個未對握手消息進行認證的錯誤。這使得其很容易進行降級攻擊。降級攻擊是有一個中間的攻擊者，攻擊者將原有的握手消息中的密碼套件信息進行修改。舉例來說，這樣他就可以使得客戶端使用不安全的塊密碼算法進行連接。

由于當(dāng)時的密碼學(xué)限制，很多塊僅有40比特或者56比特。盡管攻擊者可能無法攻破客戶端和服務(wù)端都支持的最佳的加密算法，但是可能能攻破最弱的那個，這樣降級攻擊就會成功。

這也是RFC禁止新的TLS實現(xiàn)再支持SSL2.0的原因之一。

15.3 證書授權(quán)

TLS證書可以用來認證節(jié)點，但是怎么才能認證證書呢？銀行可能有其特定的證書，但是用戶怎么知道哪一個是他的銀行，而不是假裝是他的銀行。向本書之前的介紹的這些算法，每個人都可以產(chǎn)生他們想要的公私鑰對。沒有事情能阻止一些人產(chǎn)生公私鑰對，然后假裝是某個銀行。

當(dāng)一些人使用證書來偽裝成一家銀行的時候，真正的瀏覽器不會相信他們。他們可以意識到這個用戶的證書是不被信任的。這一點是通過TLS標(biāo)準的證書認證模型來做的。TLS客戶端有一個可信的證書列表，通常是操作系統(tǒng)或者瀏覽器自帶的。這些事特殊的，可信的證書，他們被他們的擁有者細心的維護著。

這些擁有者會使用他們的證書來為其他證書簽名。除非擁有該證書，否則無法給Facebook或者銀行進行簽名。

當(dāng)TLS客戶端連接服務(wù)端的時候，服務(wù)器會提供證書鏈。一般情況下，他們的證書是由一個中間CA證書簽發(fā)的，而中間CA證書可能是被其他的中間證書簽發(fā)的，這個中間的又是由其他中間的簽發(fā)，可能只有一個是被根證書簽發(fā)的，系統(tǒng)可以使用根證書來驗證簽名鏈。

假的證書沒有一條指向根證書的鏈，瀏覽器就會拒絕它。

15.4 自簽名證書

15.5 客戶端證書

在TLS協(xié)議里，證書通常僅用來驗證服務(wù)器。這可以滿足一般的使用場景：用戶想要和他們的銀行或者電子郵件提供商安全地交流，然后證書驗證了他們通信的這些服務(wù)。而服務(wù)通常通過密碼或者偶爾也使用雙因子認證來驗證用戶。

目前為止看到的公鑰機制，節(jié)點可以擁有一對或者多對他們自己的公私鑰對。沒有理由用戶就不可以有證書，然后使用證書和服務(wù)端通信。TLS強制支持了客戶端證書。這個特性很少被使用，盡管它可以帶來一些有趣的安全上的好處。

主要原因在于用戶體驗太差了。很多系統(tǒng)不依靠客戶端證書這對于非技術(shù)人員是友好的。有少量系統(tǒng)需要客戶端證書，即使是技術(shù)人員可能也不知道他們，因此新的需要客戶端證書的系統(tǒng)也不會被構(gòu)建。

客戶端證書通常在可以控制兩端然后想要安全地認證TLS鏈接的兩端的節(jié)點市一個很好的方案?？梢宰约寒a(chǎn)生這些證書，然后對證書簽名和認證。

15.6 完美前向安全

歷史上，大多數(shù)場景中預(yù)主密鑰是由客戶端生成的隨機數(shù)，然后對其進行加密，通常是RSA加密。這樣有幾個好處。例如，它意味著服務(wù)器會處理更少的信息熵：由于隨機數(shù)是由客戶端生成后傳遞給服務(wù)端，服務(wù)端不需要自己生成密碼學(xué)隨機數(shù)。它也使得握手的過程更快，因為它不需要來回交流來確認共享的密鑰。

然而，它有個主要的缺陷。如果攻擊者可以拿到服務(wù)器的私鑰。比方說他們能夠找到RSA私鑰的因子，他們攻破了它，偷到了它，或者采用非法的手段迫使用戶交出了這個key。不管他們是如何做到的，獲取到這個私鑰的就使得攻擊者可以解密所有之前的消息。這個私鑰使得攻擊者可以解密加密了的預(yù)主密鑰，然后派生出對稱密鑰，然后解密一切。

這個機制明顯有其他的選擇。如之前討論的DH密鑰交換，運行兩個節(jié)點在不安全的媒介上，商量一個密鑰。TLS允許節(jié)點使用DH密鑰交換來產(chǎn)生預(yù)主密鑰，不管是離散對數(shù)的還是橢圓曲線對數(shù)的。

假設(shè)所有節(jié)點都在使用之后就丟棄掉密鑰，那么拿到密鑰攻擊者也無法解密之前溝通的內(nèi)容。這個特點叫做：完美前向安全。這個完美可能有一點爭議，但是前向意味著溝通的內(nèi)容之后不能被解密，盡管他們的長期密鑰（例如服務(wù)器的私鑰）落入了他人之手。

當(dāng)然，這是基于DH密鑰交換是安全的前提。如果攻擊者有超過任何人的強大的數(shù)學(xué)和計算的能力，比方說他可以使用比想象中高效的方法來解決離散對數(shù)問題，比方說使用很多數(shù)據(jù)中心，很多很多點難，那樣他可能能打破密鑰交換本身。

15.7 攻擊

和其他大多數(shù)攻擊蕾絲，針對TLS的攻擊通常被歸為兩類：

1. 針對協(xié)議自身的攻擊，例如破壞CA機制。
2. 針對特定實現(xiàn)活著密碼套件，例如利用RC4弱點的密碼分析攻擊或者是針對特定AES版本的時間攻擊。

不幸的是，SSL/TLS在兩個范疇內(nèi)都有很多成功的攻擊。本節(jié)后面的內(nèi)容將介紹他們。

CRIME和BREACH

CRIME（Compression Ratio Info-leak Made Easy）攻擊是由BEAST的作者提出的。它是依賴于TLS壓縮泄漏出的原文信息而來的一種創(chuàng)新性的攻擊。相關(guān)的攻擊被稱為BREACH，攻擊者通過HTTP的壓縮來獲取相同的效果。論文的作者在原始論文中就預(yù)測了這種攻擊，但是BREACH作者是第一個將其用到實際攻擊中的。BREACH攻擊的通用性更強，因為HTTP壓縮是TLS壓縮算法中最通用的一個。

兩者都依賴于壓縮的原文的加密，他們的機制是相同的：只是是與HTTP壓縮相關(guān)還是和TLS壓縮相關(guān)。TLS壓縮有個最大的不同是，整個流被攻擊；HTTP壓縮只有信息體唄壓縮，所以HTTP的頭是安全的。攻擊是極其類似的，本節(jié)只簡要地進行介紹來解釋如果原文是先壓縮后加密，攻擊者是如何獲取到原文的信息的。

現(xiàn)在用來做HTTP和TLS壓縮的最主要的算法是DEFLATE。DEFLATE的壓縮機制不是很重要，但是一個重要的特點是出現(xiàn)超過一次的字符序列會被有效地存儲。當(dāng)一個字符序列再次出現(xiàn)時，不是再次記錄這個序列，而是類似于提示，”去之前的信息中尋找，在之前的N個字節(jié)中記錄“

假設(shè)一個攻擊者可以控制原文。例如，一個攻擊者可以注入隱形幀或者是一些可能引起一些問題的JavaScript代碼。攻擊者需要途徑來注入他們對私密事項的猜測這樣當(dāng)他們的猜測恰好出現(xiàn)在明文中時，例如查詢的參數(shù)。通常他們將他們的猜測作為前綴。假設(shè)他們將下面的一個認證碼插入到web頁面的信息體中。

<input type="hidden"
             name="csr-token"
             value="TOKEN_VALUE_HERE">

他們可以將猜測放到已知內(nèi)容的簽名。這個例子中，，它是一個CSRF token；一個服務(wù)端選擇的隨機的token，發(fā)送到客戶端。這個token是為了防止第三方網(wǎng)站使用瀏覽器當(dāng)前的隱形身份（例如會話cookies）進行偽造來產(chǎn)生認證請求。沒有CSRF token，一個第三方網(wǎng)站可能就給潛在網(wǎng)站發(fā)送請求，web瀏覽器會存儲cookie，潛在的網(wǎng)站會以為這是一個已認證的請求。

攻擊者猜測token的值，從第一個字節(jié)開始，然后每次移動一個字節(jié)。當(dāng)他們猜對一個字節(jié)后，密文就會比之前短一點：壓縮算法將會提示它在之前的數(shù)據(jù)中有出現(xiàn)過，然后將明文在加密之前先進行壓縮。明文，和壓縮了的密文將會變的小一點。在流密碼的情況下例如CTR模式，他們可以直接做到這一點，因為這些算法產(chǎn)生的密文和明文的長度完全一樣。如果連接采用的是某種模式的塊密碼，比方說CBC模式，長度的不同可能在塊擴展中丟失。攻擊者通過控制前綴使得密文的長度差是整個區(qū)塊大小來解決這個問題。

一旦攻擊者猜對了一個字節(jié)，他們就可以移動到下一個字節(jié)，知道破解整個token。

這個攻擊有幾個有趣的地方。不僅僅是因為它是一個全新的攻擊，可以廣泛地應(yīng)用到很多密碼系統(tǒng)，更主要的是原文先壓縮再加密在很多現(xiàn)存的密碼學(xué)文獻中是被土建的。它不需要任何高級的工具：你只需要讓用戶向一個潛在的網(wǎng)站發(fā)送請求，然后只需要測量響應(yīng)的長度即可。它也非常地有效：發(fā)表BREACH報告的研究人員可以在一分鐘內(nèi)破解出密文，比方說CSRF tokens。

為了防止CRIME攻擊，關(guān)閉TLS壓縮。這在很多系統(tǒng)中是默認的。為了對抗BREACH攻擊，有很多可選項：

• 不允許用戶注入任意數(shù)據(jù)到強求中。
• 不要把私密的數(shù)據(jù)放在返回體中。
• 重新生成CSRF tokens，比方說每一次請求生成一次。

無條件地關(guān)閉HTTP壓縮是一個壞主意。雖然它確實可以停止攻擊，但是HTTP壓縮是使得網(wǎng)頁變快的主要工具。

網(wǎng)頁應(yīng)用包括很多靜態(tài)的前端（HTML5，JS，CSS），然后僅使用API來進行操作，例如JSON通過REST，這樣就可以有效免疫該攻擊。僅僅在包含私密信息的情況下關(guān)閉壓縮。關(guān)閉壓縮會使得速度變慢，當(dāng)然最起碼大多數(shù)數(shù)據(jù)依然可以通過CDN訪問。

15.8 HSTS

HSTS是服務(wù)器用來表明當(dāng)與他們通信的時候只可以使用安全連接的一個方法。實際中，HTTP中使用過的僅有的安全傳輸是TLS。

使用HSTS非常的簡單，只需要web服務(wù)端加一個額外的“Strict-Transport-Security”到在響應(yīng)頭中。這個頭信息包含了一個最大年齡，這一項決定了將來瀏覽器認為該網(wǎng)站HSTS開啟的時間。通常它是一個很大的值，例如一年。瀏覽器成功地記錄特定網(wǎng)站是開啟HSTS對于該機制的有效性是非常重要的，后面會稍作解釋。可選地，HSTS頭可以包括一個IncludeDomains，里面包括HSTS協(xié)議的詳情。

當(dāng)一個web瀏覽器與一個開啟了HSTS服務(wù)的網(wǎng)站通信時，需要做以下事情：

• 對于任何向該網(wǎng)站的鏈接，都會以HTTPS形式。在向網(wǎng)頁請求前，瀏覽器自己完成這個過程。
• 如果建立TLS連接出現(xiàn)問題，網(wǎng)站將會是不可用的，而不是簡單地給成警告。

HSTS是網(wǎng)站僅支持安全連接的一個方式。幫助用戶防止各種包括被動的監(jiān)聽（監(jiān)聽者想要獲取到明文中的一些信用信息）等攻擊，或者主動的中間人攻擊例如SSL剝離。

HSTS也可以抵抗web服務(wù)端的錯誤。例如一個web服務(wù)端可能錯誤地拿到了一些可執(zhí)行代碼，例如一些JavaScript，通過不安全的連接。一個主動的攻擊者可以解析并且修改JavaScript然后就可以徹底地控制整個網(wǎng)站。

和很多TLS提升方案一樣，HSTS不是萬能藥：它只是一個巨大工具箱里的一個工具，試圖讓TLS更安全。HSTS只是幫助確保TLS是真的在被使用，它沒有辦法防止針對TLS自身的攻擊。

HSTS可能面臨一個雞和蛋的問題。如果一個瀏覽器從來沒有訪問到一個開啟HSTS的網(wǎng)站，那么瀏覽器就不知道這些網(wǎng)站是已經(jīng)開啟了HSTS的。那么瀏覽器可能會嘗試一個普通的HTTP鏈接，這就可能造成SSL剝離攻擊。一些瀏覽器嘗試通過預(yù)先加載一個HSTS網(wǎng)站列表來解決該問題。

15.9 證書鎖定

證書鎖定是類似于HSTS的一個想法，可能比HSTS看的更遠一些：記錄支持HTTPS網(wǎng)站的證書（通常記錄公鑰的hash）而不僅僅是標(biāo)記它們支持HTTPS。當(dāng)和這個服務(wù)器連接時就已經(jīng)存儲了一些信息，然后驗證證書，使得騙子想要通過使用不同的證書偽裝成該網(wǎng)站變得更加困難。

瀏覽器從大量的高訪問的網(wǎng)站中集成一個證書列表來原始地支持證書鎖定。例如Google在他們的Chrome瀏覽器的所有服務(wù)中包括了一個白名單。

15.10 安全設(shè)置

本節(jié)，將會談到密鑰的配置選項，TLS/SSL版本等。不涉及TLS的在信任模式，密鑰管理方面的配置信息。

有一些關(guān)于TLS安全配置的問題：

1. 通常，默認的選項時不安全的，人們意識不到應(yīng)該要修改他們。
2. 安全的TLS配置可能很快就變了，因為密碼學(xué)和實際攻擊也在持續(xù)提升。
3. 老的客戶端有的時候還需要被支持，這也意味著可能會打破一些配置選項。

這些點結(jié)合在一起的一個實際的例子就是BEAST攻擊。這個攻擊利用TLSv1.0中CBC密碼套件的弱點。很多人建議將其修改為RC4.而RC4已經(jīng)被認為是有密碼學(xué)缺陷的，之后密碼分析顯示RC4比之前想象的還要容易被攻破。在被實際利用之前該攻擊已經(jīng)存在好多年了，它已經(jīng)在2006年TLSv1.1被修正，比BEAST論文的發(fā)表早幾年。但是TLSv1.1還沒有被完全舍棄。

好的建議在隨著時間變化。用戶可以通過持續(xù)地更新第三方源例如Qualys SSL Labs。他們通過了對于SSL客戶端和服務(wù)端的測試，和一些針對如何提升配置的額外建議。