How can a server know the request is coming from c

问题:

I have a simple question which I can not find a simple answer to, probably I am missing something or I don t know about how some networking concept works. And I want to know what I don t know.

Simply, the question is while eavesdropping is possible, how can server know the request is coming from client, not the eavesdropping hacker.

Scenario :

Whatever the security policy I am having, I should send something to client. It might be a asymmetric encrypted token or sth. Client has no private key, so that whatever client is able to do, send etc, a hacker can do, send too.

What might be the logic behind securing a web application. There should be something secret which only client knows.

Btw I am learning about JWT and this is the first time I am learning about auth. But this simple question is something I am still unable to find an answer to.

回答1:

How can a server know the request is coming from client, not an eavesdropping hacker?

It doesn't.

It is up to the client to verify that the server is the one it expects to be talking to. It's called Public Key Infrastructure.

TLS/SSL can be used so the connection is over HTTPS - note it does not have to be Diffie Hellman, there are other key exchange mechanisms such as RSA.

Imagine the following scenario.

Client --> HTTPS --> example.com

The client will do a DNS lookup for example.com, and say 203.0.113.10 is returned. The client will connect to 203.0.113.10 over HTTPS, and the initial part of the connection is called the handshaking process. Here the client checks that the domain it is thinking of connecting to, example.com, has a certificate signed by a trusted Certificate Authority with the subject set to "example.com". This will prevent the following from happening:

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

For example, if the attacker had taken over a DNS server and changed example.com to point to him (198.51.100.200).

This attack is prevented because the attacker cannot prove ownership of example.com to a Certificate Authority and therefore won't be able to get their certificate signed in order to prove to clients that their server is trusted.

HTTPS also encrypts the connection, and exchanges keys in a secure manner. This ensures that an already established connection cannot be read.

So once a connection is established, and a user logs in, the server will send a session token to the client, which can be in the form of a JWT. If this is a cookie and the Secure Flag is set, this can only be transmitted over an HTTPS connection. This is how the server knows that it hasn't been intercepted because the client has verified the server and has encrypted the data in transit to it using unique keys agreed by both parties.

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

Is also not possible (active Man-In-The-Middle), which shows the situation in your original question where somebody intercepts communications and passes the JWT to the real server, observing the private data in transit. This, however is if plain HTTP is used (no SSL/TLS):

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

回答2:

Indeed, when establishing a new connection there is nothing only the client knows. That is why the Diffie–Hellman key exchange and similar methods were invented.

They work by sending questions and answers between server and client. Doing this many times with (actually) not so complex mathematical methods the client and server can share a key wich only they know, even if a third party intercepted the traffic.

I cannot fully explain the concept but I can recommend this StackExchange question wich will provide a good overview of the topic.

Edit: I only just now heard of JWT so this answer might be completely out of context.

回答3:

Look up Diffie-Hellman and SSL/TLS encryption. Here is something to get you started. https://blog.hartleybrody.com/https-certificates/

The short answer is when a client initiates a connection to a server they share a secret key that is not exposed publicly. The thing is, the client needs to be making that initial connection to the server it thinks it is wanting to connect to.

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange