SSL/TLS與OpenSSL的發展

05-23

SSL/TLS與OpenSSL的發展

來自專欄 TLS與OpenSSL

TLS握手是一個逐漸變化的過程，無論是當前流行的TLS1.2，還是即將要流行的TLS1.3，都是加密技術前進的過程中的一些中間技術。在軟體發展的早期，很多技術迭代的過程中放棄的兼容來達到看起來更加純粹的改進，結果往往是大量的丟失市場份額，甚至自此一蹶不振。不知道從什麼時候開始，軟體行業的向前兼容便成為了事實上的通用做法。事實上我並不是認為TLS1.3能夠取得像1.2這般的市場地位，因為1.2取得的市場成就也並不一定是完全的技術因素。想要從一個通行的1.2版本把市場份額向1.3集中，市場上要付出的成本遠遠不是技術上的提高能夠說服的。很可能假設下個版本是TLS2.0，這個版本才能發揮出支配作用。

OpenSSL作為一個軟體是如此，SSL/TLS作為一個協議也是盡量如此。每一次向前改動的目標都是在對已有的基礎設施改動不大的情況下解決上一個版本的痛點或者是未來的新的功能特性。OpenSSL作為一個軟體誕生於1998年，而SSL協議的發布時間是1995年。因此OpenSSL對SSL的實現在一開始的時候就有比較多的考慮，但是考慮點也是僅限於早期的SSL版本。SSL 1.0是Netscape公司在1995年以前開發的，但是由於有很多嚴重的安全問題，所以SSL 1.0的協議標準根本就沒有發布。後來在1995年的時候2.0發布，但是仍然有很多嚴重的安全問題，就導致了3.0標準的研發被迅速提上日程。緊接著下一年，1996年，SSL 3.0發布。 SSL 3.0的協議是由初出茅廬的密碼學高手Pual Kocher和Netscape公司的工程師 Phil Karlton，Alan Freier三人一起設計的。這個協議標準就是SSL歷史性的RFC6101。Netscape當年的首席科學家Taher Elgamal，就榮幸的擔當了SSL之父的稱號。

就是OpenSSL這套軟體誕生的一年後，TLS 1.0誕生了。1999年，RFC2246中，TLS1.0發布，TLS1.0與SSL3.0的區別並不大，而且協議上就允許協商的過程中從TLS1.0降級到SSL3.0，改名並不代表大的版本改進。雖然這兩次都有比較權威的實現發布，但是OpenSSL一直在安靜的跟進支持。OpenSSL最初的版本是0.9.0b，到了1999年TLS1.0發布之後，OpenSSL也是非常及時的發布了對新的握手協議的支持。OpenSSL與SSL/TLS協議一起成長。但是雖然SSL/TLS握手是OpenSSL的主線，但是那也只是相當於OpenSSL業務層的內容。OpenSSL的雄心遠不止於此，它逐漸的變成一個兼容並包的平台級系統。圍繞著SSL/TLS握手協議展開的大暑計算，證書管理，各種加解密套件組建系統的搭建等等，逐漸的形成專用系統。

TLS1.1於2006年在RFC4346發布，改動並不大，是一個過渡版本。真正具有劃時代影響意義的是TLS1.2，於2008年發佈於RFC5246，此後在互聯網中長期佔據主流標準，之後的握手可以簡單的成為TLS握手，不需要帶SSL的前綴，因為SSL這個稱呼此後逐漸的從市場中退出。對稱加密技術也對應的從早期的AEAD發展為GCM的AEAD方式，並且成為市場主流。

RFC6176對TLS1.2之前的所有RFC進行了重新的定義，直接取消了重新協商退回SSL 2.0的可能。時至今日（2018年），回退的使用SSL3.0在產業界都是不能接受的，但是仍然會存在TLS1.0的版本，支持這些版本的客戶端一般是存在了近十年的老的軟體架構（例如老版本的JDK）。互聯網說它發展的快，它確實很快。但是它總有很多基礎組件的很老的版本仍然在各個老牌的大型企業中充當核心工具集，制約著整個行業的前進，因為老牌企業的組件更新緩慢導致的十多年不能完全放棄之前的老協議的支持的現象比比皆是。全世界都在談論互聯網新架構的時候，互聯網卻大都實際上在使用傳統架構。

