A client is communicating with a server through https, which should provide them with the security they need. I would like to add an extra layer of security.

The protocol would look something like :

  1. The 128-bit symmetric key is stored in the backend file on the server.

  2. Client connects to the server's IP address using https:// and logs in using a password (or PKI authentication)

  3. client is shown HTML with one input box in which he has to type the symmetric key, which is then locally stored as a js variable in the browser.

  4. All data that is exchanged by the client and the server is being encrypted/decrypted using the symmetric key for AES-CBC.

Can you think of attacks that would enable an attacker to read a message that is sent between the client and the server?

One example of why this extra layer can provide extra security: Let's say the attacker gets a hold of a certificate that is trusted by the client, and acts as the server. He would still not be able to read the messages sent by the client.

P.S. To clarify: the same symmetric key would be used for every session, as it is the one that is fixed and stored on the server. A random IV is used for each AES-CBC encryption, and is sent along with the encrypted message.


closed as off-topic by tylo, e-sushi May 2 '17 at 17:46

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    $\begingroup$ You might want to specify assumptions about the attacker, because "the TLS connection is somehow commpromised" is quite unspecific and it is impossible to say if your proposed solution helps at all. Example: If the attacker has full control over the server (or at least the execution environment the program is running in), then it doesn't help at all. Additionally, using a static key is always vulnerable to replay attacks. And finally, this is almost an XY problem: You present a solution instead of the actual question. $\endgroup$ – tylo May 2 '17 at 9:45
  • $\begingroup$ Re 1st point: storing your symmetric key on the server might be an attack vector… depending on the scenario. Re your PS: do not use the same key for every session, as that might break your neck faster than the compromised SSL connection… again, depending on the exact scenario. And that's onlky takng a short look at your Q. Therefore, you should edit your question to clarify the exact scenario like @tylo already asked you to do. Currently, your question is a bit too broad due to the missing details, and answers will hardly be able to cover all problems that might or might not arise. $\endgroup$ – e-sushi May 2 '17 at 13:38
  • $\begingroup$ Thank you. Let's say that he was able to get the symmetric key that was agreed upon during the SSL handshake. Would this extra AES layer provide security in this case, or is the attacker not able to eavesdrop on an https connection? Also, there is always an IV used for the AES-CBC encryption, would this get rid of the replay attack vulnerability that tylo mentioned? $\endgroup$ – hans May 2 '17 at 13:47
  • 1
    $\begingroup$ @hans If you want to notify people of your answer, you can use the '@username' at the start of your message. However, i am slightly worried that: a) You want your protocol validated - and that's quite close to a off-topic close reason, b) you might have a wrong view of security by only considering an attacker successfull if the can achieve a full break (that was the general point of view until a few decades ago) and c) That you might actually use that in a practical application if you're only looking for validation - which is a terrible idea if not properly examined in detail by an expert. $\endgroup$ – tylo May 2 '17 at 14:21
  • 1
    $\begingroup$ No, because this isn't a discussion board. Having your own scheme analyzed is considered off-topic here (section about cryptanalysis). Removed my previous comment - this isn't a forum. But since you read it, I hope you realized what I meant. $\endgroup$ – tylo May 2 '17 at 14:36

You are not saying how exactly the TLS connection is compromised. But if the attacker can read and modify and data transferred he can also change the HTML page displayed by the server where the clients enters the AES key. This way the attacker can get access to this AES key and can decrypt any communications done with this key.


Not the answer you're looking for? Browse other questions tagged or ask your own question.