我有一个简单的问题，我找不到简单的答案，可能是我遗漏了一些东西，或者我不知道某些网络概念是如何运作的。我想知道我不知道的事情。
简单来说，问题是当窃听成为可能时，服务器如何知道请求来自客户端，而不是来自窃听黑客。
场景：
无论我有什么安全政策，我都应该向客户发送一些东西。它可能是一个非对称加密令牌或某事。客户端没有私钥，因此无论客户端能够做什么，发送等等，黑客都可以做，也可以发送。
保护Web应用程序背后的逻辑可能是什么。应该有一些只有客户知道的秘密。
顺便说一下我正在学习JWT，这是我第一次学习auth。但这个简单的问题是我仍然无法找到答案的。
答案 0 :(得分：1)
实际上，在建立新连接时，只有客户知道。 这就是发明 Diffie–Hellman key exchange 和类似方法的原因。
他们通过在服务器和客户端之间发送问题和答案来工作。 使用（实际上）不那么复杂的数学方法多次执行此操作，客户端和服务器可以共享只有他们知道的密钥，即使第三方拦截了流量。
我无法完全解释这个概念，但我可以推荐this StackExchange问题，它将提供对该主题的一个很好的概述。
编辑：我刚刚听说过JWT，所以这个答案可能完全脱离了背景。
答案 1 :(得分：1)
查找Diffie-Hellman和SSL / TLS加密。这是让你入门的东西。 https://blog.hartleybrody.com/https-certificates/
简短回答是当客户端启动与服务器的连接时，他们共享未公开公开的密钥。问题是，客户端需要与它认为想要连接的服务器建立初始连接。
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
答案 2 :(得分：1)
服务器如何知道请求来自客户端，而不是来自客户端 窃听黑客？
它没有。
由客户端验证服务器是否是预期与之通信的服务器。它被称为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是否具有由受信任的证书颁发机构签名的证书，其主题设置为＆＃34; example.com＆＃34;。这样可以防止发生以下情况：
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