服务器如何知道请求来自客户端，而不是窃听的黑客？

我有一个简单的问题，我找不到简单的答案，可能我遗漏了一些东西，或者我不知道某些网络概念是如何工作的。我想知道我不知道的事情。

简单地说，问题是虽然窃听是可能的，但服务器如何知道请求来自客户端，而不是窃听的黑客。

设想 ：

无论我采用什么安全策略，我都应该向客户发送一些内容。它可能是非对称加密令牌或其他东西。客户端没有私钥，因此无论客户端能够做什么、发送等，黑客也可以做什么、发送。

保护 Web 应用程序背后的逻辑可能是什么？应该有一些只有客户知道的秘密。

顺便说一句，我正在学习 JWT，这是我第一次学习 auth。但这个简单的问题我仍然无法找到答案。

服务器如何知道请求来自客户端，而不是客户端 窃听黑客？

事实并非如此。

由客户端来验证服务器是否是它期望与之通信的服务器。它被称为公钥基础设施 https://en.wikipedia.org/wiki/Public_key_infrastructure.

可以使用 TLS/SSL，因此连接是通过 HTTPS 进行的 - 请注意，它不必是 Diffie Hellman，还有其他密钥交换机制，例如 RSA。

想象一下以下场景。

Client --> HTTPS --> example.com

客户端将对 example.com 进行 DNS 查找，并返回 203.0.113.10。客户端将通过 HTTPS 连接到 203.0.113.10，连接的初始部分称为握手过程。在这里，客户端检查它正在考虑连接的域 example.com 是否拥有由受信任的证书颁发机构签名的证书，主题设置为“example.com”。这将防止发生以下情况：

Client --> HTTPS --> Attacker (fake example.com)

例如，如果攻击者接管了 DNS 服务器并将 example.com 更改为指向他 (198.51.100.200)。

这种攻击之所以能被阻止，是因为攻击者无法向证书颁发机构证明 example.com 的所有权，因此无法对其证书进行签名以向客户端证明其服务器是可信的。

HTTPS 还对连接进行加密，并以安全的方式交换密钥。这可确保无法读取已建立的连接。

因此，一旦建立连接并且用户登录，服务器就会向客户端发送会话令牌，该令牌可以采用 JWT 的形式。如果这是一个 cookie 并且安全标志 https://www.owasp.org/index.php/SecureFlag设置后，只能通过 HTTPS 连接进行传输。这就是服务器知道它没有被拦截的原因，因为客户端已经验证了服务器，并使用双方同意的唯一密钥对传输到服务器的数据进行了加密。

Client --> HTTPS --> Attacker (fake example.com) --> HTTPS --> example.com

也不可能（主动中间人），这显示了您最初问题中的情况，其中有人拦截通信并将 JWT 传递到真实服务器，观察传输中的私有数据。然而，如果使用纯 HTTP（无 SSL/TLS）：

Client --> HTTP --> Attacker (fake example.com) --> HTTP --> example.com