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