使用RSA加密在兩種方式下在瀏覽器和服務器之間安全地傳輸大量數據是否可行？

Question

對於高度安全的Web應用程序，使用2048位RSA加密來加密在客戶端和服務器之間來回發送的所有重要數據是否可行？ 假設（加密之前）來回發送千字節到兆字節的數據，使用這種類型的加密會導致性能損失？

最后，我將如何（如果我有通用模型，就可以編寫代碼）讓服務器將服務器到客戶端的解密密鑰和解密引擎發送給客戶端，而又不影響當前和將來會話的安全性（例如，會話的另一個用戶）同一應用程序將無法攔截第一位用戶的數據，並將其會話中存儲在其計算機上的信息用於解密第一位用戶的數據，並且惡意的人也將無法攔截和使用第一位用戶的數據。用戶的解密密鑰和引擎來完成相同的任務）？

Answer 1

鑒於現代的處理能力，這樣做當然是可行的 ，但是出於以下幾個原因，這是一個壞主意。

首先，您可以使用證書對服務器進行身份驗證，但是客戶端呢？ 您可以使用客戶端證書（管理起來很麻煩），也可以每次（緩慢）在客戶端生成密鑰對，並在建立安全會話后使用密碼對客戶端進行身份驗證。 另一方面，AES只需要一個短鍵，並在現代x86和AMD處理器的指令集級別提供支持。

其次，從您因為需要“非常安全密集型解決方案”而考慮使用RSA的事實來看，您應該知道RSA-2048實際上不如AES-128安全。 2048位的RSA密鑰相當於大約112位的對稱密鑰強度。 看這里 。

最后，通常使用非對稱方案（例如RSA或DHKE）解決AES等對稱方案中的密鑰交換問題。 因此，您應該做的是使用公共加密方案交換對稱密鑰，然后對其余數據使用強對稱密碼-這正是TLS所做的。

HTTPS是最著名的應用程序層協議-它在TLS之上堆疊HTTP。 TLS得到廣泛支持， OpenSSL可能是當今使用最廣泛的庫，並且在所有主要平台上均受支持。

編輯1：銀行不只是應用SSL安全性，因為它們意識到SSL並不能解決所有問題-有些問題本來就無法解決。 例如，它對於網絡釣魚或會話竊取沒有用。 銀行身份驗證機制的目的不是檢查與之交談的人是否知道密碼，而是檢查該人是否為您。 這還意味着確保連接來自可識別的IP地址，有時使您回答安全問題，並要求您使用所謂的SiteKeys來確保識別銀行網站。

編輯2：您不能確保該信息未被第三方攔截。 您所希望的最好的是，它們無法將您的數據與完全隨機的字節流區分開，這是每個網絡安全協議的目標。 有些方案還嘗試隱藏實際的源地址和目標地址，例如IPsec，但這並不常見。

Answer 2

如果要構建Web應用程序，並且需要在Web服務器和瀏覽器之間傳輸敏感信息，則應該使用SSL。 它實際上是按照您在問題中描述的內容進行的。

有關其工作原理的更多信息，請參見HTTPS 。

使用2048位加密的SSL證書非常可行，並且一直都在進行。 較大的密鑰可能會產生更多的延遲，但是以我的經驗，由於密鑰大小而導致的延遲可以忽略不計。 我會更擔心每個頁面加載數百萬字節的數據。

有點相關： 使用4096位加密的SSL證書有什么缺點嗎？

當然，如果您的問題是關於加密服務器端的數據，將其發送到瀏覽器並在瀏覽器端解密的：我的建議不是 。 考慮一下此解決方案的目標。 它試圖解決的唯一問題就是中間人 ，SSL已經為您解決了這一問題。 此外，您在瀏覽器上執行的任何操作本質上都是不安全的，因為它可以由客戶端修改，因此無論如何該解決方案都是不安全的。

最后一段表明您對防止sql注入和會話劫持感到擔憂。 這些應該作為單獨的問題發布，但是足以說明您無法通過加密數據傳輸來解決這些問題。

Answer 3

為了獲得良好的答案，您必須提供“可行”一詞的定義。 可能有可能做到這一點（您可能會遇到需要很好的隨機性而瀏覽器中的javascript無法提供這種問題的問題），但是這樣做的速度將非常緩慢且笨拙。

非對稱加密提供了許多不錯的功能，但性能並不是其中之一。 在使用非對稱來交換對稱加密密鑰，然后將其用於加密和解密大量數據的情況下，傾向於使用混合方法。 這就是瀏覽器中HTTPS的工作方式。

說到瀏覽器，如果要創建一個Web應用程序，為什么不利用瀏覽器已經提供的SSL保護呢？ 如果您不信任瀏覽器SSL來保護數據，那么就不能信任它來保護服務器向下發送給客戶端的javascript代碼。

Answer 4

否。如果您使用RSA加密/解密客戶端和服務器之間的數據。 會很慢。

取而代之的是：1.使用RSA密鑰對來加密/解密會話密鑰。 2.使用該會話密鑰對客戶端和服務器之間傳輸的數據進行加密/解密。 （因為會話密鑰是對稱密鑰，所以它會更快）。3.由於它是一次性使用的，因此不會影響當前和將來會話的安全性。

請看一下： http : //en.wikipedia.org/wiki/Session_key