RFC /建議：關於安全/不安全的rpc /事件流協議設計

Question

SSL看起來非常臃腫，我想做的事情，我對OpenSSL充滿激情仇恨（NSS可能是可用的）。我需要在兩個節點之間打開一個用於RPC /加密RPC /事件流/加密事件流的TCP通道。我正在使用協議緩衝區來定義和複用不同的流量來源。

我不想用SSL開始。我需要經過身份驗證的安全密鑰建立（認證diffie-hellman），然後可能是基於塊密碼的流對象來加密和解密加密的事件流和加密的RPC。

我首先想到的是通過構建SSL實現節省編碼時間和設計時間，前提是我可以從SSL實現中獲取套接字句柄，並將其用於未加密的交換以及加密的交換。但是這可能最終會是一個醜陋的實現，而且我知道這樣做可能與ssl協議不兼容（即TCP狀態和SSL狀態之間的強耦合）。

我的第二個想法是，通過打開多個套接字節省編碼時間和設計時間。但是衆所周知，多路協議設計是邪惡的。

第三個想法是，我只是加密一切，但所討論的服務服務於高性能事件開關的能力，並且它具有在同一臺機器上運行的數據庫服務器。這種方法的開銷不能滿足，因爲大多數流量都是明文的。

因此，這些方法對我來說似乎並不令人滿意。因此，我得出的結論是，使用cryptopp和boost :: asio我可以推出我自己的解決方案並構建自己的協議（我已經必須這樣做）。我是一個功能非常強大的系統程序員，我有工程師的理解應用加密技術。

我都重複使用，在這種情況下，我希望我可以重用SSL，但我不認爲我可以。任何建議，你可以給我從你的經驗在類似的情況下（你必須設計或在網絡協議工作），將不勝感激。對我產生最大印象的建議會得到嘀嗒。：D

p.s.，我的應用程序還需要執行一些我正在使用cryptopp的異域加密。

Answer 1

你當然可以重新使用SSL - 沒有不良的TCP狀態耦合。你可以在你喜歡的任何底層流上使用SSL，唯一的依賴是它必須是雙向的。

最簡單的方法是使用SSL庫，該庫允許您提供自己的發送/接收函數，以便SSL庫在加密端發送或接收數據時調用它。然後，您將通過將SSL數據包裝在您自己的底層協議中的特殊框架中來實現這些功能。我只熟悉OpenSSL庫如何執行此操作 - SSL_set_bio()函數 - 但我確信其他SSL實現允許類似的操作）。

請注意，協議的密鑰協議部分的計算開銷 - 無論是通過SSL還是自己的 - 都將遠遠超過實際的分組密碼加密/解密，因此「加密所有內容」可能不是如你所期望的那麼大。