Page MenuHome GnuPG
Create Task
Maniphest T7972

RFC: web client to native client mapping
Open, Needs TriagePublic
Actions

Description

The current codebase matches web clients to native clients by email-address. web clients additionally keep track of which native clients they "trust", but connecting web client to native client and vice versa is based on email-address, alone.

The web client's email-address is taken from the outlook account. The native client's email-address(es) are taken from its list of available private keys.

This approach comes with some limitations:

  1. Several users might have access to (some) of the same e-mail-addresses and private keys.
  2. A user may want to use the plugin without having access to a relevant private key. E.g. for checking signatures. Or the UID(s) of their private key(s) may simply not match the UID of the outlook account, but messages are (also) encrypted to those keys.

The current code base makes an effort to enable the second case, at least for single machine installations: In case only a single native client is registered, the proxy server tries to fall back to that for establishing a mapping. (Although so far this has been very buggy). However, this does not address the first use case, above, and comes with its own set of complications. E.g. suppose (in a shared proxy setup), user A has left their browser tab opened over night. Next morning, user B starts their native client, and the two connect, despite mismatching email-addresses. (Related issue: https://dev.gnupg.org/T7726). Also it makes it difficult to correctly detect and display error conditions such as: "Connection is established, but you lack the private key for this account."

Suggested action plan:

  • The native client already sets up a unique id. Let's just use that as the primary key for establishing the connection between web client and native client.
  • On first start/configuration, the web client does not yet know what id to connect to. The proxy server will then provide it with a list of non-connected native client ids to select from. These will be simultaneously shown in the native client, and offered for selection in the UI, similar to bluetooth pairing.
  • The native client id is stored in the browser's localStorage. On next startup, web client and native client will both register at the proxy server with that id. The proxy then uses that, instead of email in order to route messages back and forth.

Related side-issues:

  • Only a single web-client (aka browser tab) can currently connect to a native client. That's also a limitation of the mapping implementation, but is not logically dependent on the nature of the mapping key.

Related Objects

Event Timeline

tfry created this task.Thu, Dec 11, 4:39 PM
tfry added a comment.Thu, Dec 11, 4:46 PM
  • The proxy server may also limit the list of ids to offer to an unconnected web client to ids of native clients running on the same ip as the web client.
m.eik added a comment.Fri, Dec 12, 9:13 AM

i'd suggest to not send an actual shared ID for verification to protect against spoofing attacks. instead, the native client (NC) should generate a six digit number (or something similar) to verify in the web client (WC). if successfully verified, NC and WC should generate a shared secret via diffie-hellman key exchange. this can then be used for challenge-response verification during re-connecting the two.

this would also allow use cases where different IP addresses are used. e.g., either native or web client running in a virtual machine on the same host as the other client to further seperate the two. it could also be the basis to allow a single NC to connect to multiple WCs simultanously.