In a synchronous environment, does Signal offer any security benefits that can’t be achieved with a modern version of TLS?

Question

The Signal protocol utilizes the double ratchet algorithm to achieve end-to-end encryption with forward secrecy and future secrecy (aka break-in recovery).

• Forward secrecy ensures that if any of the user’s keys are compromised (including long-term identity keys and ephemeral keys), these keys cannot be used to go back and decrypt past messages.

• Future secrecy ensures that if any of the user’s ephemeral chain keys are compromised, these keys cannot be used to decrypt future messages.

  *Note: Future secrecy does not apply to the user’s long term identity keys. From Advanced Cryptographic Ratcheting: If, for whatever reason, any individual ephemeral key is compromised or otherwise found to be weak at any time, the ratchet will heal itself. We call this “future secrecy.” (emphasis mine)

In addition to the above, Signal protocol can be used in an asynchronous environment, meaning that the protocol maintains state even if one or both parties are offline, or one party sends a message to the other party while the other party is offline.

However, if the two parties are communicating in a synchronous environment, then does Signal offer any security benefits that can’t be achieved with a modern implementation of TLS?

Consider a scenario where Bob and Alice wish to communicate in a synchronous environment with end-to-end encryption, with forward secrecy and future secrecy. Both Alice and Bob are running TLS servers, with modern versions of TLS that offer forward secrecy. When Alice wishes to send a message to Bob, Alice connects using her client certificate to Bob’s TLS server, the TLS session commences, Alice authenticates Bob’s TLS server certificate, Bob authenticates Alice’s TLS client certificate, then Alice sends the message to Bob’s server through the TLS tunnel. Bob uses the inverse process to send a message to Alice. After each message is transmitted, the TLS session is torn-down, and all ephemeral keys are discarded. Brand new TLS sessions are created for each message transmitted, without using any session material from previous sessions.

It is well established that modern versions of TLS provide forward secrecy. It would seem that the above system would offer future secrecy as well - being that ephemeral session keys are never re-used, so earlier session keys, if compromised, cannot be used to decrypt future messages.

In light of all of the above: In a synchronous environment (and putting aside the practicalities of Alice and Bob each having to run a TLS server), does Signal offer any security benefits that can’t be achieved with a modern version of TLS?

Answer 1

No, except to the extent that you think Signal provides better key authentication mechanisms than TLS (or vice versa). The main weak point in TLS key authentication is probably the Public Key Infrastructure (PKI), which allows any trusted CA - whether directly trusted or cross-signed by a directly trusted one - to issue a trusted cert for any entity in the world.

There exist mechanisms against the abuse of this (revocation, certificate transparency, explicitly untrusted CA lists, etc.), but the only really foolproof one is certificate (or public key) pinning. Pinning requires knowing the certificate (or at least the public key) of your peer in an unspoofable way before exchanging any sensitive data, which is the standard chicken-and-egg problem that the PKI is supposed to solve. (You can also pin a CA, which prevents a cert issued by a different CA from being trusted, but this is only a partial mitigation since you're still trusting somebody.)

Signal fares no better here. Instead of PKI in the usual sense it uses a single trusted server from which you can request anybody's public key, but if that server is not actually so trustworthy after all - akin to a trusted CA being untrustworthy - then you might not get the right one. You can attempt to verify the public key (using the "security number"), but again that requires an unspoofable knowledge of your peer's public key, before you exchange any sensitive data. Quite the conundrum.

By default (that is, with no special effort spent on verification), I'd say TLS is actually more secure than Signal (though harder to set up), because Signal will report whatever public key was sent by the last client to enter an OTP sent via SMS, and SMS-based authentication is usually easier to spoof than getting a fraudulent but trusted certificate. On the other hand, Signal is easier to make secure; you can potentially verify the "security number" once through something like an in-person meeting and then never again be uncertain about it, and you can set up the optional password in Signal that prevents somebody from taking over your account without it, and when it comes to security of the server, well, you're probably better off than with the full breadth of CAs out there (there are so many! Lots are controlled by a wide spread of governments that deliberately use them to MitM traffic!). On the third hand (foot?), you can pretty easily establish full security in TLS without relying on PKI if you want to; either just only trust the peer's certificate (pinning, but you don't necessarily need to do anything code-wise in the app for it; just remove all the CAs from the trust list and add your peer instead) or use a form of TLS that doesn't rely on public keys at all such as TLS-SRP (which provides mutual authentication using future-secret ephemeral keys and forward secrecy if the password is later lost).

Answer 2

The main difference is that signal is an end to end protocol: client1 <-> server <-> client2, while TLS is intended to be a point to point protocol client <-> server.

So if you only need to send messages over a connected session (meaning that one of the end points can behave as a server) TLS will securely protect the data. The hard part is just to be able to behave as a server, because it de-facto excludes smartphones and home computers except over a local network because those devices generally do not keep a fix IP address. Well it is of course possible to build a protocol able to establish a direct connection between 2 clients but it will require more work that just relying on a well-known and well tested protocol like Signal.