Vic*_*scó 0 security https sha
我正在创建一个通过HTTPS进行通信的Web服务.
安全性对我来说非常重要,因为我无法接受修改后的数据,因此我正在考虑添加消息diggest(签名)以检查完整性......但它是否需要通过HTTPS进行？
HTTPS已经有足够的签名来防止意外修改.
没有秘密的直接消息摘要无法防止故意篡改.一个活跃的中间人攻击者可以轻松地用自己的值替换摘要,重新计算以匹配他们所做的任何改动.
如果签名具有防止篡改的价值,则必须使用发件人上的密钥创建签名,并且签名必须在接收方上可验证,这意味着您必须有一种方法在使用前在各方之间预先交换密钥.
对于客户端是通用Web浏览器的情况,没有渠道可以做到这一点,除了通过HTTPS传输它,此时交互同样容易受到中间人攻击,你什么也得不到.这是一个引导问题.
对于您拥有自定义应用程序客户端的情况,您已通过比HTTPS更可信的渠道(例如,您实际上将其交给代码的副本)分发给您的用户,然后是,基于公钥添加服务器到客户端签名加密理论上可以提供一些价值.但滚动自己的加密容易出现实现错误,最好避免.
你在这里试图解决的攻击是什么,HTTPS与商业CA基础设施一起解决不够好？
如果您担心商业CA的PKI在历史上偶尔会出现欺诈性颁发的证书和州级间谍,那么更简单的防御方法就是运行您自己的私有CA以供应用程序使用,并让您的客户端仅接受该CA颁发的证书(而不是像Verisign等人那样构建在系统中的证书).
无论是通过运行CA还是临时签名检查,安全有效地运行您自己的PKI都是一堆持续的开销.确保公共商业PKI在走这条路线之前真的无法满足您的需求.