4 ms·

Is Signal allowing arbitrary apps to connect to its network? How do I know that my correspondent is using TM Sgnl or another unofficial app? Doesn't that break

by mmooss 2y ago

Is Signal allowing arbitrary apps to connect to its network? How do I know that my correspondent is using TM Sgnl or another unofficial app? Doesn't that break Signal's security guarantees? For example, what if I set my message to delete in 1 hour but TM Sgnl archives it, or some other app simply ignores the retention setting? If Signal allows it, it seems like a major vulnerability? I suppose I must trust other users - they could always screenshot a conversation. But while I trust them not to intentionally cheat me, I shouldn't have to trust them to accurately evaluate the security implementation of a software application - something most people can't do, Mike Waltz being the most famous example. Maybe Signal should identify users unofficial clients. A downside is that it would provide significant identifying information - few people use unofficial apps.

Sniffnoy 2y ago
> Doesn't that break Signal's security guarantees? For example, what if I set my message to delete in 1 hour but TM Sgnl archives it, or some other app simply ignores the retention setting? Disappearing messages has never been a security guarantee of Signal. People can always archive things their own way (screenshots in the worst case). It's just a convenience feature, not a security thing.
- sudahtigabulan 2y ago
  I see responses like yours quite often. They are correct, of course, but if users keep getting confused about it, may be the UX is bad. People have been requesting various changes to this feature for years, but hear crickets from Signal.
- mmooss 2y ago
  > Disappearing messages has never been a security guarantee of Signal. What makes you say that? Has Signal posted something about it? Retention settings are widely used for messaging security. Also, I just used retention as an example. There could be many other holes in the unofficial client, including how it communicates with the Signal network. Maybe my messages aren't E2EE when communicating with that client. Maybe the mess up the encrytion implementation.
  - Sniffnoy 2y ago
    > What makes you say that? Has Signal posted something about it? I mean, if you want Signal's blog post where they introduced it, it's here: https://signal.org/blog/disappearing-messages/ https://signal.org/blog/disappearing-messages/ But also, of course Signal hasn't promised that if they're remotely competent, because that's impossible. You can't stop people from retaining messages if they want to. Now perhaps they're not remotely competent, but in reality they do know better. > Retention settings are widely used for messaging security. I mean, maybe people think they're using it for that, but regardless of the context, it will not provide any actual security, because that's impossible! Your recipient could get out a camera and take a photograph if that's what it comes to.
    - mmooss 2y ago
      > Your recipient could get out a camera and take a photograph if that's what it comes to. You are making the perfect the enemy of the good. As I said, two comments up: "I suppose I must trust other users - they could always screenshot a conversation. But while I trust them not to intentionally cheat me, I shouldn't have to trust them to accurately evaluate the security implementation of a software application - something most people can't do, Mike Waltz being the most famous example." IT security professionals do use retention settings for security; it's not perfect, as you say, but it's very helpful. For example, many businesses auto-delete messages after a certain period except messages that the user intentionally preserves. And as I said, there are other security functions in Signal that users must trust their apps to handle correctly.
      - palata 2y ago
        > You are making the perfect the enemy of the good. They merely said: "Disappearing messages has never been a security guarantee of Signal". Signal guarantees end-to-end encryption in transit. They don't guarantee anything that happens on the phones, because they can't. They try to help where they can, e.g. with disappearing messages. But that is a convenience tool, not a security guarantee by Signal.
Weetile 2y ago
The question is - how do you intend to verify whether an application is official or unofficial? What's stopping the official application to be 'patched' with a fake signature feigning validity?
- mmooss 2y ago
  Asymmetric cryptography?
  - Philip-J-Fry 2y ago
    How? If you're validating a server, sure. But a server validating a client? Anything you ship with the app can be extracted.
dboreham 2y ago
There's no way for Signal to prevent any piece of code that can make a TCP connection and speak its protocol from using the service.
- coppsilgold 2y ago
  While that's true even in the general case (through reverse engineering), it's especially true in the case of Signal because it's open source. There are libraries for interacting with Signal services (one from Signal themselves), here is a CLI tool that uses a patched official library: <https://github.com/AsamK/signal-cli https://github.com/AsamK/signal-cli>
- mmooss 2y ago
  Why not require keys signed with Signal's private key?
  - goupillon 2y ago
    If the keys are generated on the device, they can't be trusted by Signal since any clone could generate them too. If the keys are generated by Signal and sent to the device, they can be intercepted and used in any clone
    - mmooss 2y ago
      Thanks. Signal could use unique public keys for each valid client. It could be intercepted and used for DoS against the valid client's Signal service, but that's not a confidentiality risk. It could serve as a UID, but maybe there are workarounds to that.
