Just read the OMEMO audit which, by necessity, re-audited the Signal /protocol/:
https://conversations.im/omemo/audit.pdf
Tells you everything you want to know about Signal. Or read the secushare comparison page:
http://secushare.org/comparison
Here, some choice quotes from the OMEMO audit that pertain to the Signal protocol:
"Metadata
The protocol leaks metadata about who is communicating with whom and how much they are communicating. Alice’s request for the server cache leaks to the server that she wants to start a conversation with Bob, as does the PreKeySignalMessage. The plaintext message counters that are included in each SignalMessage make it possible to track the rest of the conversation. Unlike the ratchet used in the Signal Protocol, the regular variant of the Double Ratchet [24] also encrypts the message headers, which would make it possible to avoid tracking of the conversation. It would only make sense to implement this if this information is not leaked already in the transport layer."
"Message authentication
Messages are authenticated by the randomized key, which protects the message integrity from outsiders. However, anyone with access to the key can alter the message, which includes a malicious device. There are a few possible mitigations, each with their advantages and disadvantages. A possible solution would be to authenticate inside the Signal session. By authenticating the payload with the tag of the SignalMessage, the full message is authenticated in such a way that no other device can compromise the integrity. The ciphertext (and not the plaintext) of the payload message should be authenticated, so that the MAC-then-encrypt pattern is applied.8 This solution increases the computational load on the sender side, because the payload needs to be authenticated more than once. When the ciphertext is added as authenticated additional data (AAD) of the Signal message, it would reduce the message size slightly, because no authentication tag is required on the payload. The payload encryption method should then be simplified to a non-authenticated block cipher mode. It will also require some alterations on the Signal library, as the current implementation does not allow the library user to add their own AAD. The payload can also be authenticated by including a hash of the payload ciphertext in the SignalMessage plaintext (and therefore the corresponding encrypted hash in the SignalMessage ciphertext). This would not require changes to the Signal library, but it would increase the size of each element. This solution is less elegant than the previous, as the hash of the payload ciphertext is sent encrypted, even though the recipient can compute this value themselves. By authenticating a list of all recipient device ids in the tag of the SignalMessage, Bob has a guarantee about which devices Alice has sent the message to. Bob’s client might provide him with a warning if that list includes untrusted devices. This protects him against the specific attack described above, but the protocol remains vulnerable if one of the devices gets compromised by another attack. This solution can be combined with the above solution of authenticating the payload ciphertext with the SignalMessage ciphertext or tag."
"Device linkage
There is no cryptographic link between identities and device keys. In other words, Eve can attach her own device identity key as if it is a resource belonging to Bob and fool Alice into adding it. There is a solution: each device could sign a certificate on each device identity key of the same user. While Eve might fool Alice into thinking that Bob has another device, it is highly unlikely that Bob is tricked into accepting another device as his own. Device identity keys with a certificates that was signed by an already accepted device of the same user could be accepted automatically. In order to account for compromised devices, users must have the ability to revoke certificates and certificates should have a finite lifetime. This solution can be extended into a full-blown public key infrastructure (PKI) or web of trust, but I recommend to keep that out of the scope of the OMEMO specification (although compatibility with such systems could be taken into account when updating the OMEMO specification)."
Granted, most of these come down to issues solvable in UX - but Signal doesn't. And the deceptive UX like the disappearing messages (which, for obvious reasons, can't expire on the server and get synced [and subsequently deleted from the client] until the last device has it), because the Signal developers only consider it a "convenience feature" (a fact which they offhandedly communicated in their blog, but think about it, how many users actually read that?), the whole phone number binding, and... Ugh. Just ugh. I don't wanna continue because Signal nauseates me. It's not that it's bad, it's not, but that doesn't mean it doesn't suck.