TLS1.3是目前最新的TLS握手協議，發佈於2017年的提案，目前（2018年初）仍然是草稿狀態，但是OpenSSL在17年的5月份就已經在1.1.1中支持了。提高握手性能帶來的收益是顯而易見的。但是TLS1.2已經大規模普及，可以預料到TLS1.3是趨勢，但是TLS1.2的市場體量就決定了TLS1.2在相當常時間內仍然會是市場的主流協議。甚至等到更新的TLS版本出現的時候，TLS1.2仍然在市場上屹立不倒。這是一個技術大規模普及之後的慣性弊端，也是整個市場無可奈何的選擇。就好像TCP/IP協議族並不是設計最好的，但是是市場最好的，就很難用更好的技術取代。IPv6確實是更具革命意義的技術，但是大量的互聯網基礎設施依賴於IPv4設計，使用IPv6意味著這麼多年這麼多公司的努力要全部重來，對於企業來說是一個推到重來的二次投資，這在市場上無疑是艱難無比的。TLS1.2就是這樣的一個技術。並不是說其最好，而是說其使用最廣泛。也並不是說它就是不會被取代，而是說在市場層面取代它會很難。HTTP2的使用中直接可以無縫的集成TLS，在TLS1.2普及的今天，HTTP2這個眾人矚目的協議的升級的阻力是遠小於TLS的，而當前如果使用HTTP2，HTTP2就會選擇主要基於TLS1.2，又是對TLS1.2的一個市場鎖定過程。一方面用戶的瀏覽器不會及時的升級到支持TLS1.3的最新版本，一方面如果一個公司已經做好了TLS1.2的服務集群，並且已經投入使用，如果不是特別財力雄厚的公司，很可能這個小組的人已經被抽調去做別的事情了。TLS1.3的升級？原來的系統能用，我為什麼要再花錢？

SSL/TLS協議的整體設計思路是在四層連接之上進行加密，使用TLS握手來達到創建加密後的應用層數據通道的效果，使得應用層的數據通信都是加密的。這個握手的過程一般是非對稱的加密方法，而握手之後的應用層加密通信則一定是對稱的加密方法。類似的思路在數據鏈路層有其他的設計，在IP層也有轟動一時的重量級方案IPSec。例如PPPoE等傳統的撥號上網方式就是首先協商一條數據鏈路層的信道出來，在此鏈路之上的通信都要進行統計收費，甚至是加密傳輸的需求。隨著互聯網的速度越來越快，撥號上網方式逐漸被家用路由器設備代理，用戶越來越少感知到該種協議的存在。信道的概念也就逐漸的模糊了。IP層面的IPSec是一個IP層面的加密信道，這個信道至今仍然重量級的應用於虛擬專用網路（VPN）的應用中，但是隨著TLS的普及，原本屬於IPSec的領域也在被TLS侵蝕，TLS（DTLS）也逐漸的可以用於VPN網路中。理論上VPN是一個網路層的概念，理應由IP層的技術去解決。但是詳細的研究IPSec就會發現，IPSec的根本原理與TLS幾乎是大同小異的，方法上都是先非對稱加密協商信道，然後對稱加密進行數據傳輸，最大的區別就是在作用的網路層次上的不同。而市場與技術的顯著的不同在於，市場的用戶看到的永遠是最接近用戶的一層，在網路中就是TCP和UDP，而不是IP。對於任何一個業務服務，直接接觸HTTPS的概率遠比直接接觸IPSec的概率高很多，也就決定了他們對TLS的感知程度遠比IPSec高很多。如果在TLS能做到IPSec能做到的事情，他們是不會去再學一套繁雜的技術的，即使能技術上更優，性能上更好。快和方便，永遠是市場上的存在的大部分人的選擇第一出發點，技術的最終結果一定是掌握在人手上，而不是技術本身上。

TLS的發展前景，遠比IPSec樂觀很多，原因也就並不是技術上的區別，而是市場上的區別。蘋果應用商店會要求大家強制HTTPS，但是不會要求強制IPSec。而大部分人們只會知道蘋果的要求，換句話說，蘋果的一個要求是讓TLS大規模市場部署提速的原因，而不是TLS這個技術本身。

TLS是一個通用的加解密信道的協議，也就是說它並不是很在乎應用層具體是什麼應用。只是我們大部分情況下見到的是HTTP而已。實際上Nginx的代碼里還有一個很大模塊是email模塊，也是可以應用TLS進行信道加密的。TLS還可以用於IM消息通信，或者是VoIP等一切應用層需要加密信道的地方。由於當前市場上HTTP對TLS的使用是主流，即使是新生代的HTTP2，標準層面試圖並不那麼依賴TLS，只是將TLS作為一個可選的方案，產業界也大都直接的毫不留情面的只支持基於TLS的HTTP2，TLS在產業界的地位在相當長時間內已然牢不可摧。

