Application integrity insurance

[IpsmLorem]

Application Code integrity is fundamental when talking about security oriented application.
For now, Wire desktop download the application code like a browser would do.
Since Wire desktop is powered by Electron, there is a way to ensure application integrity by embeding all the code into the local application and rely on Internet network only for message transmission.

PS: Somehow related to wireapp/wire-ios#197

Correct me if I'm wrong ! :p

[ghost]

Just started using Wire couple days ago and I started light audit of Wire architecture/communications. And I was thinking about the same. Virtually it possible to change code on server side without user notification to... let's say, insecure version and intercept traffic.

I'm not really familiar with Electron architecture, if it is possible to use local version instead of web-based. But I don't like to rely on web-version.

[ghost]

We need to get our hands on mobile version 🙂, I want to understand its' architecture.

[ghost]

Dear IpsmLoremm, can you please double check this bug report? It is a bit related to this one.

[IpsmLorem]

The same could be asked for the iOS version. Is there some code out of the Downloaded app ?

[ghost]

IMO opinion this Electron-based thing (same goes to browser client) cannot guarantee full privacy/security in case of server-side vulnerabilities.

[tokariu]

I don't understand this issue.
There is Wire-Desktop (downloadable/installable program) and there is WireApp (app.wire.com). The first being the one that holds a localized electron based version of wire on your hd (%localappdata%/wire on windows after install). Thats practically the same thing as app.wire.com just as a localized program.

so if you don't like app.wire.com / the browser version, just use the desktop version.

Or did I miss the point anyhwere?

About server side vulnerabilities: everything depends on working https. if any server-side private keys are getting compromised, wire as a whole would be insecure. (maybe not the axolotl protected e2ee messages, but integrity of other up/downloads)

[ghost]

HTTPS can only protect against MITM attack. Think of it like GPG-encrypted emails - I take care not about Google's/Yahoo's/etc. server side (and their private keys) if my GPG private key and my GPG binary are secure. With web-based technology I receive this "GPG binary" along with its' logic (in form of JS) every time I start/open client. If server side is compromised (which has to be kept in mind in case if we want real security) this "GPG binary" can be easily compromised too.

[tokariu]

@timur-davletshin wire is using the signal protocol (a customized version of the axolotl protocol), so the encrpytion shouldn't be the problem here, the e2ee wouldn't be compromised if server side private keys are stolen.
However if that's the case, somebody can MITM electron client updates and compromise everything that comes after that.
So the biggest flaw, as i see it, is that https/private keys get hacked someday in someway (or some corrupt CA interfers with wire certificates)

[ghost]

E2E is when my client encrypts something on my computer with some sort of binary or in our case with JS function and delivers to addressee for decryption (on the other end). Transport security is of little importance.

[tokariu]

thats all clear. but transport security is important for client updates and it's integrity. I'm not talking about communication and message encryption in this case.

[ghost]

In case of real desktop clients secure updated are provided via some sort of signed package/binary, in case of web-based — with HTTPS. But the point in having not web-based application is that breaking-in to my computer and to server are two different events. In case of web-based - it is one event since everything is on one physical server.

[tokariu]

so you draw a case like: some blackhat hacked the wire server which serves everything from communications to wire client updates. he would be able to change the files getting deployed to all other clients around the globe. the clients trust the server, the server-certificate (tls) and thinks everything is fine, while getting modified client updates.
Thats one of the worst scenarios available together with compromised SSL and if that happens it's already too late.

but I got your point. you want a signed wire installation package with all logic implement on your local device, so nothing has to be loaded via (possibly compromised) https - and therefor still working secure.
But isn't this exactly what you get with the wire-desktop-app? (verify integrity with SHA Fingerprints) A local electron based version of Wire with all program logic?

so if missed that the desktop-version is still loading all logic from web via https like the wire-webapp used to do, I'm sorry - didn't know - then I'd really support this request as written in the opening post.

[ghost]

In case of Electron-based app I'm not entirely sure that it works only with local files. As I said I'm not familiar with details of this technology that is why I'm asking for help/explanations.

[tokariu]

without digging in the desktop source code now to find answers to local-or-remote-logic problem:
the desktop client by default starts with update.exe, it phones home to see if there is an update available and if, it will update the desktop client. that's the default behaviour.
In case of the above scenario with compromised TLS or Wire-Server, the integrity of your local desktop client will get lost, because it gets overwritten by a possibly malware-modified version from the server.
You'd have to start Wire explicitly with wire.exe instead of the shortcut with Update.exe --processStart Wire.exe, so possibly malformed updates won't get automatically loaded.

Currently, I'm still assuming all client-logic is placed locally in wire desktop-version. if that's not the case, everything i wrote above makes no sense at all.

[3n-mb]

@IpsmLorem @timur-davletshin
Would you agree that is the core of issue #17 (Desktop app as insecure, as a web page. Serve code from local files, especially crypto.)

[3n-mb]

@tokariu besides main scenario, quoting you: "some blackhat hacked the wire server", there is another one, when hacker is not someone paid salary in a non-Switzerland country, but is a Switzerland's IC itself approaches Wire to do certain code corrections, to serve only specific users, definitely foreigners to Switzerland. Fear mongering of populace works as a social engineering method even in a Sweet-zer-land.

@timur-davletshin Electron-based app doesn't have to do anything with network to function. It is this particular app, wire, that takes all of its code on demand from a server.

If you can get over node_integration = false flag in Electron, then, by breaching legally-or-not wire's servers, you can own users' desktops completely.
US folks are talking about allowing mass hacking. Loading all of code from a web can be a good vector for such activity.

[IpsmLorem]

Youre right @3n-mb, this is duplicate of #17. Discussion may then go on your issue.

[3n-mb]

Unfortunately, #17 was closed by Wire's employees. And, because it was closed, you haven't seen it. I suggest you reopen this issue.

[3n-mb]

I think, github should have two categories: closed issues, and satisfied issues. Cause, as this issue shows, closed doesn't mean satisfied/fixed.