在實際網(wǎng)絡應用中，傳輸層安全協(xié)議（TLS）是默認的強加密解決方案，但也許這種情況是不應該出現(xiàn)。為什么沒有出現(xiàn)針對它的挑戰(zhàn)，TLS加密中出現(xiàn)的所有問題都被忽視了么？本文來為大家進行詳細分析。
http://netsecurity.51cto.com/art/201106/269613.htm
TLS(包括其前身的名稱，SSL)在進行網(wǎng)絡認證時，加密協(xié)議的作用就是提供強加密的解決方案。盡管在加密認證中也存在其它可供選擇的項目，舉例來說，HTTP摘要式身份驗證，它們傾向于使用較弱的結(jié)構(gòu)。但對于HTTP摘要式身份驗證來說，最大的問題就是這樣的一個事實，它無法提供識別服務器的核查機制。這讓它非常容易遭受到中間人類型的網(wǎng)絡攻擊。
與此相反，在設計的時間TLS協(xié)議就專門考慮到這種情況，并采用了權(quán)威的PKI證書來對服務器進行驗證。該證書制度屬于技術(shù)相關(guān)的過程，基于來自第三方的認證授權(quán)來對服務器進行驗證；從某些方面來看，類似采用OpenPGP公鑰加密信任模型的網(wǎng)絡，但和官僚機構(gòu)的結(jié)合性更高。
來自信任網(wǎng)絡的主要部分屬于它的轉(zhuǎn)折點，但是：不是依靠個人判斷來選擇是否信任，取而代之的是自私自利的商業(yè)認證公司來公司使用者誰可以相信，誰不能被信任。
認證中心系統(tǒng)分為TLS和瀏覽器使用的HTTPS協(xié)議，這樣的話，即使使用者希望使用類似Perspectives之類的獨立認證核查系統(tǒng)，或者Monkeysphere之類信任網(wǎng)絡的話，也還需要對于系統(tǒng)進行繁瑣的設置，以便替代CA公鑰基礎設施。
在不包含電子商務要求的自簽名證書中，基本上沒有比CA簽名的注冊證書更容易設置的了。傳統(tǒng)TLS認證模式的靜態(tài)IP地址認證不會被自簽名證書解除，或者被基于OpenPGP之類的其它公共密鑰加密協(xié)議的技術(shù)所限制。
TLS中存在的問題有什么?
在很多情況下，基于TLS的PKI都會出現(xiàn)問題。舉例來說，對于資源不足又需要安全認證的網(wǎng)站來說，由商業(yè)機構(gòu)或者財力雄厚的愛好者來提供支持是不合適的。主機共享，采用便宜的方式來建立一家“真正”的網(wǎng)站，處理使用TLS保護認證時出現(xiàn)的一些令人不快的問題(舉例來說，共享IP地址)。當然，為了保障服務器認證和強加密方面的認證保護，這些困難是無法消除的。
在理論上，這是一個可以獲得解決的問題。作為一種加密協(xié)議，OpenPGP的基本結(jié)構(gòu)是在大約二十年前由加密愛好者眼中的英雄菲爾?齊默爾曼設計的。對于個人、公司和站點來說，在加密/解密過程的半程中使用簡單的公鑰可以實現(xiàn)非常靈活的設置，并且支持帶外模式的密鑰核查認證。
它采用了大范圍的分配機制，并且可以用來進行外部核查。這里面可以包括作為傳統(tǒng)OpenPGP默認密鑰驗證過程服務的網(wǎng)絡信任模式，以及Perspectives提供的分布式系統(tǒng)。
不過，理論和現(xiàn)實很少一致，在現(xiàn)實環(huán)境中，這并不屬于一個已經(jīng)獲得解決的問題。實際情況是，TLS的應用范圍是如此廣泛，以至于已經(jīng)成為了唯一的選擇，沒有其它競爭者可以對其構(gòu)成威脅，甚至連達到類似水平的要求都做不到。
沒有一家競爭對手，可以對CA的公鑰基礎設施構(gòu)成最基本的威脅，它們甚至連挑戰(zhàn)的機會都沒有，就更不用說市場份額了。所有這一切讓網(wǎng)絡身份認證的簡單實現(xiàn)基本覆蓋所有標準共享主機的想法成為不可能，在每一個使用OpenPGP之類的外部公共密鑰加密協(xié)議的案例中：單獨CGI的執(zhí)行情況和PHP實現(xiàn)，都讓TLS成為不合理的負擔。即使出現(xiàn)了一定的成功，包括Ruby on Rails、Django、CMSplug-ins在內(nèi)的其它競爭對手也將很快跟進。
并且不幸的是，部署加密措施的操作很難做到。對于真正基于OpenPGP的網(wǎng)絡認證簡單實現(xiàn)來說，實施的時間需要了解對服務器運行的軟件類型進行假設，這不是什么很方便的事情;或者與OpenPGP的應用與服務器端軟件開發(fā)人員使用的語言種類有關(guān)。
在處理主機共享，而網(wǎng)絡開發(fā)人員對于系統(tǒng)中安裝的軟件沒有或者只有很少的控制權(quán)，大部分服務器端語言中常見的加密庫都使用來自共享主機的同樣外部工具(通常情況下是GnuPG)來作為OpenPGP支持部分的情況下，這么做是一件非常困難的事情。
讓我們不要忘記處理客戶端的艱巨性。功能豐富的新型瀏覽器可以利用基于HTTPS的URI模式來支持TLS加密。然而，它們不會采用內(nèi)置OpenPGP的方式來支持網(wǎng)絡身份認證。包含強大插件功能的瀏覽器可以采用相對簡單的方法來為系統(tǒng)增加功能，至少在某些情況下可以實現(xiàn)這一點;但插件需要進行開發(fā)，并且這樣做還涉及到客戶端上安裝的語言和分布式軟件的情況，與共享主機上的軟件可用性相比，這樣的認證系統(tǒng)的可靠性更低。
OpenPGP面臨的另一項挑戰(zhàn)
最終，我們找出了為什么沒有以OpenPGP或類似獨立公共密鑰加密為基礎的競爭對手可以替代TLS的原因。所有的努力都需要從基層開始，舉例來說，開源軟件開發(fā)社區(qū)應該提供整體解決方案，以自下而上的方式揭開針對基于CA的PKI加密模式在實際網(wǎng)絡中的霸權(quán)進行挑戰(zhàn)的序幕。
如果沒有具備前瞻性的大學生或者巨型企業(yè)支持的話，這樣的工作將會是非常難以進行的，畢竟，建立一個新的網(wǎng)絡身份認證體系需要做的工作非常多。更糟糕的可能是，即便這樣的開源系統(tǒng)得以建立，由于合理性或者資金方面的問題可能會導致它采用許可模式(估計會是非盈利版權(quán))發(fā)放，這在某些情況下會阻礙代碼的使用，從而限制其推廣。
這還沒有包含對易于使用的標準化帶外密鑰驗證系統(tǒng)的要求，盡管在理論上它并不屬于系統(tǒng)的組成部分，但對于達到廣泛普及的目標來說將會起到非常大的作用。
盡管如此，但這種做法看起來似乎是目前唯一最有可能并且最簡單的方式，可以代替TLS提供更為“民主”的選擇;至少在驗證領(lǐng)域的情況是這樣，我們甚至預計最終可以普及到全程加密。
OpenPGP盡管在本文中被我采用，而且作為典例來進行說明，但SSH協(xié)議在這方面的效果也非常好。 希望讀者多多關(guān)注這方面的知識。
