假设我的页面没有 SSL。让我们假设以下步骤：
用户向我的网页发出请求（我们称之为 www.mypage.com）。
客户端 JS 制作一个对称密钥。
客户端JS向我的后端页面发出请求，请求我服务器的PUBLIC KEY。
客户端JS对之前生成的PUBLIC KEY中生成的SYMMETRIC KEY进行加密。
客户端JS将ENCRYPTED数据发送到SERVER。
服务器对接收到的数据进行解密。
服务器开始发送/读取在步骤 2 中生成的 SYMMETRIC KEY 中加密的所有后续信息。
客户端 JS 也开始发送/读取在步骤 2 中生成的 SYMMETRIC KEY 中加密的所有后续信息。
据我所知，即使攻击者监听了步骤1到步骤8的每一条信息，他们也无法解密任何内容，用户是安全的。
你们同意我的观点吗？我对么？如果是，我们是否可以假设浏览器中的本机 SSL 存在是因为“写得不好”的页面？
TlS 是为了防止中间人攻击者，该攻击者可以拦截并修改客户端和服务器之间的通信。让我们看看这个建议的方法在这种情况下是如何工作的。
客户端 JS 制作对称密钥。
这个客户端JS首先来自哪里。希望不是来自服务器，因为不能保证攻击者没有修改它。但假设这是通过某种安全连接传输到客户端的......
客户端JS向我的后端页面发出请求，请求我的服务器的PUBLIC KEY。
由于对服务器的此请求未受到拦截和修改的保护，中间人攻击者可以简单地用自己的公钥替换公钥并将其发送到客户端。由于客户端没有对公钥进行任何验证（即没有对服务器进行身份验证），因此它将接受它。
从此客户端将相信与服务器交换对称密钥和加密流量，而实际上是与攻击者交换。攻击者可以解密对称密钥和流量，并由此建立自己与服务器的连接，这次使用来自服务器的原始密钥。
总之：您缺少 TLS 的一个关键点 - 服务器身份验证。这样就可以让中间活跃的人轻松突破防护了。
请注意，您的方法存在更多缺陷，例如没有前向透明度。但缺少服务器身份验证是最明显也是最关键的问题。