- bubblethink 2y ago
  You'd need hardware attestation, but you can essentially implement DRM like schemes that prevent any unofficial client from working.
jaza 2y ago
If it quacks like the official Signal client, there's no way for the Signal network to know that it's otherwise.
- mmooss 2y ago
  There are many solutions to this problem, such as cryptographic signatures.
  - immibis 2y ago
    The only solution to this problem is for your device to be tightly sealed so you can't modify the operating system nor access the CPU's private key.

by mmooss 2y ago

Sniffnoy 2y ago

> Doesn't that break Signal's security guarantees? For example, what if I set my message to delete in 1 hour but TM Sgnl archives it, or some other app simply ignores the retention setting? Disappearing messages has never been a security guarantee of Signal. People can always archive things their own way (screenshots in the worst case). It's just a convenience feature, not a security thing.

sudahtigabulan 2y ago
I see responses like yours quite often. They are correct, of course, but if users keep getting confused about it, may be the UX is bad. People have been requesting various changes to this feature for years, but hear crickets from Signal.
mmooss 2y ago
> Disappearing messages has never been a security guarantee of Signal. What makes you say that? Has Signal posted something about it? Retention settings are widely used for messaging security. Also, I just used retention as an example. There could be many other holes in the unofficial client, including how it communicates with the Signal network. Maybe my messages aren't E2EE when communicating with that client. Maybe the mess up the encrytion implementation.
- Sniffnoy 2y ago
  > What makes you say that? Has Signal posted something about it? I mean, if you want Signal's blog post where they introduced it, it's here: https://signal.org/blog/disappearing-messages/ https://signal.org/blog/disappearing-messages/ But also, of course Signal hasn't promised that if they're remotely competent, because that's impossible. You can't stop people from retaining messages if they want to. Now perhaps they're not remotely competent, but in reality they do know better. > Retention settings are widely used for messaging security. I mean, maybe people think they're using it for that, but regardless of the context, it will not provide any actual security, because that's impossible! Your recipient could get out a camera and take a photograph if that's what it comes to.
  - mmooss 2y ago
    > Your recipient could get out a camera and take a photograph if that's what it comes to. You are making the perfect the enemy of the good. As I said, two comments up: "I suppose I must trust other users - they could always screenshot a conversation. But while I trust them not to intentionally cheat me, I shouldn't have to trust them to accurately evaluate the security implementation of a software application - something most people can't do, Mike Waltz being the most famous example." IT security professionals do use retention settings for security; it's not perfect, as you say, but it's very helpful. For example, many businesses auto-delete messages after a certain period except messages that the user intentionally preserves. And as I said, there are other security functions in Signal that users must trust their apps to handle correctly.
    - palata 2y ago
      > You are making the perfect the enemy of the good. They merely said: "Disappearing messages has never been a security guarantee of Signal". Signal guarantees end-to-end encryption in transit. They don't guarantee anything that happens on the phones, because they can't. They try to help where they can, e.g. with disappearing messages. But that is a convenience tool, not a security guarantee by Signal.

Weetile 2y ago

The question is - how do you intend to verify whether an application is official or unofficial? What's stopping the official application to be 'patched' with a fake signature feigning validity?

mmooss 2y ago
Asymmetric cryptography?
- Philip-J-Fry 2y ago
  How? If you're validating a server, sure. But a server validating a client? Anything you ship with the app can be extracted.

dboreham 2y ago

There's no way for Signal to prevent any piece of code that can make a TCP connection and speak its protocol from using the service.

coppsilgold 2y ago
While that's true even in the general case (through reverse engineering), it's especially true in the case of Signal because it's open source. There are libraries for interacting with Signal services (one from Signal themselves), here is a CLI tool that uses a patched official library: <https://github.com/AsamK/signal-cli https://github.com/AsamK/signal-cli>
mmooss 2y ago
Why not require keys signed with Signal's private key?
- goupillon 2y ago
  If the keys are generated on the device, they can't be trusted by Signal since any clone could generate them too. If the keys are generated by Signal and sent to the device, they can be intercepted and used in any clone
  - mmooss 2y ago
    Thanks. Signal could use unique public keys for each valid client. It could be intercepted and used for DoS against the valid client's Signal service, but that's not a confidentiality risk. It could serve as a UID, but maybe there are workarounds to that.
bubblethink 2y ago
You'd need hardware attestation, but you can essentially implement DRM like schemes that prevent any unofficial client from working.

jaza 2y ago

If it quacks like the official Signal client, there's no way for the Signal network to know that it's otherwise.

mmooss 2y ago
There are many solutions to this problem, such as cryptographic signatures.
- immibis 2y ago
  The only solution to this problem is for your device to be tightly sealed so you can't modify the operating system nor access the CPU's private key.