2

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.

  • How does the client and server get a shared symmetric key in the first place so that the client is able to enter the key the server already has? I doubt that you understand what TLS is actually doing: providing a safe way to exchange a symmetric key and using this key to encrypt the traffic. You are trying to do the same symmetric encryption again on top of TLS, only that you are don't have a secure way to exchange the key you use. It does not get more secure this way. – Steffen Ullrich May 2 '17 at 16:31
  • 4
    The biggest flaw is that you are attempting to create a new security protocol. Just stop. Search for two-way authentication in TLS (using client-side certs is a widely known and used practice). – oleksii May 2 '17 at 16:45
  • @SteffenUllrich suppose the clients and the owner of the server establish the symmetric key face to face. The owner of the server then stores it on the server, and the clients learn the 16 characters (128 bit key) by head. When the clients enter the symmetric key in the html input box, it is not sent to the server, but stored as a variable in the client's browser. Do you think my two examples are correct, i.e. that this protocol provides extra security in a situation where an attacker is able to act as a client or as the server? – peter May 3 '17 at 7:33
  • @oleksii I am already using two-way authentication. But if an attacker somehow manages to get hold of one of the certificates, does my protocol ensure me that the attacker is still unable to read / send any valid message? – peter May 3 '17 at 7:48
  • @peter: if they already have a symmetric key shared in a secure way then they don't need to use TLS. The whole point of the TLS handshake is to get a shared symmetric key in a secure way in order to encrypt the traffic. But however the parties got the shared key: it should be kept secret and not entered it into some form they've got over a potentially insecure connection as you propose. Because this allows the attacker to grab this shared secret. In other words: no, your idea does not add security. – Steffen Ullrich May 3 '17 at 7:57
2

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.

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.

  • Suppose the clients and the owner of the server establish the symmetric key face to face. The owner of the server then stores it on the server, and the clients learn the 16 characters (128 bit key) by head. When the clients enter the symmetric key in the html input box, it is not sent to the server, but stored as a variable in the client's browser. Do you think my two examples are correct, i.e. that this protocol provides extra security in a situation where an attacker is able to act as a client or as the server? – peter May 3 '17 at 7:35
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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