自动更新：这样安全吗？
点网自动更新
我觉得.net缺少一个简单安全的自动更新库，所以我已经实现了一些东西并把它放在这里 。 在任何人考虑使用该库之前，我都热衷于更新过程以获得一些同行评审。
以下是步骤：
- 客户端软件填充有公钥和URI以进行轮询。
- 客户端轮询清单文件的URI。
- 下载清单并使用签名（在单独的“.signature”中）来检查清单是否有效。
- 从清单中解析待处理更新列表（向用户显示）。
- 下载安装程序文件，并再次使用相应的“.signature”文件进行validation。 （下载的文件将受ACL保护）
- 安装程序已运行。
减轻威胁：
- 清单签名应该可以防止任何恶意下载（“ 地毯式轰炸 ”）
- 安装程序签名应防止任何MITM攻击发送恶意安装程序
- 使用ACL保护下载的安装程序应该可以防止任何本地升级攻击。
未减轻的威胁：
- MITM攻击，攻击者始终报告“没有可用更新”。 （可能使客户端处于易受攻击的版本）
参考文献：
- 安全的软件更新：令人失望和新的挑战
- Black Ops 2008：它是我们所知道的缓存的终点
- 邪恶将毁灭我们所有人
我错过了什么？
Dan Kaminsky对更新程序有一套很好的指导方针：
要成功，您的更新包必须是：
- 签。
- 由你签名。
- 您使用正确的EKU（扩展密钥用法）签名
- 从未撤回的签名中签名
- 是同一个产品
- 成为新版本
根据您在此问题中的描述，您似乎拥有前3个。
在企业环境中构建自己的部署者，这里有一些我需要解决的用例：
-
支持数字签名
-
支持所有类型的代理。 一些大型团队具有复杂的代理配置（例如，通过使用代理配置脚本）。 你应该支持所有这些。
-
加密支持。 您的客户可能希望在Web服务器上提供已部署的二进制文件，并且他们不希望管理某种身份validation或访问控制; 但他们也不希望未经授权的用户下载二进制文件。 一个简单的解决方案是加密二进制文件并让您的工具部署它
-
支持可插拔的附加步骤。 企业客户通常不太习惯使用自动部署的工具。 他们需要更多的控制权。 通常，允许它们运行可自定义的步骤（如防病毒检查等）将有所帮助
-
支持基于消费者身份的不同版本的软件。 当您想要更快地更新特定消费者的副本（以修复错误或添加额外function）而不运行所有问答流程时（在这种情况下，您希望限制更新），企业环境中通常需要这样做对这个特定的消费者）
-
支持有限的特权情况。 除了您的用户可能缺少管理员访问其计算机的事实之外，大公司通常使用特定工具来限制您可以执行的操作。 准备好部署在用户拥有的文件夹（甚至是临时文件夹）中，而不是经典的“程序文件”。
-
您的工具应由强大的认证机构签署。
关于你提到的MITM攻击，它可以通过使用公共密码术轻松解决（如未知的那样 ）
好吧，您可以尝试通过“无版本更新”响应还包括时间戳（并签名）来防止MITM。 然后，如果一个月过去（或无论您的策略是什么）没有版本更改且没有时间戳更新，那么您拒绝运行软件或弹出警告对话框通知用户可能存在MITM攻击。
如果服务器出现故障，无法解决该怎么办的问题 – 大概你认为它与无时间戳更改一样。
不要故意在这里拖车，但你正试图解决已经解决的问题。 使用SSL将是一个更好的选择。 这将解决您的问题中列出的所有问题。
我知道这个系统对于那些买不起SSL证书的人来说非常有用，但是任何能够获得SSL证书的人都应该得到一个解决这个问题的人。
别忘了，“复杂性是安全的敌人”。
同样，添加一个MD5 CheckSum到下载的文件，否则，看起来不错:) – 下面的公平评论。
添加：
我在这里可以看到的另一件事就是深入研究代码混淆，或者归档设置文件和锁定存档，然后下载后解锁它。 那种事。 但是我认为你目前所做的应该是100％。
唯一需要的是应用程序非常复杂的时候。 现在你可以防止DLL篡改和原产地certificate，对于自动更新程序来说，这应该是充足的。
所以我不清楚某些事情; 下载程序通过签名validation清单是否是它所期望的清单 ，是否对它安装的实际补丁执行相同的操作？
这篇文章中有一些非常好的评论和解决方案。 但我非常同意博士。 邪恶。 您应该使用SSL连接进行更新，并且必须在客户端中保存（构建）证书。 因此，您可以确保客户端不会接受假证书。 我认为它将有效地使客户免受MiTM攻击。
注意：如果客户端可以接受未经授权的证书，则MiTM攻击可以成功，因此请勿将此选项提供给客户端。
编辑：我认为在这种情况下SSL证书可以自签名。