是的，使用了 HTTPS。该线程并没有说网络应用程序将完全不安全，而是说

这有效地将端到端加密通信的安全性降低到与服务器的 SSL 连接的安全性

这意味着任何可以控制与服务器的 SSL 连接的人现在都可以拦截和窃听您的 e2ee 通信。那么究竟谁能控制 SSL 连接呢？

好吧，如果（可能是州级）攻击者控制/破坏 CA，他们可以为 Signal 服务器颁发欺诈性证书并尝试 MitM SSL 连接（通过使用证书透明性，这种威胁是有限的，但不能消除.) 正如@multithr3at3d 指出的那样，工作场所的 TLS 检查代理更有可能是 MiTM 的一种形式，如果您的雇主有兴趣破坏您的私人谈话，则可能会导致问题。然而，在这种情况下，雇主拥有这台机器，可能只会在上面安装一个键盘记录器，所以你会有更大的问题。

但是，这里更大的问题是 SSL 连接以及所服务的内容是由 Signal 服务器控制的。这意味着，如果服务器遭到入侵或流氓（这可以通过政府发出传票等信号轻松实现），那么它可以轻松修改提供给客户端的 javascript 文件，从而允许他们拦截通讯。这有效地破坏了端到端加密的要点，即除了发送者和接收者之外，没有人应该能够读取通信的内容，因为服务器现在有能力随意破坏通信。

可以有针对性地对所服务的代码进行此类恶意修改这一事实放大了这种威胁。服务器可以确保只为特定用户/客户端提供修改后的恶意代码。这显着降低了修改被检测和暴露的机会。

实际上我们想开发一些聊天服务，比如带有网络客户端的信号，但是这篇文章让我们对我们是否应该发布一个网络客户端感到困惑，谁能解释一下吗？

这取决于您的威胁模型（或者更确切地说是您的聊天服务的目标受众的威胁模型）。这些人会只是用它来与朋友聊天或与同事交流吗？还是会被试图与记者协调披露机密信息的举报人使用？您将不得不考虑风险是否大于收益，并自行决定是否发布 Web 客户端。

如果是前者，那么拥有 Web 客户端将不是什么大问题。这更接近 WhatsApp 的用例，并且 WhatsApp 确实有一个 Web 客户端。

如果是后者，那么您最好遵循 Signal 并坚持使用可以签名并验证其完整性的桌面客户端和应用程序。

从评论中可以明显看出，有些人对为什么这些问题不适用于应用程序和桌面客户端感到困惑。

原因很简单。应用程序/桌面客户端必须下载一次。它还经过数字签名，因此可以轻松验证其完整性。代码签名密钥可以分配给可能位于不同司法管辖区的多个开发人员，这样一个流氓开发人员就不能自己发布恶意更新。如果你偏执，你也可以下载 Signal 公开的源代码并自己编译，然后禁用自动更新。如果 Signal 尝试发布恶意更新，他们也必须发布其源代码，并且在任何损害发生之前有人会注意到无法解释的更改的可能性要高得多。

有了网络应用程序，事情就没有那么简单了。首先，TLS 密钥始终存在于服务器上，因此任何有权访问的人都可以窃取它，并且单个政府可以通过传票获得对它的访问（不像拆分代码签名密钥，这需要多个政府的协作如果开发者在不同的国家）。即使网页经过数字签名，手动检查它们的完整性并确保它们每次都与公开可用的源代码相匹配是绝对不切实际的。其次，一个网络应用程序由几个网页组成。即使检查一次所有这些的完整性也是一项艰巨的任务。

不得不不同意这里的最佳答案。为 Signal 创建一个相当安全的 Web 客户端是完全可能的。如果在客户端进行加密，那么 SSL 连接是多余的，完全没有必要。包验证也可以在客户端以安全的方式完成。

真正的答案是，还需要大量资源来编写和维护 Web 客户端，并且目前生态系统不支持经济。如果这种情况发生变化，同样安全的 Web 客户端将很有意义。