SSL +额外的加密层
我想知道如果客户要求在 SSL 之上进行第二层加密该怎么办？
例如，我有一个 SSL 隧道，客户希望我对流经该隧道的数据使用对称密钥加密。对称密钥是基于会话的，并通过原始 SSL 隧道从服务器发送到客户端。
我不明白这如何更安全。如果 SSL 隧道被泄露，那么理论上，从服务器发送来在会话期间进行对称加密的对称密钥也会被泄露。
任何人都可以对这种情况提出不同的观点吗？我确信，如果事先建立了共享秘密（例如一次性密码），这将使事情变得更安全，但由于秘密是通过 SSL 在会话中传递的，所以我看不到它如何为我们带来额外的安全感。
你有什么想法，你有过类似的经历吗？
谢谢
I'm wondering what to do in the case of a customer asking for a second layer of encryption on top of SSL?
For example, I have an SSL tunnel, and the customer wants me to then use symmetric key encryption on data flowing through that tunnel. The symmetric key is session-based and sent from the server to the client over the original SSL tunnel.
I am failing to see how this is more secure. If the SSL tunnel is compromised, then in theory, so is the symmetric key that is sent from the server to do the symmetric encryption during the session.
Can anyone offer any different viewpoints on this situation? I'm sure that if there was a shared secret established before-hand (like a one-time password), that this would make things more secure, but since the secret is being passed across the session over SSL, I don't see how it's buying us any extra security.
What are your thoughts, and have you had any similar experience?
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来像是客户的“下一个好主意”，他们认为阅读“我的第一个加密货币”使他们能够以某种极其聪明的方式重新发明轮子:)
这样的事情通常是无稽之谈，更是如此，因为正如你所说，对称密钥已发送沿着。
但是，我可以想到一种可能有意义的场景 - 许多大公司或机构都有禁止端到端 SSL/TLS 连接的策略。它们会在某个时刻终止传入的 TLS，以便能够扫描纯文本数据是否存在病毒等。在这种情况下，在应用程序级别对数据进行额外加密以防止内部窃听可能是有意义的。
但话又说回来，你可能会违反内部规定......
Sounds like the "next great idea" of customers who think reading "My first Crypto" empowers them to reinvent the wheel in some fiendishly clever way :)
Such a thing is usually nonsense, ever more so because as you say the symmetric key is sent along.
However, I can think of one scenario where this might make sense - a lot of large companies or institutions have policies that forbid end-to-end SSL/TLS connections. They terminate incoming TLS at some point in order to be able to scan the plain text data for viruses etc. In such a case it might make sense to additionally encrypt the data on the application level to prevent internal eavesdropping.
But then again you're likely to break internal regulations...