I am auditing a webapplication that gives access to a financial backend. The web application provides the frontend in a HTTPS session properly encrypted, and after the client authenticating inside the system, it sends the symmetric key that will be used for further communication (between the client and the server) as a GET request back to the server, and it puts the key information as a value inside the HTTP header. The symmetric key is used to handle another portion of traffic exchange outside the web frontend.

I know that HTTPS encrypts everything, including the HTTP header, but is relying only on HTTPS to share the symmetric key for the post-encryption process safe? Is it a good practice? Encrypting the key value, before sending it as a value inside the HTTP header is still needed even if you have an already secure line established (HTTPS)?

  • 2
    Why is it using a separate symmetric key? I would be vary of the homebrew protocol, not TLS.
    – vidarlo
    Jan 11 at 0:30
  • Yes. That is the point. I understand that this could be better, but I am trying to address the risks related when using this approach
    – Mr. Lee
    Jan 11 at 0:41
  • 1
    "relying only on HTTPS" is acceptable. HTTPS is used to protect financial transactions by every bank. There could be a problem if the application used this symmetric key outside of HTTPS later on. If all traffic is kept inside an HTTPS connection, that's not the problem.
    – ThoriumBR
    Jan 11 at 1:51
  • 2
    Use TLS, don't use homebrew?
    – vidarlo
    Jan 11 at 8:17

2 Answers 2


Exchanging secrets -- including keys -- over TLS is valid and secure (as long as the TLS connection is secure, of course). However, the key exchange scheme you describe is not just relying on TLS. For mutual authentication over TLS, both the server and the client need to have X.509 certificates. But you wrote that the client is authenticated “inside the system”, e.g., with a password. This makes the scheme much weaker than TLS, because it actually relies on the security of multiple components:

  • The user-chosen password, if password-based authentication is used
  • The authentication system of the web application (e.g., all passwords must be securely hashed)
  • Whether or not the web application is protected against common attacks like cross-site scripting
  • The session management system, if users can also obtain the exchanged key during a session, not just directly by providing their password
  • The TLS connection
  • ... and possibly more

Any vulnerability in any of these components may compromise the key exchange. For example, if the web application is vulnerable to XSS attacks, an attacker may be able to render a fake log-in form, obtain the password from the user and then get the key by providing the password to the application. More sophisticated attacks which allow the attacker to read the key header with JavaScript (e.g., through Service Workers) might also be possible.

So there are many more risks besides TLS-related vulnerabilities. Whether those risks are acceptable depends on the specific security, usability and technical requirements.

  • Thanks. That makes sense. Regarding the TLS usage and key sharing in this scenario: Is it demanded to encrypt the key's string before sharing it inside the HTTPS session? I am just wondering what could happen in a SSL strip scenario, the key could be extracted and stolen and used for to decrypt data in the further encryption process.
    – Mr. Lee
    Jan 11 at 14:42
  • The server can and should reject all non-TLS traffic connections when exchanging sensitive data. If it doesn't, then this needs to be fixed in the server configuration, not by introducing double encryption. Also, encrypting data within TLS is not as simple as you make it sound, because this either requires client and server to already have a shared symmetric key (which would make the whole key exchange scheme useless), or it requires public-key cryptography with authentication (which is exactly what TLS is for).
    – Ja1024
    Jan 11 at 16:32

HTTPS/TLS encrypts the traffic only to the TLS termination point on the server side. Here are 2 cases possible.

  1. The termination point is the application itself. This happens now days very rare. In this case exchange of additional symmetric key itself is safe, but additional encryption with this key does not provide any additional cryptographic strengths, assuming the server decrypts the traffic before processing it.

  2. The termination point is not the application itself, but some reverse proxy, which forwards the traffic to the application. In such case the data will be decrypted at the TLS termination point, then (probably encrypted with another TLS connection) sent to the application. Thus, at least the TLS termination point sees the plain data. And if no TLS is used between the TLS termination point and the application, also other parties within the netwrok can read the decrypted traffic. Even if the application server uses an additional key, the termination point sees that key and still can decrypt the traffic and get the plain data.

In both cases adding one more level of symmetric encryption does not make encryption stronger.

In case the TLS termination point is not the application itself, and if the TLS termination point is not trusted, another approach can be used. The application provides its public key via some public channel. For symmetric encryption, the client uses it to initiate key exchange for the end-to-end encryption.

You must log in to answer this question.

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