0
$\begingroup$

Nowadays I work maintaining an web application written in Node.js and we use HTTPS with TLS 1.2. We have to implement a new feature related to security on this application, all HTTP messages must be encrypted, and we will have all messages encrypted two times ultimately, one time using TLS and another through the new feature. We are studing the Noise Protocol to know if makes sense use it on this new feature, but from what I understand so far, the Noise Protocol would be an alternative to TLS. I'd like to know if makes sense use both protocols together, or if they are mutually exclusive.

We don't know how to utilize the Noise Protocol yet, if we simply pick up an implementation and include on the project or if the Node.js should offer an implementation like TLS. I found this implementation on GitHub: Noise-c.

Any clarification or help is welcome, thanks.

$\endgroup$
0

1 Answer 1

1
$\begingroup$

Using two transport protocols is not a good idea. You would double-encrypt your data. However, the symmetric ciphers are generally rather secure if applied correctly.

Besides double encrypting your data you would also get: double the security warnings to react to, double key management, double the initial handshake processing, double the latency.

If you want to encrypt twice it is probably better to perform additional end-to-end encryption / decryption on top of the point-to-point encryption that the TLS security offers. That way you can keep your messages secure over multiple point-to-point connections and after receiving them at the end points. For this you could device your own protocol or you could use web-security.

Generally it is better to perform encryption well once, instead of performing it badly twice. Bullet-proofing your TLS connection makes the most sense if you just require transport protocol security. Encrypting things twice should not be your goal. The goal is simply to secure your messages to the best of your ability.


The noise protocol seems to be in draft stage. Besides that, it seems a rather generic sum of possible algorithms more than an actual protocol. It seems that it mainly has been setup to explain the security behind WhatsApp rather than to be a protocol that you should consider. Just the formatting of the messages is already ill-defined, and it is unclear which kind of authentication method you should be using.

$\endgroup$
3
  • $\begingroup$ The idea is to perform application-level end-to-end encryption. The main motivation comes this link that says: "While HTTPS is far more secure than HTTP, it is still susceptible to certain forms of attacks. For example, if a Certificate Authority is compromised, an attacker may mount man-in-the-middle attacks against any on-path traffic between the victim and the intended website. A class of these attacks may be mitigated by digitally signing the contents of the request or further encrypting the contents of the HTTP message." $\endgroup$ Dec 7, 2018 at 11:56
  • $\begingroup$ Our customer needs a high level of security on his transactions and if the HTTPS is corrupted, we'd have a additional layer of encryption. We found this RFC that explains how encrypt an HTTP message, besides that, we are thinking to use ECDH to establish a symmetric key to be used with AES cipher. That would be our protocol, the doubt was if the Noise Protocol could replace our protocol. $\endgroup$ Dec 7, 2018 at 12:02
  • $\begingroup$ You can always restrict the certificates that can be used or even pin a specific certificate down. That other RFC seems rather sparse and it seems to depend on pre-existing, shared secret key. Personally I'm not even sure why it was written. You can encrypt HTTP content with GCM. And that's it. $\endgroup$
    – Maarten Bodewes
    Dec 8, 2018 at 1:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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