Hacker News Reader

Comment by bigbones | Hacker News Reader

It gets more interesting when you think about the impact on groups. Sending an image to a group is enough for all devices associated with that group to be identifiable from CloudFlare's side, who additionally see a giant chunk of unencrypted traffic from the same client addresses going to other web sites. Given Cloudflare's less-than-straight approach to sales, it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

CloudFlare get to see a fuckton of metadata from private and group chats, enough to trace who originally sends a piece of media (identifiable from its file size), who reads it, when it is is read, who forwards it and to whom. It really doesn't matter that they can't see an image or video, knowing its size upfront or later (for example in response to a law enforcement request) is enough

View on HN

> Given Cloudflare's less-than-straight approach to sales, it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

This is an overly binary take. Security is all about threat models, and for most of us the threat model that Signal is solving is "mainstream for-profit apps snoop on the contents of my messages and use them to build an advertising profile". Most of us using it are not using Signal to skirt law enforcement, so our threat model does not include court orders and warrants.

Signal can and should append some noise to the images when encrypted (or better yet, pad them to a set file size as suggested by paulryanrogers in a sibling comment) to mitigate the risks of this attack for those who do have threat models that require it, but for the vast majority of us Signal is just as fit for purpose as we thought it was.

Hello, I'm an organizer for a system to coordinate multiple mutual aid networks, many of which are only organizing by Signal & Protonmail exclusively because they think they're secure and private.

People who are doing work to help people in ways the state tries to prevent (like giving people food) rely on this tech. These are the same groups who were able to mobilize so quickly to respond to the LA fires, but the Red Cross & police worked to shut down.

This impacts the people who are there for you when the state refuses to show up. This impacts the future version of you who needs it.

Most people aren't disabled, yet. Doesn't mean they don't need us building infrastructure for if/when they become disabled.

What groups did the police and Red Cross shut down? Any links?

In any geopolitical crisis, you tend to have victims on both sides be prevented from getting relief, except when the one side is imperial.

The powerful entities tend to prohibit relief to the oppressed side, even making it illegal.

I’m thinking as well more “mundane” things as well, like red states with “charitable feeding” laws that in effect make it illegal to feed the homeless without large amounts of red tape.

But, truly, I think you’re right to highlight wars.

https://www.salon.com/2023/08/07/criminalizing-the-samaritan...

This is why I say that it's overly binary, not incorrect. Some people do have such needs, and Signal can and should fix this for those people.

Someone should tell anyone who seeks confidentiality that no email is secure. Use Signal and enable the data retention (i.e., automatic message deletion) feature. By itself that is not perfectly secure, but it's a start.

The people involved are likely all using Protonmail. So that would mean TLS for the connection to Protonmail with E2EE for messages passing through Protonmail.

Not sure that encrypted email in general would be less secure than, say, Signal. Since Signal is an instant messenger on a phone it might actually be less secure[1].

[1] https://articles.59.ca/doku.php?id=em:emailvsim

people who think protonmail is secure it's to the same level as mail.yahoo.com :)

