I'm building a Spring app and a React app which also contains Chat functionality. I use WebSocket with RabbitMQ as message broker.

I store the chat history as encrypted messages with AES, and before I send them to the client, I decrypt them. So I'm wondering if someone could "intercept" the GET request and actually see the messages? I use JWT as authorisation, so to get the messages, the user of course has to be logged in. Also is it better to decrypt the messages in the backend or send the key and encrypted messages to be decrypted in the frontend?

I know it's better to use a hybrid of AES and RSA, and to send the private key with SSL, however, this is just for a bachelor thesis so writing about it in the report is "good enough". I don't have enough time to implement the hybrid version. I do however want to keep the chat the most secure I can.

So really my questions are: Can GET requests be "captured" by attackers even when you have to be authenticated to call the requests, and since I have to use symmetric cryptography, is it better to decrypt the messages in the backend or sending key and encrypted messages to frontend?

  • TLS is a good 1st step if you're only worried about attackers on the wire or in the switches. If you're concerned about attackers with server/endpoint access be aware that GET requests are frequently visible in logs & process tables
    – tjd
    Commented Sep 9, 2022 at 16:26

2 Answers 2


As long as you use TLS in the websocket, the requests between the server and the clients are going to be encrypted, so you don't need to encrypt again the messages. Encrypting them with AES on server-side to provide encryption at rest should be more than enough.

If you don't use TLS, then yes, the attackers could sniff the traffic and extract the content, but sending the key along with the encrypted message is not solving anything, since you also provide the attacker the way to see the original message.

Also, another drawback to send the decryption key to the frontend, is that you are sending the key to a client that you do not control, which can cause more problems:

  • You send the decryption key to an endpoint that you do not control
  • If there is only one key in the server for all the conversations, you are giving the key of decryption to a possible attacker that could compromise the message database.

Can GET requests be "captured" by attackers even when you have to be authenticated to call the requests

Specifically answering this question, without TLS the request is easily susceptible to man-in-the-middle attacks. "Capturing" request/responses (a.k.a Sniffing) is one vector, but they could inject malicious javascript see this question for more info on MitM attacks.

Anything you do without that, regarding client side vs server side d/encryption is moot.

Here is a white paper from WhatsApp on how they implement end-to-end encryption. Hope that will help as a reference point for your thesis.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .