|
|
| (9 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| | | Moved to [https://wiki.mozilla.org/Home/Features/crypto Crypto] |
| = Crypto Proxy =
| |
| | |
| == Introduction ==
| |
| | |
| This is a proposal for the 'Crypto Proxy'. It is a server-side component in the Sync Services infrastructure that makes it possible for third party applications to get access to unencrypted sync data.
| |
| | |
| == Key assumption ==
| |
| | |
| That the question "shall Mozilla ever store decrypted data, or unencrypted keys, from any Sync users on its servers?" has been answered in the affirmative, and the corresponding legal and infrasec aspects have been considered.
| |
| | |
| In short: there's no point building this if it's counter to Mozilla's core goals for Sync.
| |
| | |
| == Problems the Sync Proxy tries to solve ==
| |
| | |
| ==== Sharing of Credentials ====
| |
| | |
| Sync clients need to use Basic Auth to connect to the Sync Service. This means that a third party application needs to know the user's username and plain text password to be able to access sync data. This is obviously not the right way to do things.
| |
| | |
| The Crypto Proxy solves this problem by working with a username/access token pair instead of a username/password pair.
| |
| | |
| The access token is a randomly generated identifier that a third party application can use to access sync data.
| |
| | |
| These tokens are maintained by the Sync Proxy, which means that the Sync Proxy can also easily deny a specific application or user access through this method.
| |
| | |
| ==== Sync Key Management ====
| |
| | |
| To decrypt records, a Sync Client either needs the Sync Key or the Bulk Key for a specific collection.
| |
| | |
| Ideally these keys are not shared with third party applications at all because they give you a carte blanche to access sync.
| |
| | |
| Since the Crypto Proxy gives access to plain text sync data, there is no concern about handing over Sync Keys or Bulk Keys to third party applications.
| |
| | |
| There is of course still the issue of the Crypto Proxy having to maintain these keys in some plain text way.
| |
| | |
| Since the Crypto Proxy is in charge, the key management becomes an internal detail and can be implemented in any way and can also be changed later on without external applications depending on any specific details.
| |
| | |
| (We talked about giving some collections a different Bulk Key and sharing that key with Firefox Home. That would prevent us from compartmentalizing access or supporting multiple applications in the future. The Sync Proxy solves that problem)
| |
| | |
| ==== Permissions Management ====
| |
| | |
| Because the Sync Proxy is the only way to access sync data for a third party application, it can also implement restrictions like:
| |
| | |
| * Access from specific IP ranges - In case of Firefox Home, the app is hosted on our own infrastructure. Which means an extra security barrier: no outside app could access data, even if tokens are compromised.
| |
| * Enforce read-only data or give partial write access
| |
| * Enable/disable access based on a username or even a specific application
| |
| * Fine tune access to specific collections - Applications can get access to a specific list of collections. This can be a simple configuration file that says 'Firefox Home is allowed to read bookmarks/history/tabs and nothing else'
| |
| | |
| == Operation ==
| |
| | |
| === Obtaining an Access Token ===
| |
| | |
| Draft Draft Draft
| |
| | |
| Ideally we use OAuth for this and make this a transaction between Firefox Home and the Crypto Proxy.
| |
| | |
| Unfortunately that is not possible because we also need help from Firefox Sync, which needs to share a Bulk Key with the Crypto Proxy.
| |
| | |
| So I think this would work something like this:
| |
| | |
| * User checks the 'Enable Web Access' checkbox
| |
| * Firefox Sync changes the Bulk Key for some collections and re-uploads those collections.
| |
| * Firefox Sync calls the 'CreateAccount' method on the Crypto Proxy, giving it the Bulk Key. This is an authenticated call (Basic Auth over HTTPS).
| |
| * The Crypto Proxy checks the credentials, generates an access token and stores username/accesstoken/bulkkey in it's database
| |
| * The Crypto Proxy returns the access token to Firefox Sync
| |
| * Firefox Sync POSTs the Access Token to Firefox Home (using Basic Auth over HTTPS)
| |
| * Firefox Home validates the credentials and then stores the usernme/AccessToken
| |
| | |
| Firefox Home now has all info it needs to tlak to the Crypto Proxy and run it's internal Sync Client.
| |
| | |
| === Accessing Sync Data ===
| |
| | |
| Firefox Home has it's own Sync Client. Instead of talking directly to the Sync Service, auhenticated with Basic Auth, it will now talk to the Crypto Proxy with the Username and Access Token.
| |
| | |
| The Sync Protocol is pretty much the same except that known collections that Firefox Home has access to are automatically decrypted by the Crypto Proxy.
| |
| | |
| This means Firefox Home does not have to access crypto/keys but instead can go straight to the collections it wants to sync.
| |