From MozillaWiki
Jump to: navigation, search

Crypto Proxy

Firefox Home Roadmap: http://bit.ly/homeroadmap


This is a proposal for the 'Crypto Proxy'. It is a server-side component in the Sync Services infrastructure that makes it possible for Firefox Home 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.

Fair Point - But understand that this will be completely opt-in. We will not default this and we will of course explain very well to the user what it means to flip that 'Enable Web Access' checkbox.

<clyon> To be clear, Infrasec has not signed off on the design / implementation for Crypto Proxy

Problems the Sync Proxy tries to solve

Transparent decryption of sync data

The Crypto Proxy will expose the same API as the Sync Service. The differences are:

  • The Crypto Proxy will not work with Basic Auth but instead with Username/Access Token pairs
  • The Crypto Proxy will not return encrypted data but instead returns plain text data

The Crypto Proxy is able to decrypt the data because it has a table that contains usernames and decryption keys for a subset of the sync data.

Sharing of Credentials

Sync clients need to use Basic Auth to connect to the Sync Service. This means that Firefo Home 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 Firefox Home can use to access sync data.

These tokens are maintained by the Sync Proxy, which means that the Sync Proxy can also easily deny Firefox Home or a specific 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 Firefox Home 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 Firefox Home.

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 Firefox Home 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 since it sits between apps and sync.)

Permissions Management

Because the Sync Proxy is the only way to access sync data for a third party application like Firefox Home, 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'


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

See also File:CryptoProxyFlow.pdf

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 its own Sync Client. Instead of talking directly to the Sync Service, authenticated with Basic Auth, it will now talk to the Crypto Proxy with the Username and Access Token.

The crypto proxy will have to talk to the regular sync infrastructure. It will either skip basic auth or it will have to authenticate by some other means. (Basic Auth is not possible because the proxy does not know the users password)

The Sync Protocol is pretty much the same except that known collections to which Firefox Home has access 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.