End Of Live OpenSSL 1.1 vs Slow OpenSSL 3.0
【英文原文】
你可能已經注意到，OpenSSL 1.1.1 系列將於下週一（2024 年 5 月 27 日）達到壽命終止（EOL）……
最明智的選擇是儘快切換到 3.0 或 3.1 版本。
當然，我們的 mORMot 2 OpenSSL 單元在 1.1 和 3.x 分支上執行，並在執行時自適應每個分支之間存在的各種 API 不相容性。
但我們也發現，切換到 OpenSSL 3.0 可能會導致效能大幅下降……那麼你需要使用哪個版本呢？
OpenSSL 1.1 將壽命終止
眾所周知，廣泛使用的 OpenSSL 1.1.1 系列將於 2023 年 9 月 11 日（下週一）達到壽命終止（EOL）。：（
OpenSSL 1.1.1 的使用者應該考慮他們的選擇，並計劃他們可能需要採取的任何行動。
請注意，Indy 使用者仍然停留在 OpenSSL 1.0 分支，甚至 1.1 還沒有正式支援。一些替代的 IO 處理程式能夠在一定程度上使用最新版本。
Indy 使用者應該轉而使用支援更好的庫，比如我們的小 mORMot。
還要注意的是，1.1 和 3.x 之間存在一些 API 不相容性。函式被重新命名，甚至被刪除；出現了新的上下文建構函式；一些引數型別甚至發生了變化！
我們的單元試圖在執行時解決所有這些問題，並針對 OpenSSL 庫的多個版本進行了測試，以確保您不必擔心這些低階問題。
OpenSSL 3.x 的好處
隨著 OpenSSL 3.0 的釋出，開發人員對庫的內部進行了大規模的重構。
公平地說，OpenSSL 的 1.x 原始碼有點混亂，難以維護。最大的 IT 公司甚至建立了自己的分支或切換到其他庫。最著名的是 BoringSSL，由 Google 維護，並在 Chrome 和 Android 等中使用。
因此，進行重構是時候了，特別是對於像 OpenSSL 這樣對許多專案至關重要的庫。
在新的 3.x 分支中，許多低階 API 函式已被棄用。
實際上，您不再直接訪問庫的內部結構，現在應該始終使用高階 API 來訪問上下文屬性或執行處理方法。例如，低階的 AES_encrypt 函式不再可用：從現在開始，您需要使用高階的 EVP_Encrypt* API。
官方的遷移指南頁面顯然非常龐大，如果您想為未來幾年使用 OpenSSL 做好準備，值得一讀。
OpenSSL 3.0 效能迴歸
3.0 分支的新程式碼可能看起來更漂亮，更易於維護，但它也有缺點。新的並不總是更好的。
這個新版本的大多數使用者在從 1.x 切換到 3.0 時觀察到了巨大的效能迴歸。它影響了許多專案，來自各種語言，甚至是在效能方面本來就不突出的指令碼語言。據報導，時間迴歸從 3 倍到 10 倍不等。在我們這邊，X509 證書操作確實比以前慢得多——最糟糕的是關於 X509 儲存。
一些減速是預期的並記錄在案（例如 RSA 金鑰生成，現在使用 64 輪）。但迴歸要嚴重得多。
罪魁禍首似乎不是核心加密程式碼，如 AES 緩衝區編碼（asm 聲稱在 3.x 分支上進一步最佳化），而是 OpenSSL 上下文結構本身。它們是為了未來的可維護性而重寫的，但沒有關注它們的實際效能。
OpenSSL 3.1 的數字
3.1 分支聲稱已經解決了這些問題中的大部分。
可以肯定的是，我們使用多個版本的 OpenSSL 執行 mORMot 加密迴歸測試。實際上，OpenSSL 3.1 比 OpenSSL 3.0 快得多，但仍落後於 OpenSSL 1.1。
以下是在 Win32 上執行整個 TTestCoreCrypto 方法時觀察到的數字：
OpenSSL 1.1 = 15 秒
OpenSSL 3.0 = 33 秒
OpenSSL 3.1 = 18 秒
有幾個方面需要強調：
這些測試還執行了 mORMot 引擎加密，因此您不僅僅是在測試 OpenSSL：在上述數字中，“純 mORMot”測試大約需要 4.5 秒；
任何嚴肅的專案都應該考慮在 Win64 上編譯，並在 x86_64 Linux 上執行伺服器 - 在這個平臺上，迴歸確實存在，但只是稍微好一點；
與 TTestCoreCrypto.Catalog（即證書處理）相比，TTestCoreCrypto.Benchmark（即原始緩衝區加密）受到的減速影響較小；
我們的測試是單執行緒的，並且在重度執行緒化的程序中報告了更嚴重的減速（高達 x10）。
在 mORMot OpenSSL 包裝器中，我們嘗試儘可能多地快取上下文。例如，我們不會為每個呼叫按名稱查詢 OpenSSL 演算法，而是在執行時快取它以避免任何減速。
但對於 OpenSSL 3.0 來說，這似乎還不夠，這可能會影響您的應用程式效能。
支援還是不支援
因此，OpenSSL 3.1 似乎是前進的方向。
在 Linux（或其他 POSIX 系統）上，您可能會使用系統附帶的庫。
因此，您不必擔心使用哪個版本。而且，可悲的是，您的發行版很可能提供 OpenSSL 3.0 而不是 OpenSSL 3.1。
在 Windows（或 Mac）上，您可以（應該？）使用您“自己的”dll/so 檔案，因此您必須考慮庫的支援級別。
OpenSSL 3.0 是一個長期支援（LTS）版本，將維護到 2026 年 9 月 7 日。
OpenSSL 3.1 將僅支援到 2025 年 3 月 14 日。
這些支援結束日期可能看起來違反直覺，但這是開源專案中的常見方式，最著名的可能是 Ubuntu LTS 版本。
有關 OpenSSL 支援生命週期的更多資訊，請檢視官方 OpenSSL 下載頁面。
因此，對於大多數專案，特別是在 Windows 上，您可能會發布帶有自己可執行檔案的 OpenSSL dll，切換到 OpenSSL 3.1 可能是前進的方向。
如果您需要為您的產品收集一些安全認證，您可以考慮使用 OpenSSL 3.0 LTS 版本，這可能有助於您的認證在更長時間內保持有效。
一如既往，歡迎在我們的論壇上提供任何反饋！