四、前提條件
很多的技術(shù)有重要的先決條件;讓我們來討論下。
4.1 在沒有特別要求時內(nèi)存分配
許多靜態(tài)技術(shù)可以對抗心臟出血漏洞的缺陷，包括使用人工核查來對抗，因為OpenSSL的代碼很復(fù)雜。代碼只有簡單了才能安全。
許多安全軟件開發(fā)者首先使用“軟件質(zhì)量”工具來檢測特別復(fù)雜的結(jié)構(gòu)，然后簡化這些結(jié)構(gòu)，這就是安全軟件的產(chǎn)生過程。理想的靜態(tài)分析方法由于代碼復(fù)雜和變得困難，實用工具來檢測這些代碼的復(fù)雜性，簡化他們，在使用靜態(tài)分析方法就變得很有效。我認(rèn)為他們是對的，但是我沒有發(fā)現(xiàn)可以支持他們的數(shù)據(jù)。因此，這似乎是一個合理的想法，但是我很希望有人最終將創(chuàng)建并發(fā)布一些科學(xué)研究來支持和反駁這個假設(shè)。
在任何情況下，簡化的代碼是超過運行工具軟件的。這是一種心態(tài)，應(yīng)該要有不斷的努力來簡化代碼，不然增加運行能力就會增加軟件的復(fù)雜性。代碼的重構(gòu)要使它變的更簡單和清晰，不是不斷的增加新的功能。我們的目標(biāo)是代碼是對的，而不是代碼很復(fù)雜我們看不出問題。
過于復(fù)雜的代碼通常會導(dǎo)致安全漏洞。2006年Debian意外事件通過修改軟件來消除valgrind警告來打破OpenSSL的隨機(jī)數(shù)生成器。但是，修改軟件的人并不真正的了解它。那個人要求幫助，但是OpenSSL的代碼復(fù)雜就很難使人找到改變后的漏洞。Cox通過研究發(fā)生并得到了以下的結(jié)論：“盡量不寫偷懶的代碼，寫井井有條的代碼。你會不可避免的寫一些偷懶沒有組織的代碼。如果有人問到這這個問題，就把它作為代碼不夠好的標(biāo)志。重新把它變得更簡單和容易理解。”
LibreSSL的開發(fā)者使用了OpenSSL代碼和專心用來簡化代碼。LibreSSL-一個OpenSSL的變版，介紹OpenSSL代碼庫的一些問題。他們正在做許多的明智的事，如去掉代碼支持過時的VAX VMS系統(tǒng)。然而，他們刪除了人們關(guān)心的代碼。例如，他們?nèi)コ绹褂玫腇IPS 140-2的認(rèn)證，這同時也受到了許多民營企業(yè)的支持。在使代碼變得簡單和使代碼在很多的環(huán)境中都有效之間存在著沖突，最簡單的代碼不能實現(xiàn)什么。很顯然，許多程序可以變得比現(xiàn)在簡單。
4.2 簡化應(yīng)用程序接口
雖然這稍微的超出了本文的范圍，一個相關(guān)的問題就是應(yīng)用程序接口一般情況下都比較復(fù)雜。
大多數(shù)加密庫和數(shù)據(jù)傳輸庫都是很復(fù)雜的，他們通常呈現(xiàn)給開發(fā)者一個“困惑矩陣的選項和設(shè)置”，因此，大量的應(yīng)用程序和高層次的庫使用不正確的庫來進(jìn)行加密，導(dǎo)致了系統(tǒng)的漏洞。大都數(shù)的問題在瀏覽器中工作中出現(xiàn)，但是他們在其他的代碼上仍然是一個問題。想要了解更多的信息，請看“最危險的代碼世界：在非瀏覽器軟件中驗證SSL證書。”
盡管這在SSL/TLS的使用中是一個技術(shù)而不是一個漏洞，但是他們是無關(guān)的。加密程序庫是創(chuàng)建的復(fù)雜接口的一個組件，所以，它仍然是一個故障組件，簡化代碼。
一個相關(guān)問題是底層庫和建立在API加密庫的系統(tǒng)的很難使用。C忽略了像asprintf和reallocarray等功能。因此，程序員必須要解決這些漏洞，但是他們的解決方法常常會出現(xiàn)bug，這些bug會導(dǎo)致漏洞。
4.3 分配和釋放內(nèi)存
安全的程序必須正常的分配和釋放內(nèi)存，沒有特別的分配系統(tǒng)和內(nèi)存緩存系統(tǒng)。至少，它應(yīng)該很容易禁用和測試它們來確保禁用了他們的程序。一些技術(shù)會減輕心臟出血漏洞的出現(xiàn)，因為OpenSSL的內(nèi)存分配方式。
基本問題是OpenSSL包括未分配的內(nèi)存的應(yīng)用程序特定的緩存空間。目的就是要加快分配在相同數(shù)量的重復(fù)指令。在默認(rèn)情況下，OpenSSL正常分配內(nèi)存，但是在內(nèi)存區(qū)域沒有被使用時是不會解除分配的，在很多情況下，把該區(qū)域變成未使用的區(qū)域變成空閑的，來使它可以立刻重啟。這個緩存列表顛覆了一些操作系統(tǒng)和C的運行的一些的機(jī)制，因為他們并不是總得到通知在內(nèi)存不使用時。
Theo de Raadt提到：“幾年前我們增加利用措施到libc malloc和mmap，這樣一來更多的bugs就會暴露出來。這種存儲器會導(dǎo)致死機(jī)，甚至是核心的崩潰。分析這些bug，之后永久的維護(hù)系統(tǒng)。其他的調(diào)試工具也會達(dá)到這個目的。在很大的程度上說，這基本就沒有性能上的損失。但是在那個時候OpenSSL添加了malloc & free的封裝，使庫存在緩存中。因為一些平臺的性能下降，甚至如果你建立防護(hù)技術(shù)引入malloc() 和free()，這就無效了。在所有平臺上，由于選項是默認(rèn)的，并且Ted的測試表明你不能關(guān)掉它。因為他們沒有測試它的年齡。所以后來的bug顯示了在該層的內(nèi)存的泄漏內(nèi)容。如果內(nèi)存通過free得到了恰當(dāng)?shù)姆祷?，這就可能被munmap捕捉到，并激發(fā)保護(hù)程序的崩潰而不是泄漏你的密碼?！?/P>
似乎有很多在什么地方出來問題的困惑和OpenSSL的內(nèi)存分配方法，Chris Rohlf取得了一些有益的驗證。我覺得這些驗證是很重要的，因為我們必須先用理解這個問題在我們修護(hù)它之前。特別是Rohlf指出OpenSSL使用的是標(biāo)準(zhǔn)的malloc() C內(nèi)存分配方式，當(dāng)它需要一個全新的內(nèi)存塊時。問題是一旦一個內(nèi)存塊被分配，OpenSSL自身還在自身的管理存儲器。Rohlf也指出在很多的環(huán)境下是與空閑列表是無關(guān)的;一個空閑列表把不同的內(nèi)存分配在了一起，但是許多典型的內(nèi)存分配系統(tǒng)也提出了不同的內(nèi)存分配。然而，Rohlf的典型的內(nèi)存分配的應(yīng)用來做同樣的事是絕對正確的，關(guān)鍵是OpenSSL的實現(xiàn)阻礙了各種緩解措施。關(guān)于OpenSSL的內(nèi)存分配系統(tǒng)有另一個問題，但是我們首先要介紹下一些基本知識。
一般的方法就是處理一些內(nèi)存的分配和釋放特例，我們的想法就是緩存和重新對某些對象和緩存器在他們沒有被使用時，這中方法可以顯著的提高性能。這種方法的具體例子包括專門處理共同的內(nèi)存分配的大小，或是用未使用的高速緩存來重新使用對象和內(nèi)存器。有一些具體的技術(shù)來做這些，包括創(chuàng)建一個對象池和一個slab分配器。Glib庫包括一個稱為記憶切片的機(jī)制，提高內(nèi)存的分配性能。許多圖形用戶界面和程序在使用這些方法時，是沒有安全感的。
事實證明，一些方法可以不用解決一些檢測工具如address sanitizer和使用保護(hù)頁系統(tǒng)。特別是使用fuzz測試的問題，如果這些工具不被禁用，則fuzz測試就會變得沒有效果了。的確，fuzz測試可能不能檢測到許多超出范圍的讀操作，在使用這些方法時。
關(guān)于OpenSSL的報告指出OpenSSL的使用是自我管理的一個交大的內(nèi)存區(qū)域的方法然后在進(jìn)一步細(xì)化。這是一個使用slab分配器或是儲存器切片時要發(fā)生的。使用這個方法就是想要提高性能，在這些情況下使用address sanitizer和保護(hù)頁系統(tǒng)來抑制檢測完全的讀溢出。舊的版本稱這要發(fā)生什么。但是我已經(jīng)鉆研了更多的OpenSSL代碼，而這似乎并沒有在OpenSSL中的真實性。這對于心臟出血漏洞來說是個好消息。盡管如此，這些類型的分配方案是比較常見的，而且我知道沒有人說道這些方法的風(fēng)險。
安全性軟件必須要避免使用內(nèi)存緩存系統(tǒng)，尤其是那些與一種分配機(jī)制聯(lián)合在一起形成一個分配請求。如果不是這樣的話，他們至少提供一個簡單的證據(jù)機(jī)制來禁用它們，并要使用該機(jī)制作為其回歸測試套件的一部分。OpenSSL有一個禁用機(jī)制，但是不再被使用，并且在任何情況下很少有人能了解這種機(jī)制，它可以禁用安全分析工具的很多工程。
我們還需要修改我們的教育材料，是開發(fā)人員和測試人員都知道內(nèi)存緩存系統(tǒng)會嚴(yán)重妨礙安全分析。在我的演講中我已經(jīng)提出了一些材料來開發(fā)安全軟件，其他人員也一樣需要。
從長遠(yuǎn)來看，這或許應(yīng)該是使用C的標(biāo)準(zhǔn)接口在freelists緩存/ slab分配器。如果有標(biāo)準(zhǔn)的接口，你們工具可以很容易的修改和自動調(diào)解他們。
4.4 使用標(biāo)準(zhǔn)的FLOSS許可證
這是我的推測，我相信如果OpenSSL使用標(biāo)準(zhǔn)的推廣的許可證來進(jìn)行代碼審核會有更多的貢獻(xiàn)發(fā)生。OpenSSL使用的奇怪的變量許可證是GPL和LGPL。因為GPL是一個最常見的FLOSS許可證。在很多情況下這種不相容性是通過圍繞一個許可證漏洞的，或是使用許可證除了在軟件中通過使用OpenSSL。不過這個詭異的證書意味著很多人更喜歡GPL或LGPL會情不自禁的禁止或是審核OpenSSL。一些人喜歡限制較少的許可證，這些也有很少的幫助，這不是一個標(biāo)準(zhǔn)的證書。
我確實有一些證據(jù)表明非標(biāo)準(zhǔn)證書是一個問題。一個完全獨立的軟件包GnuTLS在最初是專門創(chuàng)建的。因此使用標(biāo)準(zhǔn)GPL許可證的軟件能夠輕易的使用SSL/TLS。OpenSSL的LibreSSL轉(zhuǎn)變成了2-clause BSD許可證，當(dāng)他們寫了新的代碼，相比與OpenSSL許可證。
在很長的一段時間了，廣泛的使用FLOSS證書對FLOSS項目來說是很重要的。1999年Bruce Perens指出：“如果使用這里被列出的一個，就不用寫新的許可證了?！焙髞鞳pen Source Initiative創(chuàng)建了License Proliferation Project，指出許多許可證“和其他開源代碼的許可證是不兼容的，嚴(yán)重的限制了開發(fā)人員的方法，開發(fā)人員僅僅是擴(kuò)大開源軟件的創(chuàng)新方式。”一個重要結(jié)果是OSI直接列出了開源代碼許可證的頁面，只是Popular Licenses，這是“流行，廣泛使用，或是強(qiáng)大的社區(qū)?！?/P>
大多數(shù)的FLOSS是基于GPL, LGPL, MIT/X, Revised BSD，BSD 2-Clause或是Apache 2.0 licenses。我建議限制FLOSS程序的許可證列表。你可以添加一些;在OSI的流行許可名單包括更多。然而，這里的問題是OpenSSL許可證根本就不是一個公共無可證。更重要的是它是一個廣泛使用的不兼容的許可證的非標(biāo)準(zhǔn)證書。如果可能的話，最好用一般通用的許可證代替。
五、什么會減少心臟出血漏洞的影響?
什么能減少心臟出血漏洞的影響或是完全消除?畢竟當(dāng)漏洞出現(xiàn)，你想減少影響。下面有一些方法。
5.1 一旦標(biāo)準(zhǔn)內(nèi)存分配器被替代，啟用內(nèi)存分配器的防御。
許多系統(tǒng)包括減少損壞的內(nèi)存分配機(jī)制，有的有時可以發(fā)現(xiàn)問題。這不能對抗問題，但是能夠減少影響，例如：
一個常見的方法就是內(nèi)存在分配和釋放時零出，這就意味著如果數(shù)據(jù)顯示，這不太可能是有趣的事。
在2014.4.29，David Wagner提出了一個有趣的選擇：“使用一個特定的內(nèi)存分配器，它能夠給每個對象一個隨機(jī)的地址。在一個64位系統(tǒng)上，會有一個48位的地址空間，這一切都在離分配對象遠(yuǎn)的地方，這個心臟出血漏洞不會透露任何其他對象的信息。這可以被納入標(biāo)準(zhǔn)內(nèi)存分配器。注明:我不主張這么做，我不是說這是最好的防御，我只是回應(yīng)你的要求想法來阻止它。”
OpenBSD的malloc支持保護(hù)頁，如前所述。特別是它的G和P選項可以減少和防止信息的泄漏。不幸的是很多的流行malloc不包括這個功能。
5.2 覆蓋了你他們一起做的關(guān)鍵信息
關(guān)鍵信息包括密碼和私有加密密鑰?？梢钥隙ㄟ@不是被優(yōu)化掉的，大多數(shù)的編譯器將會消除這種覆蓋，如果你不能避免的話。
5.3 使用默認(rèn)的加密方法來做完美的安全
一個加密系統(tǒng)有完善的保密，當(dāng)它的非確定性生成器生成一個隨機(jī)的公鑰。當(dāng)PFS啟用，當(dāng)一些密碼暴露時，信息不一定會暴露。因為沒有用于所有信息沒有單一的密碼值。
5.4 使用權(quán)限分離來達(dá)到分離關(guān)鍵密碼的作用
它可以幫助從其余的代碼中分離加密代碼出來，于是即使余下的程序被覆蓋，它也不能直接訪問私密的密碼。
這就會使用到基本的安全原則上，程序要提供最大限度的私密權(quán)利對于他們的工作。這些方法可以通過減少漏洞，如密鑰等關(guān)鍵信息的軟件的數(shù)量，從而減少漏洞的數(shù)量和影響。不過，我要列出一個減少風(fēng)險的方法，不是作為一個完整的對錯。某個地方的代碼必須有提供訪問權(quán)限的數(shù)據(jù)，并且這些代碼可能有漏洞。這里有些其他的注意事項：
David Wagner指出了這一點，并且進(jìn)一步解釋說：“RSA私鑰可能已經(jīng)被移動到另一個單獨的過程，只有運行私有密碼代碼就會轉(zhuǎn)移到這個過程。在Intel系統(tǒng)中，OpenSSL可以使用采用SGX來運行所有的加密計算在獨立的沙盒執(zhí)行環(huán)境下。這被認(rèn)為是在軟件加密模塊下的，如虛擬TPM，虛擬HSM等。SGX提供了分離關(guān)鍵代碼的硬件支持，但是可以使用其他的機(jī)制來代替SGX，像進(jìn)程隔離或是沙箱。有很多的學(xué)術(shù)著作上保持這加密代碼分離的方法，以及一些考慮到了OpenSSL的特別性?！?Rutkowska2013里有關(guān)于SGX的介紹，在Brumley里有應(yīng)用OpenSSL的權(quán)限分離的討論。
Peter Neumann指出在硬件的基礎(chǔ)上，沙箱和fine-grained訪問控制也會提供強(qiáng)有力的機(jī)制來限制權(quán)限，從而控制心臟出血漏洞。
一個學(xué)生在我的開發(fā)安全軟件的課上建議內(nèi)存在服務(wù)器上隔離每個用戶。這是一個很有趣的想法。
5.5 修復(fù)SSL/TLS證書的基礎(chǔ)設(shè)施，尤其是對證書的吊銷。
完整的SSL/TLS的基礎(chǔ)設(shè)施有很多的問題，包括不值得信任的根證書權(quán)限，不良的審核證書和嚴(yán)重?fù)p壞的證書吊銷過程。作為一個關(guān)聯(lián)點，Qualsys SSL實驗室發(fā)布了SSL威脅模型。
在目前而言，讓我們特別關(guān)注證書吊銷的過程，在對心臟出血漏洞的回應(yīng)時，這是被特別的關(guān)注的。心臟出血漏洞使人們有可能為攻擊者遺漏私密為他們的證書，這是很糟糕的。理論上，漏洞網(wǎng)址可以部署新的證書和撤銷舊的證書來解決私密的曝光。不幸的是，今天的證書吊銷機(jī)制在根本上沒有被打破，少數(shù)人會很重視這個問題。因此，今天的攻擊者往往會導(dǎo)致網(wǎng)頁瀏覽器來接受他們的證書被撤銷。有一個迫切的需要推動這方面的工作，遠(yuǎn)遠(yuǎn)超過目前可以使用的機(jī)制，更好的創(chuàng)造安全標(biāo)準(zhǔn)，并實現(xiàn)它們愛默認(rèn)情況下無處不在。我認(rèn)為應(yīng)該有一個確定推動X509 OCSP的必備，但解決方法會證明這是我們需要的。
這是一個很復(fù)雜的區(qū)域，我會總結(jié)這些問題，這里有幾個證書撤銷的機(jī)制，和使用他們的問題：
證書吊銷列表。證書吊銷列表是一個吊銷證書的大文件。這是最原始的撤銷做法。當(dāng)時的想法是一個程序會下載并檢查證書吊銷列表在接受證書之前。但是證書吊銷列表尚未縮減到今天網(wǎng)絡(luò)的要求，今天的證書吊銷列表是很大的，要頻繁的下載更新來保持目前的列表，使他們越來越不和實際。人們已經(jīng)逐漸遠(yuǎn)離證書吊銷列表，如Firefox 24變成了自動更新證書吊銷列表和用戶導(dǎo)入證書吊銷列表的接口。
在線證書協(xié)議。在這個方法中，程序可以與服務(wù)器連接來請求特定證書的狀態(tài)。在線證書協(xié)議應(yīng)該比證書吊銷列表需要更少的網(wǎng)絡(luò)寬度，接近實時的狀態(tài)檢查。然而，在線證書協(xié)議創(chuàng)造了巨大的體積和證書發(fā)送機(jī)構(gòu)的響應(yīng)時間要求，因為他們現(xiàn)在必須提供對應(yīng)所有客戶端在一個真實的時間。在線證書協(xié)議也要創(chuàng)建了一個嚴(yán)重的隱私問題：它會導(dǎo)致客戶透露給CA，它與客戶正在聯(lián)系。另外，不論在線證書協(xié)議和證書吊銷列表有一個根本性的問題：如果你不能找到答案會出現(xiàn)什么?在實踐中，實現(xiàn)線證書協(xié)議和證書吊銷列表的系統(tǒng)都默認(rèn)軟件連接失敗，也就是說，他們接受證書，在他們沒有找到其他的東西。但是軟故障使得整個方法沒有用，因為攻擊者往往可以干擾或去掉這些要求。硬故障時可以正常的工作，和其他人說它也可以為他們工作。然而，切換到硬件故障確實有其自身的嚴(yán)重問題。這個附加的檢查減慢了到安全網(wǎng)站的連接，并且很多用戶對這個額外的時間很敏感。在線證書協(xié)議服務(wù)器的故障是很常見的，在連接到網(wǎng)絡(luò)受到制約的地方時你要暫時不用這個，如果硬故障被廣泛使用，之后攻擊者可以通過短暫的在線證書協(xié)議服務(wù)器連接來禁止HTTPS。攻擊者甚至可以使用在線證書協(xié)議封裝，包括已經(jīng)吊銷證書的在線證書協(xié)議響應(yīng)，挫敗了Langley2014a和Langley2014b的檢查。
在線證書協(xié)議封裝。在線證書協(xié)議封裝試圖通過讓證書者來查詢在線證書協(xié)議服務(wù)器，不是最終的用戶和得到一個簽名的時間的反應(yīng)，是在有效的時間里解決在線證書協(xié)議的問題。當(dāng)客戶端隨后訪問這個網(wǎng)站時，他們會從該網(wǎng)站獲得證書和一個附加的封裝時間。如果沒有收到封裝響應(yīng)，那么客戶端可以回退到另一個方法，如標(biāo)準(zhǔn)的在線證書協(xié)議。這不是廣泛部署的在線證書協(xié)議和證書吊銷列表，但是一些網(wǎng)絡(luò)服務(wù)器和網(wǎng)絡(luò)瀏覽器都支持在線證書協(xié)議裝訂。然而在線證書協(xié)議封裝本身仍然容易受到攻擊過濾;在很多情況下，攻擊者可以去除裝訂的響應(yīng)，并阻止客戶端獲得在線證書協(xié)議服務(wù)器。在這種情況下，在瀏覽器中的正常的軟失效過程中導(dǎo)致整個系統(tǒng)失效。
證書吊銷列表設(shè)置。證書吊銷列表設(shè)置是建立在網(wǎng)絡(luò)瀏覽器的短暫的證書吊銷列表。例如Chrome瀏覽器開發(fā)人員編譯了一天列表，他們認(rèn)為是“高價值吊銷”和使用Chrome的自動更新機(jī)制，使這個列表推送到Chrome的安裝。Adam Langley，一個谷歌的專家，提倡使用證書吊銷列表設(shè)置機(jī)制，而不是證書吊銷列表和在線證書協(xié)議。我同意證書吊銷列表設(shè)置可能是有用的，當(dāng)一個網(wǎng)絡(luò)瀏覽器強(qiáng)行撤銷廣泛使用的網(wǎng)站證書。但是總體而言，我認(rèn)為證書吊銷列表設(shè)置正在從根本上被打破。一個證書吊銷列表設(shè)置就是一個不完全的黑名單。Langley指出，一個證書吊銷列表設(shè)置是不完全的，也沒有達(dá)到足以應(yīng)付大量的撤銷…希望使用證書吊銷列表設(shè)置，那樣我們就能夠把撤銷的變成重要的和行政的并推動重要的…可悲是，這沒有發(fā)生。Gibson有一個正確的觀點，他指出“互聯(lián)網(wǎng)證書吊銷列表列舉出超過兩百萬撤銷和不信任的證書。不過Chrome的證書吊銷列表設(shè)置目前列出了約24000的吊銷證書。兩百萬中另一種隱式的別Chrome信任?！弊C書頒發(fā)機(jī)構(gòu)安理會已經(jīng)強(qiáng)烈反對證書吊銷列表設(shè)置機(jī)制作為唯一的證書撤銷機(jī)制：“心臟出血漏洞是完美典范為什么撤銷的是很重要的，即使沒有確定的關(guān)鍵妥協(xié)。沒有人可以肯定的說，他們的服務(wù)器的私密被攻擊了。大多數(shù)撤銷正在進(jìn)行證書吊銷列表為“商業(yè)原因”，而不是提到證書吊銷列表設(shè)置。這里很清楚的認(rèn)為證書吊銷列表設(shè)置只是一個簡單的吊銷證書的黑名單。”其他瀏覽器也有類似的黑名單，而這些可以有效的時間。但是他們不能替代在線證書協(xié)議的檢查…即使撤銷在線證書協(xié)議的檢查不是100%的準(zhǔn)確的。它仍然可以保護(hù)用戶的比例…關(guān)閉撤銷檢查對每個人來說都是沒有保護(hù)的。只是要清楚，我不認(rèn)為證書吊銷列表或是在線證書協(xié)議運行的良好，我同意證書吊銷列表設(shè)置可以有一定的效果，尤其是當(dāng)有一個特定的高調(diào)網(wǎng)站證書被曝光。然而，像心臟出血漏洞是不同的，在心臟出血漏洞中，如果他們的私有密鑰時網(wǎng)頁不能確認(rèn)被排除了，所以他們需要撤銷他們只是確定的…而且由于OpenSSL被廣泛的使用，這會硬性到很多的網(wǎng)站。證書吊銷列表設(shè)置不能解決心臟出血漏洞的問題。
必備的HTTP頭文件。Firefox計劃實施一個新的必備HTTP頭文件，知道像X.509 OCSP等更好的機(jī)制必須封裝起來便的可用。這只是增加了一個新的HTTP頭文件作為一個HTTPS的連接請求的一部分。如果這個新的頭文件是有服務(wù)器提供的并且支持瀏覽器，瀏覽器將會需要一個封裝在線證書協(xié)議在該域以及子域。再次，如果這是客戶端第一次被訪問攻擊者就可以顛覆這個了，因為攻擊者仍然可以偽造初始連接。有些人混淆了用X.509 OCSP主封裝HTTP頭文件的方法，他們不是一樣的。
短暫的證書。一種解決方案是部署只能持續(xù)很短時間的證書，如，幾天而不是年為單位。從理論上講這就要在今天工作;到期時間是有效測試證書的基礎(chǔ)。不過這可能不是擴(kuò)展，許多系統(tǒng)假設(shè)證書的有效期是很長的時間，并且額外的CA的工作可能很容易犯錯誤。許多的用戶使用過期的證書并且忽略了他們的警告。最后，許多機(jī)制可以對抗其他證書的問題通過假設(shè)的證書很少的改變，所以這些修復(fù)能夠增加漏洞。
X.509 OCSP 必備的封裝。在這種方法中，該證書具有一個標(biāo)記，表示該用戶端必須要接接OCSP封裝，然后OCSP封裝被廣泛使用。這是一個附加的OCSP封裝，但是它可以防止攻擊者篩選OCSP封裝，因為客戶知道什么是錯誤的。請注意這不只是封裝OCSP，這不是一個必要的封裝HTTP頭文件，人們有時會混淆這些不同的方法。不像必須封裝的HTTP頭文件的方法，攻擊者無法輕易篩選出這一點，因為證書本身指出需要封裝。這中方法對短壽命的證書同樣有效果，就不會有這些問題。Langley, CASC和其他的公司都推薦使用OCSP必備封裝。然而雖然有必須的封裝，這沒有正式的規(guī)范并且這種擴(kuò)展不被廣泛使用。對于這個工作我們需要一個正式的規(guī)范，在服務(wù)器和瀏覽器中廣泛的使用包括擴(kuò)展的X.509證書包。
其他方法。還有其他的方法，盡量處理犯罪嫌疑人的證書，包括TACK和Mutually Endorsing CA結(jié)構(gòu)。再次這些沒有被廣泛的使用和接受。
5.6 使軟件容易更新
問題將會發(fā)生，組織者必須在必要的時候修復(fù)他們。如舊的Android 4.1.4就容易受到心臟出血漏洞的攻擊。這是因為Google雖然很快的修復(fù)了這個版本，但是手機(jī)的制造商很慢的更新手機(jī)，手機(jī)運行商通常會推遲更新的時間。也到了談?wù)撝圃焐毯瓦\營商不能修復(fù)手機(jī)的問題，當(dāng)有安全漏洞要修復(fù)時，運行商已經(jīng)即時的出售了手機(jī)。同樣，我認(rèn)為通過FIPS 140-2驗證過程需要改變，以便庫中的漏洞被發(fā)現(xiàn)和更新。
5.7 存儲散列的密碼
當(dāng)然，繼續(xù)把散列的數(shù)值作為密碼，而不是明文或是可逆值，如果要存儲密碼為明文或是可逆的值，你沒有說服人的理由，你就不能使用。
5.8 一般問題：安全軟件教育/培訓(xùn)和減少攻擊者的攻擊
我要提到各方面的改善可能會減少一般可利用的漏洞的數(shù)量，有時利用這些。這就包括安全軟件教育/培訓(xùn)并且要減少攻擊者的攻擊。
很多的軟件開發(fā)人員依然沒有受過什么教育和培訓(xùn)來開發(fā)軟件。然而，幾乎所有的軟件可以直接連接到網(wǎng)絡(luò)上，或是可以通過一個網(wǎng)絡(luò)接收數(shù)據(jù)。許多開發(fā)人員不知道如何設(shè)計軟件來對抗攻擊，一般的漏洞是什么，和如何正確的對抗。事實上，很多開發(fā)人員不知道安全軟件和軟件安全的區(qū)別。這些材料是可用的，我在一本書上寫了如何開發(fā)安全軟件，開發(fā)人員必須要學(xué)習(xí)和運用這些知識。
我們也需要減少經(jīng)濟(jì)效益的攻擊，經(jīng)濟(jì)激勵會使人們發(fā)現(xiàn)漏洞并要出售給攻擊者。在很多情況下人們不會把漏洞告訴防御者，他們可以通過出售這些漏洞給攻擊者來得到很多的錢。畢竟人們可以通過出售一個單一的漏洞來合理的掙到100萬。賞金根本跟不上當(dāng)時的情形，我們需要探討如何減少這些誘惑。例如也許我們應(yīng)該把漏洞信息賣給不是供應(yīng)商和政府的人定罪。基本上對于漏洞信息的捐獻(xiàn)：有意的消除經(jīng)濟(jì)引誘在一個特定的區(qū)域來獲得一個更好的社會。我認(rèn)為這不可能防止公民來告訴他的國家軟件的漏洞;公民必須把這作為他們的職責(zé)。我覺得沒有一個政府會禁止購買這些信息。但是額外的限制可能會減少人們積極尋找漏洞，不是修復(fù)而是利用他們。顯然有一些人會做違法的事，但是有些人會避免做違法的事，這是因為他們怕被捉到。你并不需要停止所有可能，只是改變。也許有更好的辦法，如果有的話，請?zhí)崆罢f，在任何情況下，我們需要找到一個方法來做物質(zhì)的工作和不是安全。
六、應(yīng)用這些方法
正如我前面提到的，開發(fā)安全軟件需要的工具和方法的結(jié)合。當(dāng)有錯誤時，要弄清楚發(fā)生了什么，我們需要了解它們失敗的原因，并要試圖做的更好。
這不是一個很好的時機(jī)來使用加密庫。這些庫是很重要的，但是最近發(fā)現(xiàn)了很多的問題：
1、本文的重點是OpenSSL中的心臟出血漏洞。
2、蘋果的iOS遇到了漏洞，這是一個簡單的故障來檢查無效的證書。這些漏洞可能已經(jīng)通過各種機(jī)制，包括靜態(tài)死代碼檢測器，測試覆蓋工具，或是無效認(rèn)證的否定測試。
3、GnuTLS也不能正確的認(rèn)證證書，其次，似乎有可能檢測到這個在代碼公布之前，其中包括否定測試。
4、OpenSSL CCS的注入。其中一些精心制作的可能會導(dǎo)致密鑰的成為弱項。Masashi Kikuchi已經(jīng)分別描述了他是怎么發(fā)現(xiàn)這個漏洞的。他首先想到了使用Coq來證明使用的正確性。他專注于過度的CCS，然后檢查如何驗證代碼轉(zhuǎn)變條件。他發(fā)現(xiàn)OpenSSL不能驗證失敗的情況，并且發(fā)現(xiàn)了漏洞。
5、一個隨機(jī)數(shù)生成器不能在OpenSSL運行，值得注意的是，可以通過它來檢查這個錯誤，所有的基本工程測試已經(jīng)掌握了這一點。
許多人依靠加密庫但是評估這些要有專業(yè)的知識，美國政府已經(jīng)建立了一套流程來評估加密模塊，稱為FIPS 140-2。我認(rèn)為這是個好方法來廣闊的評價這些很重要并且難評估的項目。
這有更重要的事情，雖然符合FIPS 140-2進(jìn)程，但是不檢查加密協(xié)議，包括SSL/TLS的實現(xiàn)。相反，當(dāng)前的FIPS 140-2進(jìn)程只能計算它在密碼庫內(nèi)的算法和檢測在密碼模塊內(nèi)的方案。我沒有說清楚這個舊版本的文本，我希望弄清這些事。作為實施指南的FIPS PUB 140-2和加密模塊驗證程序的有效性。“該加密模塊可以實現(xiàn)在安防行業(yè)已知的各種協(xié)議。這些協(xié)議的例子是IKE, TLS, SSH, SRTP, SNMP和TPM，在NIST SP 800-135rev1列出來。FIPS 140-2以及其附件沒有解決方案，只有在加密算法和方案被認(rèn)可和允許時，這些在操作模式下使用。”
實際上，OpenSSL堅持使用FIPS 140-2認(rèn)證，它修復(fù)了心臟出血漏洞由于使用了附加的技術(shù)。FIPS 140-2進(jìn)程不能評估正常的OpenSSL代碼，只是評估了叫OpenSSL FIPS對象模塊的特別的軟件模塊。OpenSSL FIPS對象模塊有一樣的接口，并且從OpenSSL代碼中衍生出來，但它還是一個單獨的模塊。開啟“FIPS模式”來結(jié)束FIPS模塊代碼，而不是使用常規(guī)的OpenSSL代碼來實現(xiàn)加密。因此OpenSSL FIPS對象模塊可以保持其通過FIPS 140-2的認(rèn)證，即修復(fù)心臟出血漏洞，這是因為FIPS 140-2進(jìn)程不評估SSL/TLS協(xié)議，因為不符合FIPS某塊的代碼必須要修改。在其他方面不同的情況下發(fā)生的。通常情況下，任何的加密模塊的改變都不能導(dǎo)致驗證的損失，這就需要很長的時間和金錢來得到一個新的驗證。虧損的危險就是一個反常的激勵：加密模塊的開發(fā)人員有一個強(qiáng)烈的動機(jī)來區(qū)分問題。如果這是正確的，我可以肯定OpenSSL開發(fā)人員和FIPS的使用者和高興。這就意味著心臟出血漏洞能夠很快的得到修復(fù)在符合FIPS時，我確認(rèn)在2014-05-09理解NIST。
因此通過設(shè)計FIPS 140-2進(jìn)程中沒有通過SSL/TLS來實現(xiàn)的包括加密協(xié)議在內(nèi)，我覺得這公平來詢問，但是，如果要注意保密協(xié)議。正確的評估加密協(xié)議需要相同類型的專業(yè)知識和其他的加密代碼。很容易創(chuàng)建和運行一個大的測試套件來對抗如SSL/TLS的標(biāo)準(zhǔn)協(xié)議。這并不奇怪，驗證過程沒有發(fā)現(xiàn)隨機(jī)數(shù)生成器的失敗。我想通過FIPS 140-2進(jìn)程至少是使用動態(tài)測試每一個支持加密隨機(jī)數(shù)的生產(chǎn)器，從而確保他們是隨機(jī)的，并且可以避免常見的錯誤。這將不花費很多和提供了一些信心，如果FIPS 140-2進(jìn)程不能延長審查加密協(xié)議，那么事情應(yīng)該建立來審查這些。一般情況下，我們需要重新測試FIPS 140-2來使它運行的更快更徹底。當(dāng)前的進(jìn)程使它很難更新庫，如讓一個人得到了關(guān)于安全和兼容性的結(jié)論。
沒有測試過程中可以找到所有的問題，所以期待的完美是不合理的。不過，存在這新的技術(shù)來評估保密代碼，這就會增加速度減少成本。更重要的是，我們都需要對攻擊者的學(xué)習(xí)來增進(jìn)當(dāng)前評估過程來對抗容易忽略的漏洞。我的目標(biāo)不是來毀掉現(xiàn)有的各種評估進(jìn)程，評估是一項很難的任務(wù)。我的目標(biāo)是要弄清楚做什么可以改善這些事情，因為加密是最重要的。
需要更嚴(yán)格和透明的程序來測試加密協(xié)議，一個要求對安全漏洞進(jìn)行更新和公開的更新程序來防止復(fù)發(fā)。我能夠很容易的看到FLOSS項目來創(chuàng)建一個更嚴(yán)格的測試套件，指的是通過密碼庫的使用和用戶的關(guān)注程度。
我想我應(yīng)該提一下FLOSS。有些人曾經(jīng)試圖宣稱心臟出血漏洞在一個FLOSS不能創(chuàng)建好軟件的證據(jù)。這沒有意義，在專有軟件中也發(fā)現(xiàn)了漏洞，在2013年，Coverity的掃描報告中發(fā)現(xiàn)“開源代碼的質(zhì)量優(yōu)于專有的C/C++項目。”在現(xiàn)實中一些FLOSS程序是安全的，但是專有軟件就不是很安全了。FLOSS有些潛在的安全優(yōu)點，但是他們只是潛在的，你必須要檢測特定的軟件來確定它是否適合您的需要，包括它的安全性。
Eric S. Raymond把下面這叫做“Linus’ Law”：“使用一個足夠大的β測試和聯(lián)合的開發(fā)基礎(chǔ)，幾乎所有的問題很快的成型和修復(fù)就變得很明顯了。”或是不正規(guī)的“只要你認(rèn)真的尋找就會發(fā)現(xiàn)漏洞?！钡?，這不意味著一些人想要。首先Raymond截然不同的發(fā)展FLOSS;他不是在談?wù)揊LOSS和非FLOSS。其次，注意到更小心的措施需要“足夠多的聯(lián)合開發(fā)人員”基礎(chǔ);加密學(xué)使得得到一個大的開發(fā)者基礎(chǔ)成為問題，并且非標(biāo)準(zhǔn)的OpenSSL證書有可能抑制了合作開發(fā)人員的數(shù)量。第三，注意這些文字“幾乎每個問題都會很快的形成”，他從來沒有聲稱發(fā)現(xiàn)了所有了問題，或是他們很快的被發(fā)現(xiàn)。最后，文中指出事實證明傳統(tǒng)的方法在發(fā)現(xiàn)和對抗這些問題時不會奏效，雖然有很多的工具和方法來分析OpenSSL。相反，系統(tǒng)問題來發(fā)現(xiàn)類似的漏洞，因為不同的人使用類似的假設(shè)。好的消息是我們可以找到漏洞并且修復(fù)這些漏洞，因為漏洞的成因是公開討論的。在大的設(shè)置中，本文代表了人們識別系統(tǒng)的問題來修復(fù)他們，從而類似的漏洞會很快的發(fā)現(xiàn)和修復(fù)。
本文著重關(guān)注如何應(yīng)對技術(shù)。然而這里還有很多的非技術(shù)問題。Summer Maynard的“什么能讓心臟出血可以教導(dǎo)OSS社區(qū)的市場營銷”，這就展示了心臟出血是怎么被推銷的。市場營銷是很重要的;心臟出血是一個很糟糕的漏洞，好的營銷加快的反應(yīng)速度和降低了傷害。項目可以幫助關(guān)鍵的部件，這些有潛在問題的;核心的設(shè)施要數(shù)百萬的美元來資助開源項目，這個項目是核心計算機(jī)功能的關(guān)鍵路徑，這收心臟出血漏洞啟發(fā)的。
七、范例
那么是不是有做的很好的例子?畢竟容易引起抱怨，但是如果沒有人可以做的很好，那么這應(yīng)該是不可能的。此外，如果沒有可以復(fù)制的例子，就很難學(xué)習(xí)怎么做了。
我要求人們在可靠性和安全性方面來區(qū)分強(qiáng)大的FLOSS例子。當(dāng)然，一個程序會有一個強(qiáng)勁的投入和不安全性。此外，即時是好的系統(tǒng)也偶爾會有問題的。這是一個很好的想法來看這些例子，因為很容易使用類似的方法在你在實際運行中。這有一些人們確定的項目：
OpenBSD。OpenBSD渴望成為安全領(lǐng)域的第1。他們由一個6-12人的隊伍來進(jìn)行安全審計：“我們不能找到很多的安全漏洞，因為我們正在找軟件的基本問題，使用很長時間后人們才會發(fā)現(xiàn)安全問題，之后修復(fù)這些問題。在系統(tǒng)的任何領(lǐng)域都會發(fā)現(xiàn)漏洞。在我們審計中發(fā)現(xiàn)了在安全問題中新的類，而且往往這些較早審核的源代碼需要重新設(shè)計時要考慮到這些漏洞。代碼要經(jīng)過多次的審核，并且由很多人使用不同的方法來審核，另一個安全的審核過程就是他們的積極性。在很多的條件下，我們發(fā)現(xiàn)對于開發(fā)的決心不是一個問題。在我們的審計過程中，我們發(fā)現(xiàn)了很多的問題，并且我們努力解決這些問題，即時沒有得到證實?！?他們試圖創(chuàng)建并實施對抗這些漏洞的新方法，包括strlcpy()/strlcat()，保護(hù)頁面，和隨機(jī)malloc()。他們還在“默認(rèn)安全”下工作，同時進(jìn)行全面的披露。
OpenSSH。OpenSSH是實現(xiàn)SSH協(xié)議和密鑰連接的工具。OpenSSH是在OpenBSD項目的兩個團(tuán)隊開發(fā)的。一個團(tuán)隊做基于OpenBSD的開發(fā)，其他的團(tuán)隊需要運行這個版本在許多操作系統(tǒng)上運行。OpenSSH使用的是OpenBSD的安全開發(fā)流程。OpenSSH的開發(fā)人員一直在努力降低OpenSSH被攻擊的可能性。他們的方法有防御性程序，使用獨立的庫來減少復(fù)雜性，輕度的改變協(xié)議來減少攻擊，特權(quán)分離，通過改變程序來最大化的緩解在操作系統(tǒng)的攻擊。想要了解更多的OpenSSH的權(quán)限分離可以查閱Provos2003。
SQLite。SQLite是通過使用非常積極的測試方法來獲得可靠性。該項目的代碼行中超過了1000的測試代碼和測試腳本。他們的作為包括三個獨立開發(fā)的測試工具，異常測試，fuzz測試，回歸測試，自動資源泄露測試，100%分支測試和MC/DC覆蓋測試，數(shù)以百萬的測試方案，廣泛的使用assert()和運行時間檢查，Valgrind分析，整數(shù)溢出檢查，開發(fā)者清單。他們沒有編譯警告，在警告開啟或是使用Clang靜態(tài)分析工具。在2014.5.10，Peter Gutmann告訴我：“我一直使用SQLite完成我專業(yè)級軟件開發(fā)，我談?wù)摿嗽趺撮_發(fā)和測試它，在受到強(qiáng)烈的影響下?！?/P>
Postfix。我注意到Elaine R. Palmer和Bill Cheswick認(rèn)為他們對安全和可靠性都全面的了解。Postfix的方法來開發(fā)安全軟件重點在于存在一個非常有經(jīng)驗的團(tuán)隊，從頭開始編寫到安全，涉及到一組守護(hù)進(jìn)程分別執(zhí)行不同任務(wù)的集體結(jié)構(gòu)。Postfix使用C和POSIX的安全子集，并結(jié)合創(chuàng)建安全的替代品的一個抽象層。例如，它有一個“vstring”創(chuàng)始人的幫助來緩解緩沖區(qū)溢出的攻擊和“safe open”創(chuàng)始人來阻止競賽條件。
GPSD。全球定位系統(tǒng)服務(wù)守護(hù)進(jìn)程。這使用了大量的回歸測試，使用多個工具的嚴(yán)格的靜態(tài)測試和可以減少風(fēng)險的構(gòu)架方式。他們使用一個自定義的框架來拓展回歸測試套件，包括使用諸如valgrind工具。他們的靜態(tài)分析工具包括splint，cppcheck和Coverity;他們說道：“我們不知道沒有比GPSD更強(qiáng)大的套件，包括全部的splint注解，并強(qiáng)烈懷疑沒有存在?！被蛟S更重要的是，他們的設(shè)計沒有缺陷。Eric Raymond說到，“如果移動或是主機(jī)不是Windows，GPSD肯定可以運行，在世界上所有的智能手機(jī)的GPS監(jiān)控，DARPA挑戰(zhàn)一個重要的航海系統(tǒng)，從無人駕駛汽車開始，還有大多數(shù)的無人機(jī)和機(jī)器人，只有CVE和在十年內(nèi)沒有任何的漏洞。在幾個月的時間內(nèi)沒有任何的缺陷報告，GPSD是使用傳統(tǒng)C的基礎(chǔ)，從而可以使你非常接近不用判斷。我得到了瘋狂的回歸測試和常規(guī)的四個靜態(tài)分析器?！?/P>
這當(dāng)然不是一個完整的清單，他們中的漏洞會被發(fā)現(xiàn)的。盡管如此，它指向用來提高安全性和可靠性的項目，以及他們是如何工作的，讓別人找到什么值得模仿。
八、結(jié)論和建議
有幾種方法可以發(fā)現(xiàn)心臟出血漏洞，在這漏洞軟件發(fā)布之前。這不是一個真對OpenSSL開發(fā)人員的，他們在一直的努力減少漏洞的數(shù)量，包括審計的人數(shù)和工具。相反，本文是來幫助改善的，OpenSSL和其他的項目可以通過改變他們?nèi)绾伍_發(fā)和評估軟件來阻止將來類似的漏洞發(fā)生。
我們已經(jīng)學(xué)了一個重要的事情是許多的靜態(tài)和動態(tài)分析方法使用在分析的項目中，也沒有找到心臟出血漏洞。這就包括使用自動測試套件，fuzz測試方法，和典型的語句或是分支代碼覆蓋率的方法。幾個源代碼的弱點分析儀的開發(fā)人員正在改善他們的工具來檢測非常類似心臟出血漏洞。我認(rèn)為我們應(yīng)該繼續(xù)使用這些工具，但是和明顯不夠。想要打造安全軟件項目還需要添加一下的一種方法：
1 徹底的negative測試(動態(tài)分析)
2 帶地址檢測和標(biāo)準(zhǔn)內(nèi)存分配的fuzz(動態(tài)分析)
3 在標(biāo)準(zhǔn)內(nèi)存分配器下編譯和使用地址保護(hù)或是sanitizer(復(fù)合分析)
4 在各個領(lǐng)域內(nèi)有驗證是使用手動檢測(靜態(tài)分析)
5 上下文配置的源代碼弱點分析儀，包括注釋系統(tǒng)(靜態(tài)分析)
6 100%分支覆蓋率(復(fù)合分析)
7 入侵時間描述(動態(tài)分析)
8 更安全的語言(靜態(tài)分析)
9 完全靜態(tài)分析器(靜態(tài)分析)
10 徹底的人工核實和檢測(靜態(tài)分析)
11 格式化方法(靜態(tài)分析)
項目應(yīng)該保證容易分析。例如簡化代碼，正常分配和釋放內(nèi)存，使用標(biāo)準(zhǔn)的FLOSS許可證書，這要具有廣泛的兼容性。這將會是很好的使用一個編程語言，包括C，有被廣泛接受的標(biāo)準(zhǔn)注釋符號，從而使注釋語言更容易被接受。象C語言是很難得到這樣的協(xié)議的，但是我覺得要是能夠使它標(biāo)準(zhǔn)化，他們就會更廣泛的使用。
還有很多的方法可以減少心臟出血漏洞的影響：
1 一旦標(biāo)準(zhǔn)的內(nèi)存分配器被取代，開啟內(nèi)存分配器的防御。在很多系統(tǒng)如Linux上的GNU malloc就沒有這種機(jī)制，我們要首先進(jìn)行添加。
2 覆蓋關(guān)鍵信息在處理他們時。
3 使用完美的缺省的向前安全性的加密算法。
4 使用權(quán)限分離的臨界加密用于其它的代碼部分。
5 修復(fù)SSL/TLS的證書架構(gòu)，尤其是默認(rèn)證書的吊銷過程。這就要協(xié)調(diào)一致的努力才能得到真正的解決方案中的規(guī)定，實施和部署;我們要從現(xiàn)在開始。
6 是軟件升級變得簡單。
7 零散的儲存密碼
8 一般的問題：安全軟件培訓(xùn)和教育，降低攻擊動機(jī)。
教學(xué)材料的改進(jìn)和添加，特別是我們需要警告開發(fā)人員在內(nèi)存緩存系統(tǒng)中的潛在的安全問題，在使用C，C++, 或是Objective-C;現(xiàn)在經(jīng)常用的。當(dāng)然真是的問題是開發(fā)人員學(xué)習(xí)使用安全軟件，盡管幾乎所有的程序都在受到攻擊。
現(xiàn)在讓我們來談?wù)凷SL/TLS的實現(xiàn)。在短時間內(nèi)，我認(rèn)為FLOSS項目的建立是建立在一個全面的SSL/TLS回歸測試套件，使用以下的技術(shù)：
該套件要使用徹底的negative測試，它當(dāng)然要有測試選項。
這將會是最好的，如果這個測試套件使用了很長的時間可以達(dá)到100%的分支覆蓋，以為測試使用了多個實現(xiàn)方法，可以幫助檢測缺失的錯誤輸入和錯誤處理。
使用帶地址檢測和標(biāo)準(zhǔn)內(nèi)存分配器的fuzz和傳統(tǒng)的negative測試結(jié)合的方法會更好，fuzz測試可以發(fā)現(xiàn)許多的安全漏洞，但是傳統(tǒng)的fuzz測試就很膚淺，并且測試效果有限，如果他們自然的應(yīng)用密碼協(xié)議。結(jié)合了fuzz測試和傳統(tǒng)測試可以取得更大的進(jìn)步，在協(xié)議上可以做到比單純的fuzz測試更有效的測試。一個完全的測試工具應(yīng)該可以測試到細(xì)微的錯誤狀態(tài)。
像這樣的測試套件可用多種實現(xiàn)方式協(xié)議來實現(xiàn)，但是我認(rèn)為要使用SSL/TLS開始。最近，在很多的SSL/TLS的運行中發(fā)現(xiàn)了很多的漏洞，所有這些都可以通過negative測試來實現(xiàn)。如果任何加密庫有漏洞，在其他保護(hù)下可以泄露數(shù)據(jù)。這個測試套件可以重啟所有的SSL/TLS項目，在任何一個開發(fā)人員做出任何的改變，在他們在用戶的電腦上顯示很長時間以前消除他們。這個套件可以用于潛在的用戶和政府，如果使用驗證，可以提高供應(yīng)商額外的測試來添加下一個版本。一個常見的測試套件將使我們更有信心在所有的SSL/TLS中，在開始點這些測試套件會很有用，在開始的地方便的很容易。它還有資金的優(yōu)勢;如果你不知道你是否支持OpenSSL，LibreSSL叉，或是其他的，這不重要-這個套件可以幫助大家。個別的項目要繼續(xù)使用自己的測試套件，但是顯然現(xiàn)在的測試套件是不夠的。這也可以擴(kuò)展到其他的加密協(xié)議，依賴一中技術(shù)來測試漏洞是不壞注意，包括創(chuàng)建一個共同的嚴(yán)格測試套件;我們要更多的套件才行。但是這可以說是一個好的開始。
更廣泛的說，項目需要檢查心臟出血的漏洞以及其他的漏洞，并且要確定他們是有效的。他們也需要檢查一個項目，在這個項目做的很好時，來看使用壽命方法來復(fù)制。
這沒有更好的辦法。然而，這需要更重要的課程學(xué)習(xí)，要積極的使用套件才能是類似心臟出血漏洞不再發(fā)生。