TLS本身也很難歸結為OSI七層模型中的某一層，它工作在傳輸之上，直接提供功能給應用層。實際的工程中要時刻的區別理論和實踐的區別。理論是實踐的升華和指導，但是理論不能代表實踐，更不能決定實踐。加入RFC規定了瀏覽器必須要如何，但是Chrome，Edge和Firefox等都選擇不支持，這個理論也就無從談起。所以現實中，理論一般由由決定意義的大公司提出，或者幾家大型公司聯合提出。由小公司提出的理論除非其有極其優秀的使用結果，或者是迅速被大公司採納接受，否則標準就無從談起了。可以說，標準的數量是遠遠比實際應用的數量多的。OSI是一種廣泛接受的標準，但是TCP/IP這個最廣泛應用的協議族就並不符合這個標準。以實踐為基礎是工程從業者的基本出發點，畢竟我們不是誰都能力確定一個標準的，但是我們有權力在能力範圍內選擇我們認為合適的實現方式，哪怕有些小細節跟標準不一致。很多流行的開源軟體也是這麼想的，慢慢的，軟體或許就指導了標準，而不是標準指導了軟體。理論必須存在，但是理論在工程中要知道什麼是江湖。

SSL的1.0根本沒有發布，2.0頁由於嚴重的安全問題根本不能夠使用，3.0可以說是第一個可以實際使用的協議，後續的TLS發展都是基於SSL 3.0的，並且盡量的能夠支持向下兼容，在高版本的協議一方不支持的時候，能夠自動的切換為較低版本協議的通信。也就是因此有一種安全攻擊就是主動的降低伺服器的握手版本，使得伺服器使用低安全級別的協議。所以老的協議是早晚要徹底廢棄的，例如SSL 3.0在2015年被標準禁止，TLS 1.0會在2018年出現不再向下兼容支持。這些進度都是標準把控，但是實際的實現上，時間上可能會有出入，但是總體的趨勢是一樣的。

OpenSSL在不斷的發展並且在兼容老版本協議的過程中，經歷了非常痛苦的發展過程。這些OpenSSL的開發者是非常純粹的開源精神，堅持這麼多年，收入相對非常少，創造了全世界首屈一指的基礎架構軟體。在發展的過程中，因為一次一次的攻擊或者漏洞的發生，導致世界範圍對OpenSSL的質疑，包括代碼質量和安全程度上。很多人在OpenSSL的基礎上Fork出新的項目進行二次開發，很多人參考了OpenSSL的實現，進行了新庫的開發。這些其他的工作無疑都一定可以解決OpenSSL的一些痛點，否則他們也不會產生。比較出名的有BoringSSL，LibreSSL，WolfSSL三個。BoringSSL定位於瀏覽器，WolfSSL定位於嵌入式(同樣定位的還有一個mbedTLS)，只有LibreSSL是在OpenSSL爆發了心臟滴血漏洞的時候，踩著OpenSSL的傷痕出現的，並且是OpenBSD直接複製了1.0.1g版本的代碼，重新發布的分支。我們知道任何一個軟體都難免有漏洞，包括可以投入海量資金進行研發的操作系統本身，OpenSSL的功能集非常龐大，並且作為一個開源項目，我個人對其是包容和感激態度的，如果對其代碼質量不滿意，我認為應當捐款已促使其加強或者主動參與其開發的進程，而不是一味的批評甚至是利用自身的影響力Fork新的替代分支，但是開源界最有趣的權力均衡現象是當一批人認為一個開源軟體領導者的錯誤實在不可理喻了，他完全可以Fork出來用他認為正確的方式繼續前進。人情上是殘酷的，但是世界也就是這麼進步的。在OpenSSL這樣一群偉大的無私的作者面前，我個人似乎找不到任何的顏面去批評其實現的質量，但是我也承認OpenSSL還要有很長的路要走。在歷盡風霜的OpenSSL代碼中，我在1.1.0h的版本開始介入分析，我相信對於OpenSSL的發展過程中，不會算是晚期，但是對於其接近20年已經走過的路，也絕對不算是早期。