Lighty
2016-03-15 13:57:39 UTC
如果我有一個網站或移動應用程序，它通過安全的SSL / TLS連接（即HTTPS）與服務器對話，並在已經安全的連接之上對用戶和服務器之間發送和接收的消息進行加密，我會做不必要的舉動嗎？還是雙重加密是常見的方法？如果是這樣，為什麼？
原因之一是要利用高效的雙重“ ROT13”加密算法。
您可能需要不同級別的加密-您希望對用戶的文本消息進行加密，以便只有收件人才能閱讀它，並且還希望對攜帶該文本消息的協議消息進行加密，以便只有您的服務器才能閱讀它。
與TLS相比，某些舊版應用程序可能已經在與TLS不同的通道上使用了自己的加密。當開發人員將其轉換為TLS時，他們可能不想通過刪除舊的加密層來引入新的錯誤可能性。
@Keavon終極的中間相遇攻擊！
@DmitryGrigoryev如何在沒有密鑰的情況下進行中間相遇攻擊？
對於從用戶到服務器的所有消息的加密，可能存在預定義的安全性要求。該要求可能更高，或者以某種方式與HTTPS不完全匹配。為了獲得更多的控制權，並能夠指向“完全”滿足規範X款中對審閱文件的要求的一段代碼，這對於開發人員而言可能是最簡單的選擇。
@immibis如何兩次應用ROT13並假裝文本已加密？
@DmitryGrigoryev-正是出於您要問的原因，這是關於無效的安全性的一個老笑話-聽起來不錯，但完全沒有用。
為什麼要看問題。如果問題是傳輸中的攔截，那麼可以說HTTPS就足夠了。如果問題是在終止HTTPS的任一端點上攔截，則HTTPS不提供保護。如果移動應用程序存儲了敏感信息並且遭到了洩露，那麼存儲在應用程序中的數據也會被洩露。如果該數據被加密，則即使該應用程序遭到破壞，它也會為數據添加一層保護。我對密鑰管理不屑一顧，這裡涉及到的問題是因為雙重加密似乎不是主題。
-1
請求參數可能最終出現在服務器訪問日誌中，這可能是不可取的，因此對它們進行加密可能會有所幫助。
我在某處讀到，雙重加密DES實際上“降低”了加密的安全性，這就是為什麼Triple-DES成為標準的原因。
@Keavon Pshaw，我做10,001發ROT13發，因此攻擊者必須花更多時間才能找回純文本。 IFNKOVHGROGHPRM！
TLS僅從您到服務器加密。服務器獲取純文本。如果您存儲的是加密的數據，則服務器將無法解密數據。他們只能為您存儲。因此，在TLS內部進行加密不是“雙重加密”，因為從保護您免受服務器管理員的角度來看，TLS根本沒有對它進行加密。
除了這些註釋以及在某些答案中提到的以外，SSL / TLS只是指向安全性而不是指向安全性。儘管存在細微差別，但惡意實體可以MitM進程（例如Bluecoat），解碼SSL流，然後重新啟動與服務器的連接。
通過不信任空間（也稱為Internet）進行的某些通信必須通過另一個IPSEC內的IPSEC隧道進行雙重包裝，使用帶有不同密鑰的IPSEC的兩種不同實現，這樣，對外部包裝實現的成功攻擊只會揭示出進一步的加密層。使用同一漏洞無法攻擊。
可以確定...
從歷史上看，二戰時德國人使用的Enigma機中的薄弱環節之一是他們決定對所有事物進行雙重加密時。第二次加密引入了人腦可見的模式，使加密更容易破解。
考慮發送HTTPS流量時使用VPN隧道，同時發送帶有小型truecrypt卷附件的PGP加密電子郵件，該附件包含服務器的加密備份，該備份保存用戶數據庫（敏感值經過加密，而不是以明文形式自由顯示）通過全盤加密存儲在HDD上。這裡有許多合法的“雙重加密”示例，儘管公認的現實生活很少像包含至少六層加密的示例那樣令人費解。
@SplashHit [triple-des]（https://zh.wikipedia.org/wiki/Triple_DES）旨在提供與常規DES的向前和向後兼容性，而不是因為“兩個還不夠”。
@pojo-guy得到了一個鏈接？
-1
-1
也許您正在考慮在更改消息正文之前如何兩次列出會話密鑰？那是使它被破解的關鍵缺陷！它不是雙重編碼的。它在同一流中重複進行。像rot13一樣，加密和解密實際上是“相同”過程。所以，是的，我想如果使用相同的插件設置但使用不同的轉輪設置來進行雙重編碼，就會產生大量的輪胎信息。我不記得我讀過的歷史。
也許他們擔心該頻道可能會被降級，因此希望獲得額外的安全性