undefined | Better HN

0 pointsdanShumway7y ago0 comments

Signing infrastructure does seem like a significant improvement over Javascript delivery, but does that also carry over to platforms like Windows?

Again, please correct me if I'm wrong, but Windows doesn't do anything with signing app updates, does it? Come to think of it, I'm not 100% sure my Linux version has this either, since Signal isn't being distributed as part of the official repos.

If Signal is being updated on Windows without validating any kind of signature, could a compromised server even pull off the "send a malicious payload to only one IP address" attack that people talk about with the web?

0 comments

d_k_f7y ago

While Windows does allow for code signing of executable files in general, I doubt Signal is using their system. The official windows store would probably work similarly to how Apple and Google handle updates, but Signal doesn't use it either.

You can always implement signing yourself, though, without relying on somebody else's infrastructure. Just include the public key in the app itself and use it to verify your updates are properly signed by your private key before accepting them. I haven't checked but assume/hope Signal is doing this with their updated JS packages.

If none of this were to happen, however, then the answer to your last question is "yes", though with a caveat: If Signal's servers are compromised and push out a malicious update, then all bets are off, as the app running on your system has access to all your unencrypted messages. If the compromised server is only one of the messaging/relay servers, however, things are not as bad, as they don't have access to your keys and thus can't decrypt your messages. They can still forward them somewhere else for later decryption, but thanks to perfect forward secrecy this is currently rather unrewarding.

danShumwayOP7y ago

So the takeaway I'm getting from this and a few other comments is that, in general, running automatic updates for most software is still more secure than not, since a 0-day is more likely than a compromised server.

E2E encryption is still valuable, because assuming that the codebase is delivered/signed separately from its app servers, it decreases the number of available attack points. It's usually easier to secure code delivery than it is to secure your entire backend/database. It's even easier than that to secure a private key that you never put on your delivery servers in the first place.

JS has some additional concerns regarding stuff like Spectre and random number generation, but ignoring those for a sec, E2E encryption is in theory viable and valuable on the web, assuming you've split your backend from your code delivery endpoint and are taking extra steps to secure those specific code delivery servers.

But E2E encryption on the web could be improved a lot if we expanded code-signing for browsers. We download code over SSL, but that's just to make sure no one MITMs the server itself. We could, in theory, have some kind of signing system for raw assets that was completely unrelated to the connection to the server -- a "only allow Javascript to download/eval on this domain if it's signed with a key that's not even stored on the delivery server at all" policy. But we don't have anything like that yet.

Is that a reasonable interpretation?

j / k navigate · click thread line to collapse

0 comments

d_k_f7y ago

danShumwayOP7y ago

Is that a reasonable interpretation?

j / k navigate · click thread line to collapse