DIY消息級安全？
對於這個社區來說，這可能是一個過於初級的問題，但我希望得到專家的幫助：
假設 TLS 不足以保護客戶端和伺服器之間傳輸的消息，那麼在客戶端和伺服器之間建立安全通信的好方法是什麼？就我而言，這是在 Web 伺服器和移動應用程序之間，兩者之間有典型的請求和響應。
我有以下想法：生成一個非對稱密鑰對，將公鑰分發給移動客戶端，並將私鑰保存在伺服器上。當從客戶端啟動與伺服器的通信時，我可以為會話生成一個對稱密鑰，使用公鑰加密密鑰，將加密密鑰發送到伺服器，然後伺服器將使用私有非對稱密鑰解密對稱密鑰，然後繼續使用對稱密鑰解密請求和加密響應。
這是否接近可接受的解決方案，為了實現可接受的解決方案，我應該注意哪些細微差別？應該選擇哪些算法？
您的想法缺乏前向保密性，而 TLS 之類的協議通常（無論如何在較新版本中）提供。否則，它接近於通常如何完成這些事情。
為了實現前向保密，您將改為使用臨時 Diffie-Hellman 密鑰交換，您將使用預共享的公鑰（這將是簽名密鑰，而不是加密密鑰，這會產生影響）進行身份驗證。
算法有幾種替代方案，但基本上你應該……做好的 TLS 密碼套件所做的事情。例如帶有 ECDSA 或 RSA 簽名的 ECDH 或 EDH。AES-GCM 將是對稱加密的一個很好的預設選擇。
由於沒有給出特定的攻擊場景，我會添加另一個更高級別的選項。
當點對點傳輸安全性不應該足夠安全時，您可能還會考慮端到端消息安全性或應用程序級安全性。
TLS 的想法是它保護從客戶端到伺服器的消息。然而，客戶端和伺服器並不總是資訊的端點；例如，可以使用 SSL 解除安裝程序。此外，可以緩衝或儲存消息以供進一步處理。TLS 僅保護傳輸中的消息。TLS 密鑰也可能不如應用級密鑰安全，例如當 TLS 密鑰用於多個連接的通用安全性時。
因此，例如，您可以使用加密消息語法對通過 TLS 連接發送的（某些）消息進行加密和簽名。顯然，即使TLS 連接被攻擊否定，確保消息和消息協議是安全的也是很好的。
請注意，例如，Web 服務（WS-security）已經具有執行傳輸和消息級別安全性的選項。當然，這取決於您是否足夠信任或者您想使用自己的協議。我之前選擇生成自己的實現（由於缺少安全審查），但通常最好信任維護良好的現有庫。