服务器如何知道请求来自客户端，而不是窃听黑客？
How can a server know the request is coming from client, not an eavesdropping hacker?
我有一个简单的问题，但找不到简单的答案，可能是我遗漏了什么，或者我不知道某些网络概念是如何工作的。我想知道我不知道的事情。
简单地说，问题是虽然窃听是可能的，但服务器如何知道请求来自客户端，而不是窃听的黑客。
场景：
无论我有什么安全策略，我都应该向客户发送一些东西。它可能是一个非对称加密令牌或某物。客户端没有私钥，因此无论客户端能够做什么，发送等等，黑客也可以做，发送。
保护 Web 应用程序背后的逻辑可能是什么。应该有一些只有客户知道的秘密。
顺便说一句，我正在学习 JWT，这是我第一次学习 auth。但是这个简单的问题是我仍然无法找到答案的。
的确，在建立新连接时，只有客户端知道。
这就是为什么
Diffie–Hellman 密钥交换
并发明了类似的方法。
他们通过在服务器和客户端之间发送问题和答案来工作。
使用（实际上）不那么复杂的数学方法多次这样做，客户端和服务器可以共享一个只有他们知道的密钥，即使第三方拦截了流量。
我无法完全解释这个概念，但我可以推荐 this StackExchange 问题，它将很好地概述该主题。
编辑：我现在才听说 JWT，所以这个答案可能完全断章取意。
查找 Diffie-Hellman 和 SSL/TLS 加密。这是让您入门的东西。
https://blog.hartleybrody.com/https-certificates/
简短的回答是，当客户端启动到服务器的连接时，他们共享一个不公开的密钥。问题是，客户端需要与它认为要连接的服务器建立初始连接。
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
How can a server know the request is coming from client, not an
eavesdropping hacker?
没有。
由客户端验证服务器是否是它期望与之通信的服务器。它被称为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 并且设置了 Secure Flag，则它只能通过 HTTPS 连接传输。这就是服务器知道它没有被拦截的原因，因为客户端已经验证了服务器并使用双方同意的唯一密钥对传输给它的数据进行了加密。
Client --> HTTPS --> Attacker (fake example.com) --> HTTPS --> example.com
也是不可能的（活跃的中间人），这显示了您原始问题中的情况，即有人拦截通信并将 JWT 传递给真实服务器，观察传输中的私有数据。但是，如果使用纯 HTTP（无 SSL/TLS）：
Client --> HTTP --> Attacker (fake example.com) --> HTTP --> example.com
我有一个简单的问题，但找不到简单的答案，可能是我遗漏了什么，或者我不知道某些网络概念是如何工作的。我想知道我不知道的事情。
简单地说，问题是虽然窃听是可能的，但服务器如何知道请求来自客户端，而不是窃听的黑客。
场景：
无论我有什么安全策略，我都应该向客户发送一些东西。它可能是一个非对称加密令牌或某物。客户端没有私钥，因此无论客户端能够做什么，发送等等，黑客也可以做，发送。
保护 Web 应用程序背后的逻辑可能是什么。应该有一些只有客户知道的秘密。
顺便说一句，我正在学习 JWT，这是我第一次学习 auth。但是这个简单的问题是我仍然无法找到答案的。
的确，在建立新连接时，只有客户端知道。 这就是为什么 Diffie–Hellman 密钥交换 并发明了类似的方法。
他们通过在服务器和客户端之间发送问题和答案来工作。 使用（实际上）不那么复杂的数学方法多次这样做，客户端和服务器可以共享一个只有他们知道的密钥，即使第三方拦截了流量。
我无法完全解释这个概念，但我可以推荐 this StackExchange 问题，它将很好地概述该主题。
编辑：我现在才听说 JWT，所以这个答案可能完全断章取意。
查找 Diffie-Hellman 和 SSL/TLS 加密。这是让您入门的东西。 https://blog.hartleybrody.com/https-certificates/
简短的回答是，当客户端启动到服务器的连接时，他们共享一个不公开的密钥。问题是，客户端需要与它认为要连接的服务器建立初始连接。
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
How can a server know the request is coming from client, not an eavesdropping hacker?
没有。
由客户端验证服务器是否是它期望与之通信的服务器。它被称为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 并且设置了 Secure Flag，则它只能通过 HTTPS 连接传输。这就是服务器知道它没有被拦截的原因，因为客户端已经验证了服务器并使用双方同意的唯一密钥对传输给它的数据进行了加密。
Client --> HTTPS --> Attacker (fake example.com) --> HTTPS --> example.com
也是不可能的（活跃的中间人），这显示了您原始问题中的情况，即有人拦截通信并将 JWT 传递给真实服务器，观察传输中的私有数据。但是，如果使用纯 HTTP（无 SSL/TLS）：
Client --> HTTP --> Attacker (fake example.com) --> HTTP --> example.com