使用通道加密（https）是否使散列密钥冗余？

Question

我正在设计一个客户端连接到的Web服务，以便检索一些私有数据。每个客户端都有一个唯一的ID和一个密钥（由服务器生成），它们作为参数发送到Web服务以进行身份​​验证。此外，所有通信都通过HTTPS完成。

我还计划使用HMAC-SHA256，以避免通过线路发送密钥。

但是，我想知道这是否是绝对必要的。由于HTTPS为我提供了客户端和服务器之间的安全通道，为什么我真的会介意通过该通道发送密钥？

我设法提出的唯一原因是，一个不可知的开发人员可能在将来添加服务而不拒绝非HTTPS连接，因此散列密钥是对企业软件开发现实的一种保险，如果你愿意，还有额外的防线。

我错过了更重要的事情吗？这是一个真正的漏洞，某些攻击媒介可以利用它吗？

Answer 1

• 攻击者将虚假的可信证书安装到浏览器中并劫持会话。
• 发送了指向您网站的链接，但拦截了重定向到SSL并开始了非SSL会话。

还有其他人，但故事是这样的：SSL很复杂，经常以创造性的方式受到攻击。如果您的连接是安全的，那么与人类代码的复杂性和cpu时间的成本相比，散列几乎没有价值。但是，如果SSL会话遭到破坏，那么您仍然保存了密钥。就像我们在数据库中散列密码一样，尽管没有人不应该有访问权限，但是尽管SSL是明智的，但是对你的密钥进行哈希处理。

Answer 2

频道可能是安全的，但这并不会告诉您有关端点的任何信息：取决于相关浏览器（及其插件/扩展程序/ ...） ），你的密钥很可能最终会在用户计算机上的某个基于磁盘的缓存中结束，它可能会一直存在，直到永远结束。

这不是一个非常有趣的漏洞...直到你意识到各种恶意软件已经在磁盘中搜寻，寻找任何有价值的东西 - 并且使用当前的速率，你的一些用户将成为感染（除非您的网站只有20个用户;）。）

所以：不要丢掉一个非常强大的加密机制来节省一些CPU周期;这是一个潜在危险的微观优化IMNSHO。