创建任何类型的应用程序web，api等;目前，最佳做法建议使用TLS保护端点，但我们可以从cloudbleed问题中了解到，这可能还不够。
因此，我想知道即使TLS遭到破坏，可以采取哪些措施来保持一定程度的安全性。
对于Web应用程序，我目前使用的是jsencrypt，基本上在发送之前对客户端浏览器端的所有数据进行加密，但为了达到此目的，我首先要在之间交换共享密钥（令牌/ cookie）服务器和客户端，但在处理不支持javascript的API时可以使用什么？
关于令牌的交换，通过本能可以明显地说使用OAUTH，OpenID Connect，json tokens，但是所有这些都需要或委托对TLS的信任，并且当它被泄露时再次使用它变得无用。
如果我是对的，可以在没有SSL的情况下使用OpenID通过Diffie–Hellman key exchange分享“共同秘密”，是否有类似的东西可以实现，请记住，如果TLS受到损害，可以采取简单的措施比如撤销令牌或更改“salts”？
目前我认为通过跟随gpg或rsa（私有/公共）密钥是可行的方式，可能每个人都可以访问公钥，但无法查看某些数据的内容签名给特定用户。
但问题仍然是如何在客户端和服务器之间交换第一个“已知秘密”，避免可能man in the middle attack考虑TLS不可信任。
答案 0 :(得分：1)
交换第一个“已知秘密”的问题对于所有协议是否相同，SSL与否。 SSL是一种公钥基础结构，其中需要分发的基本信息是证书颁发者的根证书的公钥。所有ssl证书颁发者的公钥都随浏览器安装一起分发。
任何协议都将取决于服务器和客户端之间在与建立通信的通道不同的通道中传递的某些信息。如果您不信任SSL基础结构，则必须通过电子邮件，邮件，短信或其他方式发送此信息。
但是，您的问题不是从您在Web应用程序中使用的加密库所需的密钥开始。您的Web应用程序（javascript文件）也通过SSL从服务器发送到Web浏览器。如果您的SSL通信受到中间人的影响，那么这个中间人也可能会更改您发送到浏览器的网页和JavaScript代码。他可以重写您的应用程序并删除所有加密代码，为用户添加新字段和消息，将用户发送到其他站点等等。
SSL基础架构确实是Web安全的基石，也是Web应用程序的必需品。没有它，您将不得不构建一个自定义协议来发送加密的网页，并编写一个可以理解该协议的自定义浏览器。
尽管如此，当然可以在SSL之上添加一小块额外的安全性。您可以为每个用户创建一个私钥/公钥对，向用户发送一个公钥，并使用私钥加密从服务器到用户的所有消息。这可以防止主要中间人能够收听通信但无法更改您的消息的情况。