在許多互聯網領域，尤其是Web PKI和SSL/TLS行業中，我們大多生活在過去的決定中。脆皮密碼、差強人意的協議設計以及不怎麼標準的軟件始終牽絆着前進的步伐。往往一個新操作系統或庫的問世都會迅速被大量使用，然後整個生態系統需要花上很多年的時間處理各種遺留的設計缺陷。
隨着互聯網規模和重要性的增長，我們試圖做出更明智的決定，以避免或至少縮短這一週期。最近，兩個操作系統進行了更新，反映了兩種不同的保持生態健康的做法：
Debian推動了其預發行版本的更改，將只支持TLS 1.2；而微軟則開始在Windows Server 2008添加TLS 1.2支持。
這兩個選擇代表了相反的觀點 - 一個展望未來，另一個回顧過去。
Debian發佈了一個新版本的OpenSSL庫，用於其不穩定的構建 - 一個包含最新版本的開發版本，且僅支持TLS1.2。這種非主流操作真的很少見——目前只有Mozilla的“Modern”配置設置才推薦使用TLS 1.2。
保持OpenSSL庫的長期Debian開發人員Kurt Roeckx寫道：“我希望Buster發佈對TLS 1.2的支持將足夠高，不需要再次啓用[TLS 1.0和1.1]。 ”
Buster是Debian 10的代號，它是Linux發行版的下一個主要版本。沒有宣佈發佈日期，但距離上一個版本的發佈已經超過一年了。
對於只想使用舊版本的人，Roeckx並不留情，他說：“強烈建議你添加對TLS1.2的支持，或讓對方添加支持。”
或許等到Buster發佈的那天，僅支持TLS1.2不再是騷操作或大膽的配置。但熟悉SSL / TLS和Web PKI的人士都知道，我們都是晚期拖延症患者，要落實一個功能，只會晚不會早。
比方說，微軟剛剛向其老化的Windows Server 2008平臺添加了TLS 1.1和TLS 1.2支持。
表面上看，添加對優化版TLS的支持是件好事。但如果我們細看Server 2008的其他TLS功能，缺陷是顯而易見的：
- 沒有AES GCM支持
- 沒有AEAD密碼
- 沒有SNI（服務器名稱指示）支持
- 沒有OCSP Stapling支持
這不是一個非常有吸引力的HTTPS服務器。可能你今天就不想用，更別提三年後了。
Windows Server 2008（使用IIS 7）至2020年仍處於擴展支持階段。但爲什麼現在添加TLS 1.2？
從2018年6月開始，你將不得不支持TLS 1.1或更高版本的PCI兼容性。微軟在其任何一篇關於添加TLS 1.2的博文中都沒有提到PCI。它表示，它想要刪除“棄用舊的安全協議”的障礙，並致力於“一流的加密”。
但是，如果更好的安全性是真正的目標，爲什麼微軟忽略增加其他現代功能？爲了公平起見，Windows Server 2008的TLS支持不是過於差勁。由於ECDHE支持，它至少具有PFS（完全正向保密）密碼。
有時候，強行優化一個老系統可能會帶來更多安全和生態上的落差。因爲它使企業和用戶有藉口堅持早就該被替換或升級的系統。
這也是爲什麼去年Chrome把整個Diffie-Hellman密碼類都移除掉的部分原因。儘管它可以只保留支持更強的2048位參數，直接取消全部更爲簡單安全。
Debian放出的僅支持TLS1.2的消息可能不是最終決定，但這種膽識確實值得讚許。與此同時，在Server 2008裏添加TLS1.1和TLS1.2支持到底是好是壞還真不好說。讓我們靜觀其變吧！
