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

Warn user if an unverified device turns up #2143

Closed
richvdh opened this Issue Sep 9, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@richvdh
Member

richvdh commented Sep 9, 2016

When a new unverified device turns up in a room, and the user sends a message, we should warn them and let them check the device list.

This is going to be tricky to get right, without races: it would be easy for a malicious homeserver to engineer a race so that a new device turns up milliseconds before you press enter, so we must make sure we deal with that race robustly.

@richvdh richvdh added the type:e2e label Sep 9, 2016

@ara4n ara4n added bug p2 feature and removed bug labels Sep 16, 2016

@richvdh

This comment has been minimized.

Show comment
Hide comment
@richvdh

richvdh Sep 22, 2016

Member

Related to #2313

Member

richvdh commented Sep 22, 2016

Related to #2313

@remram44

This comment has been minimized.

Show comment
Hide comment
@remram44

remram44 Nov 21, 2016

Contributor

Does everyone have to approve the new device? Only one? Only the owner (from other device)?

Contributor

remram44 commented Nov 21, 2016

Does everyone have to approve the new device? Only one? Only the owner (from other device)?

@maralorn

This comment has been minimized.

Show comment
Hide comment
@maralorn

maralorn Jan 11, 2017

I’d actually suggest making this an opt-in option, because this is protection against active attackers. The majority of the population will get drowned in false positives they don’t understand.

maralorn commented Jan 11, 2017

I’d actually suggest making this an opt-in option, because this is protection against active attackers. The majority of the population will get drowned in false positives they don’t understand.

@remram44

This comment has been minimized.

Show comment
Hide comment
@remram44

remram44 Jan 11, 2017

Contributor

This is the only way to protect against any homeserver of any participating user snooping in on the conversation. In my opinion it is not worth implementing end-to-end encryption at all without this, if you trust the homeservers just rely on TLS.

Contributor

remram44 commented Jan 11, 2017

This is the only way to protect against any homeserver of any participating user snooping in on the conversation. In my opinion it is not worth implementing end-to-end encryption at all without this, if you trust the homeservers just rely on TLS.

@maralorn

This comment has been minimized.

Show comment
Hide comment
@maralorn

maralorn Jan 11, 2017

I see the difference between a passive and an active attacker. If you don’t use E2E anyone who can one day get access to the homeserver logs (or break tls) can read the message. The active attacker scenario would actually require malicious code in the homeserver (today. without anyone noticing. which will be hard, if users who know, what they are doing, are actually verifying their keys). I totally understand that the security is lower, but E2E crypto is much more important than verified E2E crypto. Confusing users with misplaced warnings lowers security and does not raise it.

(I will not push this point any further, this has to be decided by the developers. We can discuss it on matrix, if you want.)

maralorn commented Jan 11, 2017

I see the difference between a passive and an active attacker. If you don’t use E2E anyone who can one day get access to the homeserver logs (or break tls) can read the message. The active attacker scenario would actually require malicious code in the homeserver (today. without anyone noticing. which will be hard, if users who know, what they are doing, are actually verifying their keys). I totally understand that the security is lower, but E2E crypto is much more important than verified E2E crypto. Confusing users with misplaced warnings lowers security and does not raise it.

(I will not push this point any further, this has to be decided by the developers. We can discuss it on matrix, if you want.)

@pierce403

This comment has been minimized.

Show comment
Hide comment
@pierce403

pierce403 Jan 16, 2017

I think these warnings should pop up per room. Something like:

<nick> (<id>) has added a new device "<device name>" [verify] [blacklist]

Presumably, whoever added the key would also message the room with an older verified key/device saying something to the effect of "Hey, just got a new phone" or something. This will also encourage users to have descriptive device names.

pierce403 commented Jan 16, 2017

I think these warnings should pop up per room. Something like:

<nick> (<id>) has added a new device "<device name>" [verify] [blacklist]

Presumably, whoever added the key would also message the room with an older verified key/device saying something to the effect of "Hey, just got a new phone" or something. This will also encourage users to have descriptive device names.

@ara4n

This comment has been minimized.

Show comment
Hide comment
@ara4n

ara4n Feb 2, 2017

Member

this has just merged to /develop. @pierce403 - the implementation is very similar to what you suggest (although the verify/blacklist buttons are going to land shortly in a later PR)

Member

ara4n commented Feb 2, 2017

this has just merged to /develop. @pierce403 - the implementation is very similar to what you suggest (although the verify/blacklist buttons are going to land shortly in a later PR)

@ara4n ara4n closed this Feb 2, 2017

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