OpenSSL必死無疑，永遠不會有改善
OpenSSL軟件包大概有30萬行代碼，這意味著其中可能仍然存在著大約299個bug，現在就是心臟出血的bug — 這使得幾乎任何人都可以檢查其通常無權被訪問的內部狀態 — 它已經被修復了.
這的確是所有你需要知道的，但你也得清除，這不會讓我消停下來，是不?
理論上要確保一個計算機網絡連接的安全并不真的很艱難. 首先你可以讓技術過硬的密碼學專家設計一些加密的構造塊. 你將會需要一個好的散列功能，一個好的對稱加密算法，以及一個好的非對稱加密算法. 接下來你可以讓技術過硬的加密協議設計者來定義這些構造塊如何以一種極為詳盡的方式捆綁在一起. 然后是一個技術過硬的API設計者來定義應用程序如何通過一個帶有精心選擇的可靠的默認值，以及一個好的錯誤報告機制的，深思熟慮并且具有容錯機制的API，訪問到協議. 然后是讓技術過硬的程序員根據API完成對算法和協議高質量的編碼實現，并且全部通過分析和審核. 而在此之后，應用程序的開發者 - 他們可以是任何什么人，但通常都技術過硬 - 最后會寫段代碼來打開一個受保護的連接.
但我們的事情還沒完呢.
我們需要確保編譯器將高級語言寫就的代碼正確的翻譯成機器語言指令. 而這之后技術過硬的編譯器開發者才能做到啊! 我們還需要確保計算環境值得信任 — 系統庫和操作系統內核中不能有漏洞，錯誤，后門，或者惡意軟件. 而這又該由誰來負責呢? 你答對了，很明顯該是技術過硬的內核開發人員! 而當然如果CPU不老老實實的去執行指令，所有這些全都白費, 技術過硬的CPU工程師無疑將發現這一點.
現在 — 直到最終 — 我們才可以保護將一張小貓圖片從一臺計算機到另一臺計算機的傳輸.
這不是那么糟糕的，是不是呢?
如我所指定的這樣一個夢之隊也并不是完全無懈可擊，就好像 OpenSSL 中會包含如下的代碼:
/* * The aim of right-shifting md_size is so that the compiler doesn't * figure out that it can remove div_spoiler as that would require it * to prove that md_size is always even, which I hope is beyond it. * （向右移動md_size的目的是，由于編譯器不會如我們所期望的考慮到它可以移除 * div_spoiler，這需要它先證明md_size總是偶數，我覺得這超出來它的處理能力) */ div_spoiler = md_size >> 1; div_spoiler <<= (sizeof(div_spoiler)-1)*8; rotate_offset = (div_spoiler + mac_start - scan_start) % md_size;
老實說 — 在我向你指明這點之前，你會想到會有一個成熟的，正確的，經過編譯器改善的安全風險嗎?
你當然不會！它已經被證明是正確了的，對吧?
而那里就是我們的安全模型——如果你稱它是安全模型的話——發生故障的地方. 這里涉及如此多的代碼，因而如果出問題的話，沒有人會有線索.
在我的計算機上面的數量大概是:
Operating system Kernel: 2.0 million lines of code Compiler: 2.0 --//-- C language runtime library: 0.5 --//-- Cryptolibrary: 0.3 --//--
涉及到每一個額外的編程語言，都將增加大約一百萬行. 使用一個圖形用戶界面技術是這個數量的兩倍, 而一個瀏覽器則又會再翻倍. 一個合理的估計是你讀這篇文章的電腦至少有100，但更可能是1000個漏洞，這些漏洞犧牲了你的安全性. 如果這些漏洞對于你的計算機而言是獨特的，那還不會太糟糕。但實際情況卻不是這樣的，成百萬成百萬的計算機上都有完全相同的漏洞，并且每一個漏洞都有爆發的潛在可能. 還有 — 因為如果這利用漏洞的難度不夠大的話 — 有些人會積極地嘗試去對結果搞破壞，為的是使得“情報收集”更加的簡單實惠. 顯然我們的夢之隊的一些技術過硬的工程師和科學家會有隱藏的動機 — 否則NSA的領導們就有點太無能了.
再就是證書頒發機構。他們的工作是充當“信任錨”，這樣一旦你已經建立了一個安全連接，你也可以知道你是在和誰通信。
CA的可信性是一個笑話.
你會相信:
TÜRKTRUST B?LG? ?LET???M VE B?L???M GÜVENL??? H?ZMETLER? A.? （TÜRKTRUST數據通信和信息安全服務，INC）.
用它來認證進入你銀行的連接嗎?
你甚至不知道 "GÜVENL??? H?ZMETLER?" 是什么意思，對吧?
我當然不會知道啥意思，而且我也不信任他們!
在 2012 年 8月, 他們發表了可以生成其持有者是Google的整數. TÜRKTRUST當然會宣稱這完全只會是“一個一次性錯誤”，也就是說“不會涉及任何犯規的操作”，并且“它永遠也不會再發生一次了”。
沒有人會相信它的只言片語.
然而，你的瀏覽器可仍然默認是相信他們的，僅僅因為它相信其他或多或少的有嫌疑的機構是說實話的. 因此我們就使用一個帶有臃腫漏洞的軟件來進行鏈接，相信幕后有政府滲透的CA來確保我們在和誰通信?
肯定有更好的辦法，對嗎?
然而并沒有更好的辦法.
我們從來沒有發現兩個之前從來沒打過交道的組織建立安全通信通道的更簡單的辦法. 一直到非對稱加密 (1973-1977)被開發出來之前，這都被認為是不可能的. 而如果你想要知道誰在連接的另一端，唯一的辦法是相信一個宣稱知道這一信息的第三方機構. 沒有什么數學或者加密領域上的突破會改變這個現狀，因為我們的身份是社會結構，而不是物理實體.
因此，如果我們想要電子商務運作起來，我們就不得不去運行這些有缺陷的代碼，而我們應該實現一些比"CA-黑手黨"更加值得信任的東西。
而這又讓我回到了OpenSSL — 它很爛. 代碼糟糕透了，文檔也存在誤導, 而默認的東西都是在忽悠扯淡. 再加上其30萬行代碼使其承受這任何你可以想象得到的軟件工程領域的痼疾:
沒有架構在中心的權威機構
6,740 行 goto 語句
內聯匯編代碼
多種不同的編碼風格
宏預處理器的晦澀運用
不一致的命名約定
太多的選擇和選項
不能被理解的僵尸代碼
存在誤導和不連貫的注釋
</ul>
如此種種.
而這不是任何人的錯誤.
沒有人真正負責過 OpenSSL, 它也就成為了發明加密原型的默認垃圾清理場之類的東西, 而由于都是在光天化日之下 (就在你能發現如何使用它的某處)加密所有的東西, 它也成了機密功能的默認來源.
我敢肯定有不止一個人曾近想過“沒有人會因為使用了OpenSSL而被解雇".
而這就是在我寫下這篇文章的時候網上的每個人都會感到恐慌的原因.
這個漏洞是非常糟糕的，即便是作為OpenSSL中的漏洞, 而我在ACM Queue的合作專欄作家, Kode Vicious, 曾近設法去尋找一線希望: "因為他們使用的是一個 '短' 整形, 只有64KB價值的秘密被曝光了."
而這不是第一個也不會是OpenSSL中最后一個嚴重的漏洞 , 而由于其永遠都不會好轉，OpenSSL 必死無疑.
我們需要一個設計良好的 API, 盡可能簡單到使得人們很難去錯誤的使用它. 而我們需要針對這個API的具有獨立品質的實現, 以便如果其中一個不行了，人們可以在幾個小時之內切換到另外更好的一個.
到底是愛它還是討厭他? 請讓我們了解到吧。