Maybe not individual warrants (at least not warrants to do non-scalable collections like hardware bugs in one's phone - I.e. warrants that, most users, with high probability, are not subject to). But mass surveillance, e.g. NSA, even with 'mass warrants' (e.g. Verizon-FISA warrant), that everyone is subject to, is probably in most people's attacker model. I don't have a study handy, but it seems reasonable that most users use signal to protect against mass surveillance and signal advertises itself as being good for this.

Also Marlinspike and Whittaker are quite outspoken about mass surveillance.

If cloudflare can compile a big part of the "who chats with whom" graph, that is a system design defect.

I highly doubt that signal does anything to help with mass surveillance. Signal started keeping people's name, photo, phone number, and contacts in the cloud protected by a "secure" enclave the NSA almost certainly has access to and hackers already got into (https://community.signalusers.org/t/sgx-cacheout-sgaxe-attac...) and even leaving all that aside, all anyone needs is a PIN that can be trivially brute forced. (https://www.vice.com/en/article/signal-new-pin-feature-worri...)

I thought it was digits only but see there's always been the option to use an alphanumeric passphrase as the "PIN". That prevents brute-forcing for anyone that bothered to use one, right?

It was only digits initially (https://old.reddit.com/r/signal/comments/oc6ow4/so_a_four_di...), with nothing preventing very easy ones like "1234", but even after they fixed it they continued to call it a PIN and many people would just assume is a number ("number" is right in the acronym), and often a very short one. Most people didn't want to set a PIN at all, they'd been being nagged about setting one and then got nagged again and again to reenter it.

It was not clear to most people that their highly sensitive info was being uploaded to the cloud at all let alone that it was only protected by the PIN. I wouldn't be surprised if a lot of people picked something as simple as possible.

https://old.reddit.com/r/signal/comments/gqc2hu/the_new_pin_...

Their announcement post says "at least 4 digits, but they can also be longer or alphanumeric", though maybe the feature had launched before that was written? https://signal.org/blog/signal-pins/

Far from ideal I agree.

> Signal can and should append some noise to the images when encrypted (or better yet, pad them to a set file size as suggested by paulryanrogers in a sibling comment) to mitigate the risks of this attack for those who do have threat models that require it

Adding padding to the image wouldn't do anything to stop this "attack". This is just watching which CF datacenters cache the attachment after it gets sent.

Right, my bad on the ambiguity—I was replying to the OP's concern about image sizes, not the attack in TFA:

> It really doesn't matter that they can't see an image or video, knowing its size upfront or later (for example in response to a law enforcement request) is enough

That makes sense. Thanks for the clarification, my bad!

I think the threat model of enough signal users to matter is nation-state actors, and signal should be secure against those actors by default so that they may hide among the entire signal user population

>It gets more interesting when you think about the impact on groups. Sending an image to a group is enough for all devices associated with that group to be identifiable from CloudFlare's side,

Doesn't this open up the possibility to identify groups that have been infiltrated by spies or similar posers? If you use this method to kinda-sorta locate or identify all the users in your group and one or more of those users ends up being located in a region where you should have no active group members then you may have identified a mole in your network.

Just thinking out loud here since there's no one else home.

>If you use this method to kinda-sorta locate or identify all the users in your group and one or more of those users ends up being located in a region where you should have no active group members then you may have identified a mole in your network.

...unless they happen to be using a VPN for geo-unblocking reasons or whatever.

If you're in a group like this where people are seriously concerned about their location being discovered by governments or by their own contacts, anyone in that group who is not already on a VPN all the time is either ignorant or nuts.

Communication of any sort over any channel risks sharing location information. Silence is secrecy.

I wonder if we'll see assets being padded to some common byte sizes to combat this.

Nothing stops Cloudflare from inspecting the file contents, or using a hash to distinguish between identically-sized files.

The only reason we assume they don't do this is because it's a waste of resources for no good reason. But what if somebody gave them a good reason?

Aren’t the files end-to-end encrypted? How would they inspect the files?

Last time I used Cloudflare I think their settings default to only "Origin SSL/TLS" (or whatever they call it), which wouldn't encrypt anything between Cloudflare and the origin, it would only encrypt data between Cloudflare and the end-user/browser.

But the Signal client encrypts images before sending them to the Signal server. If it padded out the images at that point, the images would all be indistinguishable from each other unless Cloudflare were actually able to break the encryption (which would completely undermine the entire security model).

Ah yes, I'm sorry, I mistook the context. If Signal encrypts the images E2E, you're right that it wouldn't matter what Cloudflare does, especially if padded.

So the image is uploaded for each recipient with an individual key?

TLS doesn’t matter for End-to-end encrypted stuff though, you could exchange the data over Telnet and it would still be secure. The content itself is already encrypted before being transmitted and can only be decrypted by the receiver.

AFAIK the attack described by OP only works if the attacker knows the (randomly generated) URL of the image, which probably means they have a Signal client that can decrypt the image already. So the secrecy of the content is not at issue. The question is whether some specific person has received the same image, and from where.

Part of his attack requires disabling the cache on his (sender) side so that he doesn’t pollute the cache. That implies that both sides of the conversation share the same URL, which means Cloudflare could assume two IP addresses requesting the same URL on the Signal attachment domain are participating in a shared conversation.

Yeah, that's a problem. It is leaking metadata, not content.

Ideally, the image should be padded, encrypted with a different key, and given a different URL for each user who is authorized to view it. But this would increase the client's burden significantly, especially in conversations that include more than two people.

yeah, the person you're referring to is confused because the Cloudflare HTTP service terminates TLS and presents a Cloudflare certificate, but that doesn't have anything to do at all with Signal's E2EE which is not based on HTTPS PKI

Hi there, Signal dev here. We do, in fact, pad attachments to a limited set of bucket sizes.

> , it is astonishing the words "secure" and "Signal" ever appear in the same sentence.

You misspelled "I do not understand what end to end encryption means"

Reply on news.ycombinator.com