我觉得.NET缺乏一个简单安全的自动更新库，所以我实现了一些东西并放在这里。在任何人考虑使用该库之前，我都很希望更新过程能够获得同行的审查。
数字签名支持
所有代理的支持。某些大公司有复杂的代理配置（例如通过代理配置脚本）。您应该支持所有这些。
加密支持。您的客户可能希望在Web服务器上提供已部署的二进制文件，并且他们不想管理某种身份验证或访问控制；但他们也不希望未经授权的用户下载二进制文件。一个简单的解决方案是加密二进制文件并让您的工具进行部署。
可插拔附加步骤的支持。企业客户通常不太喜欢使用自动部署工具。他们将希望更多的控制权。通常，允许他们运行可定制的步骤（如反病毒检查等）会有所帮助。
根据消费者标识支持不同版本的软件。这在企业环境中经常需要，当您希望非常快速地更新特定消费者的副本（以修复错误或添加额外功能）而不运行所有Q&A过程时（在这种情况下，您希望将更新限制为该特定消费者）
支持有限权限的情况。除了您的用户可能缺乏对其计算机的管理员访问权限外，大公司通常使用特定工具来限制您可以执行的操作。准备在用户拥有的文件夹（甚至是临时文件夹）中部署，而不是经典的“程序文件”。
您的工具应由强认证机构签名。
关于您提到的MITM攻击，通过使用公共加密技术（如未知人士所述），很容易解决。
你可以尝试通过在“无版本更新”响应中包含时间戳（并签名）来防止中间人攻击。然后，如果一个月过去了（或任何你的策略），没有版本更改和时间戳更新，那么你会拒绝运行软件或弹出警告对话框，通知用户可能存在中间人攻击。
这并不能解决如果服务器崩溃时该怎么办的问题 - 大概您会将其视为没有时间戳更改的情况。
不是要在这里充当骗子，但你正在尝试解决一个已经解决的问题。使用SSL会是一个更好的选择。这将解决您问题中列出的所有问题。
我知道这个系统对于不能负担SSL证书的人可能很有用，但任何能够获得证书的人都应该获得一个来解决这个问题。
别忘了，“复杂性是安全的敌人”。
这篇文章中有一些非常好的评论和解决方案。但我非常同意恶棍博士的观点。您应该使用SSL连接来进行更新，并且证书必须保存（建立在）客户端中。这样，您可以确保客户端不会接受伪造的证书。我认为这将有效地使客户端免受中间人攻击。
注意：如果客户端可以接受未经授权的证书，那么中间人攻击可能会成功，因此不要向客户端提供此选项。
编辑：我认为在这种情况下SSL证书可以自签名。
另外，还要在下载的文件中添加MD5校验和，否则看起来很好 :) - 下面是公正的评论。
补充：
我唯一能看到的额外事情就是深入研究诸如混淆代码、归档安装文件并锁定存档，然后一旦下载，解锁它。不过我认为你目前所做的应该已经足够了。
只有当应用程序非常安全复杂时才需要更多。现在，您可以防止DLL篡改和源头证明，这对于自动更新程序来说应该已经足够了。
所以我不太清楚一个问题；下载器通过签名验证清单是否符合预期，那么它对安装的实际补丁是否也进行同样的验证呢？
