diff options
| -rw-r--r-- | doc/design/assistant/xmpp.mdwn | 37 |
1 files changed, 31 insertions, 6 deletions
diff --git a/doc/design/assistant/xmpp.mdwn b/doc/design/assistant/xmpp.mdwn index 8dadfaf97..627a2229a 100644 --- a/doc/design/assistant/xmpp.mdwn +++ b/doc/design/assistant/xmpp.mdwn @@ -9,6 +9,28 @@ who share a repository, that is stored in the [[cloud]]. See <http://git-annex.branchable.com/design/assistant/blog/day_114__xmpp/#comment-aaba579f92cb452caf26ac53071a6788> * Support registering with XMPP provider from within the webapp, as clients like pidgin are able to do. +* Add an encryption layer that does not rely on trusting the XMPP server's + security (currently it's encrypted only to the server, not end-to-end). + There are a few options for how to generate the key for eg, + AES encryption: + * Do a simple Diffie-Hellman shared key generation when starting each XMPP + push session. Would not protect the users from active MITM by the + XMPP server, but would prevent passive data gathering attacks from + getting useful data. Since the key is ephemeral, would provide + Forward Security. + * Do D-H key generation, but at pairing, not push time. Allows for an + optional confirmation step, using eg, BubbleBabble to compare the + keys out of band. ("I see xebeb-dibyb-gycub-kacyb-modib-pudub-sefab-vifuc-bygoc-daguc-gohec-kuxax .. do you too?") + * Prompt both users for a passphrase when XMPP pairing, and + use SPEKE (or similar methods like J-PAKE) to generate a shared key. + Avoids active MITM attacks. Makes pairing harder, especially pairing + between one's own devices, since the passphrase has to be entered on + all devices. Also problimatic when pairing more than 2 devices, + especially when adding a device to the set later, since there + would then be multiple different keys in use. + * Rely on the user's gpg key, and do gpg key verification during XMPP + pairing. Problimatic because who wants to put their gpg key on their + phone? Also, require the users be in the WOT and be gpg literate. ## design goals @@ -109,9 +131,10 @@ status with a chat message, directed at the sender: ### security -Data git-annex sends over XMPP will be visible to the XMPP -account's buddies, to the XMPP server, and quite likely to other interested -parties. So it's important to consider the security exposure of using it. +Data git-annex sends over XMPP will be visible to the XMPP account's +buddies, and to the XMPP server (and any attacker who has access to the +XMPP server). So it's important to consider the security exposure of using +it. Even if git-annex sends only a single bit notification, this lets attackers know when the user is active and changing files. Although the assistant's other @@ -121,9 +144,11 @@ As soon as git-annex does anything unlike any other client, an attacker can see how many clients are connected for a user, and fingerprint the ones running git-annex, and determine how many clients are running git-annex. -If git-annex sent the UUID of the remote it pushed to, this would let -attackers determine how many different remotes are being used, -and map some of the connections between clients and remotes. +An attacker can observe the UUIDs used for pushes and pairing, and determine +how many different remotes are being used. An attacker could replay push notification messages, reusing UUIDs it's observed. This would make clients pull repeatedly, perhaps as a DOS. + +The XMPP server, or an attacker with access to it can reconstruct the git +repository from data sent in pushes, in part or in whole. |