Hacker News Reader

Comment by paulryanrogers | Hacker News Reader

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

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

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

Reply on news.ycombinator.com