提问人：Victor Lucas Mazzotti 提问时间：10/3/2023 更新时间：10/3/2023 访问量：47
如果我在网页上实现类似于 SSL 的安全逻辑，这与使用 SSL 是否相同？
Is it the same as using SSL if I implement security logic similar to SSL on my webpage?
问：
假设我的页面没有 SSL。假设以下步骤：
用户向我的网页发出请求（我们称之为 www.mypage.com）。
客户端 JS 生成一个 SYMMETRIC KEY。
客户端 JS 向我的后端页面发出请求，请求我的服务器的 PUBLIC KEY。
客户端 JS 对之前在获取的 PUBLIC KEY 中生成的 SYMMETRIC KEY 进行加密。
客户端 JS 将 ENCRYPTED 数据发送到 SERVER。
服务器对接收到的数据进行解密。
服务器开始发送/读取在步骤 2 中生成的 SYMMETRIC KEY 中加密的以下所有信息。
客户端 JS 也开始发送/读取在步骤 2 中生成的 SYMMETRIC KEY 中加密的以下所有信息。
据我所知，即使攻击者正在监听从步骤 1 到第 8 步的每一条信息，他们也无法解密任何内容，并且用户是安全的。
你们同意我的看法吗？我说得对吗？如果是，我们是否可以假设浏览器中的原生SSL存在，因为“写得不好”的页面？
答：
3赞
Steffen Ullrich
10/3/2023
#1
TLS 是为了保护客户端和服务器之间的通信免受中间人攻击者拦截和修改通信的影响。这可能是ISP，可能是公共WiFi热点的所有者，也可能是LAN或WiFi热点中的攻击者，它使用ARP或DNS欺骗重定向您的流量。 让我们看看这种提议的方法在这种情况下是如何工作的。
客户端 JS 生成一个 SYMMETRIC KEY。
这个客户端 JS 首先来自哪里？希望不是来自服务器，因为不能保证攻击者没有修改它。但是假设这是通过某种安全连接传输到客户端的......
客户端 JS 向我的后端页面发出请求，要求提供我的服务器的 PUBLIC KEY。
由于对服务器的此请求不受拦截和修改的保护，因此中间人攻击者可以简单地将公钥替换为自己的公钥并将其发送给客户端。由于客户端没有对公钥进行验证（即没有对服务器进行身份验证），因此它将接受它。
从那时起，客户端将相信与服务器交换对称密钥和加密流量，同时实际与攻击者交换它。攻击者可以解密对称密钥和流量，并从中建立自己与服务器的连接，这次使用来自服务器的原始密钥。
总而言之：您错过了TLS的一个关键点 - 服务器身份验证。这使得中间活跃的人可以轻松打破保护。
请注意，您的方法中还有更多缺陷，例如没有前向透明度、没有消息完整性、没有重播保护。但是缺少服务器身份验证是最明显和最关键的问题。
如果是，我们是否可以假设浏览器中的原生SSL存在，因为“写得不好”的页面？
它内置在浏览器中，因为加密很容易出错，所以不要依赖用户自己做。它附带根 CA 作为信任锚，因为使用以前未知的远程方进行加密需要某种方法来验证该方是否确实是预期的方（您缺少的服务器身份验证），这是通过检查 TLS 中的服务器证书与内置的受信任根 CA 来完成的。
参见 为什么我们不应该自己滚动？ 为什么你不应该尝试发明自己的加密协议，而是依赖既定的标准。
评论