我们有这个具有高价值（业务）数据的网络应用程序。
所有通信都通过 TLS/SSL 加密。虽然我认为这是一个非常安全的协议，但如果有人设法在我的计算机上安装了恶意 CA 证书，它仍然会受到损害。
由于我们有基础设施，我们希望通过预共享密钥（通过 SMS）加强相互认证。
（我不想发明一些东西，但正如我所见，应该使用 PSK 来加密底层流。也许周围的 SSL 甚至会是开销，但同样，我不是想发明自己的协议）
有谁知道浏览器是否支持预共享密钥加密/身份验证？也许通过插件？我在网上搜索过，没有发现任何关于浏览器支持的信息。
目前，似乎现有的主流浏览器都不支持TLS-PSK，也不支持TLS-SRP。在您的情况下，两者都适用，但 SRP “更强”，因为它可以更好地容忍低熵共享密钥（例如密码）。在使 Chrome SRP 感知方面进行了一些初步努力。我不知道它走了多远。由于 PSK 提供的所有东西都可以由 SRP 完成，并且可以说以更好、更强大的方式完成，因此浏览器在获得 PSK 支持之前获得 SRP 支持是合理的。但它还没有完成。
同时，您可以有一些部分解决方法：
让您的用户使用具有特定配置文件的 Firefox。Firefox 配置文件尤其包括浏览器将用于验证服务器证书的根 CA 集；让他们使用仅包含您自己的 CA 的“空”配置文件。
让用户通过 VPN 连接。特别是 SSH 隧道：SSH 可以用作 SOCKS 代理，可以指示浏览器将其用于每个连接。SSH 的公钥模型是无 CA 的；每个用户决定他接受或不接受哪个密钥。
将Web应用程序变成安装在客户端系统上的真正的、成熟的应用程序。然后，该应用程序将与您的服务器进行 SSL，然后可以选择它希望使用的任何身份验证机制。
不要做任何事情：这是客户的问题，而不是你的问题。
最后一个“解决方法”值得一些额外的思考。实际上，潜在的流氓 CA 的问题在于这些 CA 受客户端信任。在成功的中间人攻击中，攻击者伪装成假服务器，客户端与攻击者交谈，而不是与您交谈。因此，作为第一个近似值，您在服务器中无法做任何事情来改变客户端和攻击者之间发生的事情。在 SSL/TLS 中，客户端宣布它愿意使用的所有密码套件，然后服务器选择一个。即使您的服务器想要使用 SRP 或 PSK，您也可以打赌攻击者的服务器会更喜欢其他密码套件。
因此，假设您找到了一个支持 SRP 的浏览器，那么针对中间人攻击者（可能贿赂 CA）的连接的安全性不依赖于您在服务器上使用 SRP，而是依赖于人类用户：肉袋必须期待SRP（或 PSK）并在他没有得到的情况下称犯规。只有当人类用户出现绿色挂锁和带有您的徽标的漂亮登录页面并要求他通过短信获得的密码时，MitM 才会被击败，他会对自己说：“嘿，这是一个网页，而不是浏览器弹出窗口！” 然后拒绝连接。如果您可以让您的用户以这种方式可靠地做出反应，那么您可能可以训练一只猫洗衣服并用真空吸尘器清洁地毯（然后我对您的服务非常感兴趣）。
这相当于有点令人沮丧的以下总结：如果您的用户信任流氓 CA，那么他们已经被水洗了；您的服务器无法真正保护它们。第一步是教他们不信任现有的 CA，这将带来保护（假设他们的机器尚未被劫持），但从他们的角度来看也会“破坏 Internet”。
如上所述，使用 VPN 添加一层安全性可能是最容易的。看看例如https://openvpn.net/index.php/open-source/documentation/howto.html
创建和共享密钥并设置 VPN 后，您可以确保您的应用程序连接到服务器的 VPN IP，而不是公共（互联网）IP。使用此设置，您甚至不需要设置代理或任何东西。