security protocol against attacks on SSL/TLS

Question

A client is communicating with a server through https using two-way authentication. I would like to add an extra layer of security.

The protocol would look something like :

1. An 128-bit symmetric key is stored in a file on the server.

2. Client connects to the server's IP address using https:// and gets access through his client certificate that is trusted by the server.

3. Client is shown empty html page 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. A verification step is done by sending an AES-encrypted message to the server using the client's symmetric key, which the server then decrypts with his version of the symmetric key. If this is successful, the client is given access to the rest of the html.

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

Two examples of why this extra layer can provide extra security:

• If the attacker gets hold of a certificate that is trusted by the client, and acts as the server. He would not be able to read the messages sent by a client.
• If the attacker gets hold of a certificate that is trusted by the server, he/she would still need to type in the symmetric key.

Am I right about the two examples, and secondly, do you see any flaws / attacks that I am unaware of?

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.

Answer 1

1) if someone can steal the TLS private key, can't he steal the symmetric key?

2) if someone can MitM your TLS connection he may change the javascript that the server sends to client, so that the script will send the key entered by client to hacker.

3) If hacker can decrypt the TLS connection and bypass TLS client authentication, he will store the message sent by client on step 4, and then just reconnect to server and resend the same message. The server will successfully decrypt it and grant access. To prevent this the server may send some random string (challenge) and the client should send the challenge back encrypted and MACed (with HMAC). If the message is not MACed, then the hacker can modify first block of the message encrypted in CBC mode by changing IV and may be bypass authentication again.

It seems that your solution may make it somewhat harder to hacker to get your info, but it surely will make it harder to legitimate user to work with the server. IMHO it doesn't make things better.

In general, creating robust crypto protocol is a very hard task, and it's not recommended to create it until you really know what you are doing. Even protocols created by groups of professionals at first have bad vulnerabilities.

Answer 2

Where is the additional security in your scheme? The Client supplies the key to the server (or attacker) so it can just be retrieved by an attacker.

Take a step back and explain what attack you are trying to defend against. And can you explain how your current setup for TLS does not protect you already for this?

If (and I am guessing your purpose here) I am correct in assuming you want to add validation between client and server. This is achieved through something called Client-side certificates.

Answer 3

It sounds like the client doesn't trust encrypted communication. Given the body of knowledge around SSL/TLS is comprehensive perhaps the what the client is attempting might be better managed using FIDO U2F.

That said, one instance where additional crypto makes sense is for the content such as ProtonMail provide for mailboxes or Mega purport to offer on uploaded files.