New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application integrity insurance #115

Closed
IpsmLorem opened this Issue Oct 25, 2016 · 19 comments

Comments

Projects
None yet
4 participants
@IpsmLorem

IpsmLorem commented Oct 25, 2016

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

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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.

timur-davletshin commented Oct 25, 2016

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.

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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

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

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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

timur-davletshin commented Oct 25, 2016

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

@IpsmLorem

This comment has been minimized.

Show comment
Hide comment
@IpsmLorem

IpsmLorem Oct 25, 2016

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

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

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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

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

@tokariu

This comment has been minimized.

Show comment
Hide comment
@tokariu

tokariu Oct 25, 2016

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)

tokariu commented Oct 25, 2016

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)

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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.

timur-davletshin commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tokariu

tokariu Oct 25, 2016

@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)

tokariu commented Oct 25, 2016

@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)

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@tokariu

tokariu Oct 25, 2016

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.

tokariu commented Oct 25, 2016

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.

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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.

timur-davletshin commented Oct 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tokariu

tokariu Oct 25, 2016

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?

desktop

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.

tokariu commented Oct 25, 2016

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?

desktop

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.

@timur-davletshin

This comment has been minimized.

Show comment
Hide comment
@timur-davletshin

timur-davletshin Oct 25, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@tokariu

tokariu Oct 26, 2016

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.

tokariu commented Oct 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@3n-mb

3n-mb Oct 28, 2016

@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 commented Oct 28, 2016

@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.)

@IpsmLorem IpsmLorem changed the title from Application integrity assurance to Application integrity insurance Oct 28, 2016

@3n-mb

This comment has been minimized.

Show comment
Hide comment
@3n-mb

3n-mb Oct 28, 2016

@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.

3n-mb commented Oct 28, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@IpsmLorem

IpsmLorem Oct 28, 2016

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

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

@IpsmLorem IpsmLorem closed this Oct 28, 2016

@3n-mb

This comment has been minimized.

Show comment
Hide comment
@3n-mb

3n-mb Oct 28, 2016

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 commented Oct 28, 2016

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

This comment has been minimized.

Show comment
Hide comment
@3n-mb

3n-mb Oct 28, 2016

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

3n-mb commented Oct 28, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment