JWT token security - public key forgery prevention

Question

Question on securing JWT token integrity, given the following scenario:

1. Client sends a JWT to server signed with Client's private key
2. Server caches public key, but uses http (and not https) to retrieve the public key to validate that JWT is signed by the client.
3. Attacker intercepts the http connection, changes the public key to the attacker's public key, and sends a JWT to the server with the attacker's signature on it - misrepresenting the message as if it were sent from the Client.

Is there a way out of this? Thanks

• Vincent Savard: Ignoring the JWT aspect of your question, the security consensus is to never transfer sensible data over HTTP. Can you clarify why this obvious solution is not an option for you?
• Berin Loritsch: The attack you are referring to is known as a man-in-the-middle attack, and it is always a possibility if you have weak or no encryption.
• IMSoP: This is a bit like saying "if I don't lock my door, burglars can get in; is there a way out of this?" Without some reason you're not applying the obvious solution, the question answers itself.

Answer 1

Key management is a critical part of any security system. In the first arrangement. You must establish an appropriate trust model where you know who the authority is and how you trust them. There are multiple issues with the scenario you've presented:

• The client is signing the JWT--how do we trust the client?
• We are sending keys over a medium with no means of verifying certificates
• Trust can only occur if you know the client and the server--that can only happen over encrypted communications

GPG (and PGP) require secure communications when sharing public keys, but the identity of the public key is known. That's the only reason why the point to point communications can be trusted. That's not the way web sites are supposed to work. If you wanted the identity to come from the client, then implement a true PKI implementation. As long as the key is properly signed by one of your trust keys, it is good.

Instead, for web applications, you must implement the authority service that validates the user's credentials--usually requiring encrypted communications so passwords or other tokens cannot be sniffed.

• Once the user's identity is confirmed, the authority generates the JWT with a key your system manages.
• The public key is shared to all backend services as a matter of deployment and configuration--i.e. no need to send the key over any means

With this model, you know the public key and the authority of the private key.

There are more advanced approaches where you are sharing a group of public keys to handle rotating keys. This is more secure, but again, you cannot trust unencrypted communications due to the man-in-the-middle attack possibility.

Answer 2

Use of a message digest is one solution. In the request to the server, a cryptographic hash of the contents of the request can be included along with the headers. This way, if an attacker tries MITM, they won't be able to as they won't have the correct signature, even if they could trick into getting their public key instead of the real one.

• IMSoP: This just begs the question: how do the client and server agree a secret for the message digest, if they only have insecure channels to communicate over? If the answer is that it's pre-shared, then pre-sharing the public key for the JWTs is even simpler.