Weaving secure synchronization into Mozilla Firefox - Mozillas Sync Extension (WS10/11)

Markus Rudel

Seminar Work

at

Chair for Network and Data Security Prof. Dr. Jörg Schwenk

advised through Dominik Birk

26.01.2011

Horst-Görtz Institute Ruhr-University of Bochum Contents

1 Introduction 1 1.1 Motivation ...... 1 1.2 Sync extension ...... 1

2 Implementation 3 2.1 Synchronized data ...... 3 2.2 Security measures ...... 3 2.2.1 Used encryption algorithms ...... 4 2.2.2 Username and password ...... 4 2.2.3 Key management and de/encryption ...... 4 2.3 Server component ...... 8 2.3.1 Server installation ...... 8 2.3.2 Server configuration ...... 9 2.3.3 Database structure ...... 9 2.3.4 Used URL scheme ...... 10 2.3.5 Mozillas implementation ...... 10

3 Security considerations 11 3.1 Man-in-the-middle related attacks ...... 11 3.1.1 Self-signed certificates ...... 11 3.1.2 Replaying already transferred data ...... 12 3.1.3 Validation on server side ...... 12 3.1.4 Manipulation of transferred data ...... 12 3.2 Extension manipulation on client side ...... 17 3.3 Security on server side ...... 18

4 Summary 19

i List of Figures

2.1 Allowed characters in usernames and passwords ...... 4 2.2 Necessary values for the first encryption ...... 5 2.3 Basic WBO encryption ...... 6 2.4 WBO decryption ...... 7 2.5 Basic database scheme ...... 9

3.1 Check for modifications 1 ...... 13 3.2 Check for modifications - continued, but no change detected ...... 14 3.3 Check for modifications - continued, but change detected ...... 15 3.4 Check for modifications 2 ...... 16 1 Introduction

In this paper, we will present the new Mozilla Firefox extension called Firefox Sync [Moz10b]. It allows an easy and secure way of synchronizing browser settings, bookmarks and especially login data. As this data contains sensitive and personal information, it is necessary to get an insight in the functionality of the extension and to focus especially on how data is stored and transported. Most users will use the public servers of the Mozilla Foundation and it is therefore crucial to understand what happens to their synchronized data. Due to the increased availability of mobile devices and computers, we need a secure and easy way to share data between the devices. A user might want to switch from his netbook to his home computer because of the bigger screen. However, retyping the addresses of the opened browser tabs is exhausting. By using a synchronization extension for Firefox, you can easily continue your work on another computer. Another important reason for the Sync extension is the backup aspect. The browser profile is saved with each of its saved bookmarks and settings, so that in case your computer crashes, you can access your data from another authorized computer. Last but not least you can securely use more complex passwords for your logins without the need to memorize them, as they can also be synchronized to other computers.

1.1 Motivation

Synchronization between different pools of data tends to be complicated and sometimes frustrat- ing. The possible loss of information during a synchronization is an important factor to distrust in such an infrastructure like Mozillas Sync service. Mozilla pledges an easy and especially secure way of realizing this claim. Today’s browsers contains confidential data like logins to online banking, e-commerce or social networks. By promising to exchange this kind of sen- sitive data between computers over potentially insecure networks, it is important to protect it from curious eyes. During my Bachelor thesis I already got experiences in analyzing secured data transfer with a focus on the Google Chrome web-browser. Now it is interesting to see how Mozilla solves this problem keeping in mind that Google announced a similar service for their browser. In respect of data security, it is also worthwhile to point out the possibility to install your own server in your trusted environment, which makes Sync interesting for commercial use.

1.2 Sync extension

The development of the Sync extension started in 2009 [Moz10c] and it was first called Weave. It should weave different browser installations on different PCs and their individual settings together in one common profile. The idea of synchronizing browser profiles is not new, as

1 several other services appeared earlier on the internet. But they were often centered around synchronizing the bookmarks1 instead of whole user profiles. With more and more browsers supporting synchronizing profiles (i.e. Google Chrome [Goo10] or Opera [Ope10]), the Mozilla Foundation needed to add this feature to their browser to keep up in order to be able to compete. There are also non-browser specific programs for this function. One example is the Xmarks service, which should be discontinued in January 2011 due to a insufficient business plan [Tod10]. Another possible solution could be the use of a portable drive with modified browser versions, which saves all the users data and program content. The installation of the Sync extension is quite simple and needs no complicated installation routines. The user visits the Sync homepage in the Firefox Extension Repository [Moz10a] and clicks on "Add to Firefox". After a browser restart the extension is available and active. The user is asked to create a new account or to login with an existent account. For further instructions on this matter, please refer to the Mozilla knowledge base entry [Moz10m]. At this time of installation, the user is also asked to use the Mozilla Sync server or his own server.

1Depending on the used browser bookmarks are also called favorites.

2 2 Implementation

This chapter gives a short insight into the different types of synchronized data, the used security measures like used encryption algorithms, the choice of username and password, the key man- agement and de/encryption as well as a closer look at the server component of the extension.

2.1 Synchronized data

The extension synchronizes different types of data [Moz10l], notably bookmarks, history, pass- words, tabs, user preferences as well as an API1 for other developers [Moz10h], so that they can synchronize their data as well. All items are stored inside so called Weave Basic Objects (WBOs) and are organized in collections. While the WBO contains the actual synchronized item (e.g. bookmark, tab), the collection combines several WBOs of a session to one set of data for a browsing session. There are three different synchronization modes to choose from, when the Sync extension registers with the synchronization servers: "two-way synchronization between each Firefox", "other Firefox browsers overwrites this Firefox" and "this Firefox overwrites other Firefox browsers". It is the users choice to determine the behavior of his Sync clients to the server.

2.2 Security measures

It is important to ensure privacy and confidentiality for the users profile data. The Sync exten- sion uses several security measures to achieve these aims, therefore we will present you in this chapter the used encryption algorithms, the choice of username and password as well as the used key management and de/encryption workflows. To analyze and understand the used encryption algorithms, an insight into the extensions source code is helpful. As Mozilla Sync is published open source2, we can easily examine the Mozilla Sync extension source code3 as well as the Mozilla Sync server source code consisting of a user registration server component4 and the actual Sync server component5.

1API stands for application programming interface. 2Open source means that the used source coded can be openly reviewed. 3This source code was accessed on 27th October 2010 (http://hg.mozilla.org/services/fx- sync/log?rev=c540c68ecda1). 4This source code was accessed on 14th November 2010 (http://hg.mozilla.org/services/reg-server/). 5This source code was accessed on 14th November 2010 (http://hg.mozilla.org/services/sync-server/).

3 2.2.1 Used encryption algorithms The Sync extension is written by the Mozilla foundation. The developers used for this extension already existing working and proven code from older projects. So they used Mozillas own crypto engine library called Network Security Services (NSS) [Moz09]. Another important reason for choosing this library lies in its platform independency. This allows the extension to work on almost all major operating systems, as the NSS is written in JavaScript. NSS supports SSL v2 and v3, TLS v1, PKCS 5, PKCS 7, PKCS 11, PKCS 12, SMIME, X.503 v3 certificates, and other security standards and algorithms [Moz10k]. But the Sync extension uses only a small set of this functionality: it only uses RSA with a 2048 bit private key, PBKDF2, AES 256-bit in CBC Mode for encryption and TLS v1 for secure data exchange with the Sync server. Mozilla states in their privacy policy [Moz10d] that their engine assures an SSL-secured con- nection to their servers and that there is no way that a server administrator is able to view unen- crypted data [Moz10g]. The following chapters will explain the necessary steps to achieve these aims.

2.2.2 Username and password When using the Sync service for the first time, the user has to create a new user account, con- sisting of e-mail address and password. The following characters are allowed to be used as a password:

Figure 2.1: Allowed characters in usernames and passwords The username will be randomly generated and will be saved together with the e-mail address. They will be used together with the password to authenticate against the Sync server. The pass- word can be changed via the extension settings. Username and password can be seen in the Firefox password manager, if no master password is set.

2.2.3 Key management and de/encryption After having successfully created a new account, the extension generates a passphrase for the user6, consisting of twenty random characters between a and z. This passphrase is used as a base for most of the cryptographic functions in Sync. It can also be replaced by a passphrase choosen by the user. The passphrase should not be lost because without it there is no way to repeat access to any of the encrypted data. The extension recommends to save this key to a file or to print it. It is possible to change this passphrase, but it will result in the erasure of all saved data on the Sync server. Without this passphrase it is not possible to Sync other computers to the same account. After creation, the extension setup offers to display and save the passphrase in a html doc- ument called "Firefox Sync Key.html". This file should be saved to a secure location, because otherwise it is possible to decrypt the profile data. The Sync key is separated by hyphens in four

6See "extension dir/modules/util.js"

4 groups of five. The hyphens are just used to be more legible. The passwords can be read by any user in the Firefox password manager using the current profile, except the user set a master password that restricts direct access to the password manager. The next steps are shown in figure 2.2. It starts with the creation of a random RSA key pair with a 2048 bit private key (pk and sk). This key is based on the passphrase, an one- time generated salt value (salt) and a random initialization vector (IV). Following, the extension derives a symmetric key from the users passphrase using PBKDF27 while using the salt created to generate the RSA key pair. Subsequently, the extension encrypts the generated private key with the newly generated symmetric key. As a starting point this encrypted part (c) is sent to the server together with the salt, IV and the public key.

Sync Client Sync Server

Step 1

Generation of pk, sk, salt, IV

Step 2 Users passphrase Derivation of a symmetric key k via PBKDF2

Step 3

AES Encryption of sk with k enc_k(sk) = c

Step 4

Send salt, c, pk, IV

Figure 2.2: Necessary values for the first encryption

7PBKDF2 stands for Password Key Derivation Function 2.

5 Each time a WBO needs to be synchronized, the extension generates a new random 256 bit symmetric key and an IV particularly for the encryption of the WBO content (see figure 2.3, Step 1). This session key is always generated anew for a sync and then encrypted with the public key (Step 2), while the WBO content is encrypted with AES 256-bit CBC8 (Step 3) and associated with the to be synchronized WBO (Step 4) and finally transferred to the server (Step 5).

Sync Client Sync Server

Step 1 Derivation of a symmetric key k and creation of IV k, IV

Step 2 Encryption of k with RSA public key pk enc_pk(k) = c

Step 3 Encryption of WBO content with k enc_k(content) = c2

Step 4

Association of c with WBO

Step 5 Send c, c2, IV

Figure 2.3: Basic WBO encryption All keys are Base64 encoded and stored in different formats: symmetric keys are just Base64

8Cipher Block Chaining - an encryption mode for block cipher

6 encoded while asymmetric keys are stored in an ASN.19 format. There are several necessary steps to decrypt a WBO content, as the information is stored on a server cluster at Mozilla. The figure 2.4 shows them with requests and server answers.

Sync Client Sync Server

Step 1 GET users cluster server user supplies his username and password return location

Step 2 GET users encrypted pk, sk return JSON objects with pk, sk

Step 3

salt from sk JSON object Generation of a 256-bit symm. users passphrase key k using PBKDF2 IV from sk JSON object

Step 4

Decryption of users sk with k

Step 5 obtain encrypted wbo return encrypted wbo

Step 6 fetch corresponding encrypted k return encrypted k

Step 7

Decryption of k with sk

IV from encrypted wbo Decryption of wbo with k and IV

Step 8

Start using wbo content

Figure 2.4: WBO decryption Step one makes an HTTP GET request to the server and requests the users cluster server, if a user is using the official Mozilla Sync servers. A single server could be overloaded by too many requests, so that it could result in denial of service. To avoid this situation, Mozilla distributes user data on different servers, that are combined in a cluster of servers. The location is then the

9ASN.1 stands for Abstract Syntax Notation One.

7 exact address of the responsible users cluster server. The second step is to ask the server for the encrypted users private and public key, that are stored encrypted on the server. For this two steps, it is necessary to authenticate towards the server with a valid username and password. The servers answer is stored inside an JSON formatted object. Following, the extension extracts IV and salt from the private key object and uses them together with the users passphrase for the generation of a 256-bit long symmetric key by using the PBKDF2 function in step three. This is the symmetric key that was used to initially encrypt the private and secret key. Together with the IV and the private key object, it is possible to decrypt the users private key in step four. The next step is to obtain an encrypted WBO from the server, followed by the corresponding encrypted symmetric key in step six. All necessary information are now available for decryption of the symmetric key with the users private key. The symmetric key is necessary for the encryption of its corresponding WBO (see step seven). Finally, the extension is able to use the unencrypted content of the WBO e.g. a bookmark (see step eight).

2.3 Server component

According to Toby Elliott [Ell09], who is one of most active developers of Mozilla Sync, the services provided by Mozilla are distributed on a server cluster, to achieve maximal availability. Nevertheless it is possible to deploy the server component on a single computer. We will present you in this chapter the different kinds of installation of the Sync server, the configuration, the underlaying database structure, a short introduction to the used URL scheme and the real world implementation of Mozilla.

2.3.1 Server installation There are two different approaches on the installation of the server. One includes the instal- lation of a Weave Minimal Server, the other one follows a manual installation in several steps [Moz10e]. The Sync server software is written in PHP, but also available in Python for ng- inx10. Data is stored encrypted in a MySQL database. There is also an user registration server [Moz10f], which is necessary for a normal installation of the server. The Weave Minimal Server lacks this component in favor of user configuration via a single configuration file. For the an- alyzation of the full server with user registration, a standard Apache2, MySQL5 and PHP5 in- stallation was used together with the server code accessed on the 14th of November 2010. The installation follows the already mentioned tutorial or orientates on the packaged README file. It is even possible to use the server without TLSv1 encryption, which simplifies the analysis and manipulation of the transferred data in further tests. This configuration should not be used in a real world implementation, as the authentication is made unencrypted. The actual number of installed scripts is manageable small: 19 php files for the Sync server resulting into 3791 lines of code11 and 15 php files for the registration server resulting into 2017 lines of code.

10nginx is a web server written in C. 11Lines of code represents the actual number of used source code lines in a software. The smaller the number, the more efficient can be the solution. The used software is called cloc http://cloc.sourceforge.net

8 2.3.2 Server configuration Configuration of the server is handled via two configuration files. One file for each component, so default_constants.php is used for the Sync server and weave_user_constants.php for the user registration service. These configuration files store the unencrypted password to the used MySQL database, so administrators should take precautions to secure these files properly. User registration is made possible through an own server component called registration server, or reg server for short [Moz10f]. It takes the request from the Sync extension and writes the user registration values into the database. To avoid too many automated user creations via bots, it is possible to use Googles recaptcha service12. For bulk user account creation, it is possible to enable an admin interface that skips the HTTP authentication and recaptcha codes. This interface requires an own admin secret for identification which needs to be passed on each admin request via X-Weave-Secret header.

2.3.3 Database structure The Sync server is capable of using different database forms. These include and favor MySQL but basically every database supported by the used PHP Data Objects Extension (PDO)13. To simplify installation, we will use MySQL. A view on the MySQL database shows that the entered e-mail address is saved in cleartext, while there is no saved password but only a saved password hash for comparison. They are stored inside the users table. As already mentioned in chapter 2.1, all synchronized objects are kept inside Weave Basic Objects (WBO) and are stored encrypted inside the MySQL database at the WBO table, while the corresponding collections are saved in their own collections table. The figure 2.5 shows the basic database scheme:

weave

collections users wbo PK userid PK id PK username PK collectionid PK collection username PK id name password_hash email parentid status predecessorid alert sortindex reset modified reset_expiration payload payload_size ttk

Figure 2.5: Basic database scheme

12Google recaptcha (http://recaptcha.net/) is a free anti-bot service that helps digitize books. 13PHP Data Objects Extension (PDO) http://php.net/manual/en/book.pdo.php

9 The three tables collections, users and wbo are parts of the database called weave. While the gray cells are the tables name, PK stands for primary key. These primary keys are used to identify the table entries.

2.3.4 Used URL scheme As the Sync protocol is web based, it relies on a specific URL-scheme for exchanging data be- tween clients and server. It is divided into a Sync and an User part [Moz10j]. Most of the exchanged messages are JSON14 formatted, which makes them more readable to humans and allows transformation of all values via the eval() JavaScript function to real JavaScript-Objects. This reduces unnecessary transformations, as the extension is also written in JavaScript. The extension itself needs to be configured too. It is necessary to supply the server address manually while creating a new account. The used address must start with HTTP or HTTPS, indicating either unsecured or secured connections to the server. The actual location for installation con- figured in the apache configuration should be entered as the corresponding Sync server address. After configuration of the extension, the extension will start to synchronize to the Sync server.

2.3.5 Mozillas implementation There are several IPs behind the real world Mozilla synchronization service. Each server is mapped to a different domain name, which all belong to the domain services.mozilla.com Since all of the traffic to this servers is TLS encrypted, Mozilla issued a wildcard certificate for *.services.mozilla.com. It’s primary server address resolves from https://auth. services.mozilla.com/ as a CNAME15 alias to phx-auth.services.mozilla.com to several IP addresses. The API is in a way designed to support multiple cluster servers, so the IP address depends on the location of the users profile on one of the Mozilla servers. Some of them could be identified to the IP addresses 80.156.86.78, 62.157.140.133, 63.245.217.102 and 63.245.217.207. These values can be retrieved by using the tool dig and Wireshark on https://services.mozilla.com, which is the main server for synchronization services by Mozilla.

14JSON stands for JavaScript Object Notation. 15CNAME stands for canonical name and describes an alias name for an IP address.

10 3 Security considerations

The data handled by the Sync extension is very sensitive user data. It is therefore required to analyze the used encryption and transportation techniques, so one can get a better understanding of the functionality. In this paper, faulty server configurations are not taken into account. We will only try to concentrate on a few basic security tests. These include the reaction on self- signed certificates from the Sync server, replaying already transferred data, validation of input values on server side and tempering with transferred data.

3.1 Man-in-the-middle related attacks

It is possible to attack the transferred profile data for manipulation purposes while it is on its way to the server. So the extension should use an encrypted transmission. With the help of the network sniffer Wireshark1 and the Java utility Burp Suite2, it will be tested for clear text transmission or other insecurities. Depending on the initial configuration of the extension, the extension contacts the server either via unencrypted HTTP or via TLSv1 encrypted HTTPS. In both ways it is possible to intercept communication using the Burp Suite as an intermediate proxy server. This kind of attack is also known as the man-in-the-middle attack3. After configuring Firefox to use Burp Suite, the extension waits each time for a confirmation of the Burp Suite to relay intercepted packets.

3.1.1 Self-signed certificates If the extension is configured to use HTTPS, it is required to visit the Sync server address for a first time to confirm possible self signed certificates. The Firefox standard behavior is to avoid self-signed certificates and to warn the user about them. Firefox stops all traffic to the server in question until the user decides to accept an exceptional rule for this certificate. Only after this step the extension starts to accept the Sync server. Otherwise the extension says that there is no connection to the server possible. This behavior was also mentioned in the Sync server documentation and acts as a security measure against attacks with self-signed certificates. If the Burp Suite is used to intercept packets via HTTPS, it creates for each server Firefox tries to contact an own self-signed certificate. According to the already explained exception rules for self-signed certificates, the user has first to agree to this connection attempt by visiting the server page first by accepting the certificate. After accepting this certificates, the browser trusts them and allows communication with them.

1See http://www.wireshark.org 2See http://portswigger.net/burp/ 3The man-in-the-middle attack is an attack, where an attacker is able to eavesdrop both communication partners without detection and to make them belief they are talking directly to each others.

11 3.1.2 Replaying already transferred data Burp Suite has also a function called repeater, which allows sending an older intercepted packet to another point in time. This kind of attack can be used to replay already transferred data. If a user tries to synchronize his bookmarks, the Burp Suite intercepts these change in bookmarks and stores them for later use. These valid intercepted old bookmarks can be replayed at any time. The reaction of the server is, that the server accepts them and adds them to his database as if they were new bookmark entries. But the server compares the message content to the stored data in the database and just changes the modified value of an already existing bookmark entry. The value that is changed is the unix timestamp4 of the last time this bookmark entry was modified. This way it is not possible to create a duplicate of an entry without using direct database access.

3.1.3 Validation on server side Sometimes transferred bookmarks or other synchronization items can get corrupted or manipu- lated during their way from client to the server. The integrity of the received items are crucial to a reliable synchronization and data backup on the server. Before an item is deleted or modified on the server, the Sync server checks the messages content for its integrity and validity. In case of manipulation, the server returns an error 400 Bad Request and denies entry. This can happen, if the payloads length of fields is changed or if invalid values are entered. It cannot confirm the message anymore as valid JSON formatted and discard it, regardless of the message length or invalid values. So the Sync extension displays an unknown error and tries to synchronize again later. The payload of this synchronization attempt is discarded and replaced by a new payload for another try.

3.1.4 Manipulation of transferred data In this chapter, we will test Syncs reaction to manipulation of transferred data. For simplifica- tion, we only test a change of bookmarks to keep the transmitted traffic to a reasonable minimum for the analysis. Depending on the synchronization configuration5, the extension reacts differ- ently. The following tests where made by using one Firefox profile to be configured as the one profile, that overwrites all other profiles. The second Firefox profile was then configured to be overwritten by the other Firefox profile. This procedure ensures a repeatable synchronization behavior. But regardless of the used synchronization mode, each Sync client checks the server for eventually made modifications. The necessary steps are split up into two different cases with a common start, which is explained in figure 3.1.

4The unix timestamp is easier to calculate and to process than the human readable representation of hours and minutes. 5As earlier mentioned in chapter 2.1.

12 Sync Client Sync Server

Step 1 GET collections & crypto values Return collections & crypto values

Step 2

Check for changes via modified values

Values modified!

Step 3 PUT changed bookmarks on server Return ID & modified=Unix time stamp

Step 4

Check for changes via modified values

Figure 3.1: Check for modifications 1 The first step is to get all collections of bookmarks on the servers and the corresponding crypto values. The second step is to check for changes in these downloaded collections via the modified values. If this value is modified, the client puts in step three the changed bookmarks back onto the sever, while the server returns an ID and a new modified timestamp value. The following step four is the basis for the following figures 3.2 and 3.3.

13 Sync Client

Step 4

Check for changes via modified values

Step 5

No change, nothing to upload

Repeated until change is detected, even after a browser restart!

Figure 3.2: Check for modifications - continued, but no change detected Figure 3.2 describes the check for modifications, assumed that there was no change detected. Step four is repeated until a change is detected. This constant recheck is repeated even if the browser is restarted.

14 Sync Client Sync Server

Step 4

Check for changes via modified values

Step 5

Newer bookmarks detected!

GET bookmarks newer than last modified value Return newer bookmarks

Step 6

Decrypt bookmarks & integrate into own data

Step 7

Encrypt new bookmarks for server

Step 8 PUT newer bookmarks on the server Return ID & modified=Unix time stamp

Figure 3.3: Check for modifications - continued, but change detected Figure 3.3 describes the check for modifications, assumed that there were changes. Step five differs this time, because newer bookmarks are detected, so the client gets the bookmarks that are newer than the last modified valued. The client decrypts and integrates the newer bookmarks into its own data (step six). Step seven is to encrypt the new bookmarks for the server, while step eight is the actual upload of the newer bookmarks to the server. If there is any manipulation on the server to the payload value of the bookmark WBO without using the server API, the modified value of this WBO does not change. The extension does not realize any change of data, because it only checks for the modified value. An attacker could even delete the payload from this WBO and the browser will not check for manipulation. This behavior is not unwanted, because an intact version of the bookmarks is saved in the browsers

15 local profile. Nevertheless, it would be critical for other browsers, that want to get the latest changes of the bookmarks for their own profile and to merge both bookmarks data.

Second Sync Client Sync Server

Step 1

Change or Deletion on Server without API usage

No change on modified value!

Step 2

GET collections & crypto values Return collections & crypto values

Step 3 GET all corresponding bookmark entries Return all corresponding bookmark entries

Step 4

Check for changes via modified values

Step 5

No change because modified value hasn’t changed

No error message concerning decryption

Bookmarks differ, user doesn’t get his bookmark changes synchronized!

Figure 3.4: Check for modifications 2

16 Figure 3.4 describes a change or deletion of WBO data without API usage directly on the server (step 1). This can happen if the server is compromised and an attacker gets full access to the underlying database. A second Firefox browser was used here, so that a browser with a different bookmark data can be guaranteed. This is because the first Firefox browser was the source of the bookmark data on the server and was also the last client that uploaded its data. The data on the server and the data of the first Firefox is the same. So the second browser gets its collections and cryptovalues from the server (step two), as well as all corresponding bookmark entries and sets a new local modified value for this client (step three). This local modified value is overwritten by the newer modified valued from the server. The client tries to detect any changes via the modified values (step four) but is not successful, because the modified value has not changed since its last check (step 5). This results in no error message on the second browser concerning the decryption and the user does not get his bookmark changes synchronized, although the bookmark entries differ. If there is a new bookmark added on the first browser and then synchronized to the server, it only adds a new WBO entry for this set of changes, as all WBO entries are chained together in a bookmark collection. The second browser now synchronizes and realizes that there is a newer WBO for the bookmarks for download. This newer WBO does not contain the recently added bookmark, so this entry is lost. The second browser gets a chance to restore the data and to display the missing entry only after another change on the first browsers bookmarks. So the conclusion is that the synchronization protocol is temper proof up to a certain amount of data corruption, as this could always happen on both sides during transmission. It would be helpful to have an additional snapshot feature, so that a user can revert to another point in time before the data corruption or when the deleted items where still there. This versioned approach would make life easier, in case the user accidentally changed something on his profile and synchronized it to the server.

3.2 Extension manipulation on client side

One of the greatest problems with Firefox extensions is the insufficient check for manipulated xpi6 installer packages. Mozilla is trying to avoid this with the development of their Jetpack technology. It enables unique IDs for extensions, so that no unofficial tempering with the exten- sion is possible. It would be an interesting way of adding security to the Firefox Sync extension, but according to the planned roadmap [Moz10i] there is no research in this area. The following Firefox version 4 will include the Sync extension, so an initial manipulation protection comes with the trust in secure and not manipulated Firefox installer setups. Further smaller updates for the Sync extension without concerning Firefox should rely on protection via the Jetpack technology.

6xpi is the file extension for Firefox extension installer packages.

17 3.3 Security on server side

Using an own server results in a lot of maintenance and configuration work, but it could prove very useful for a certain kind of user. Most important, it allows full control over the whereabouts of the profile data as they are stored on a user controlled system. It is also independent from infrastructure problems at Mozillas Sync service and allows the user to use the service, even if Mozilla decides to shut it down. The user also has the possibility to configure his access in a additionally secured way, e.g. via VPN7 to his Sync server. As the extension saves only encrypted data on the server, an administrator could only look into the several database entries. He gets no important new information. However, he could try to analyze how each WBO fits to their collections and sessions. For the question wether it is possible to force synching to an older version with old/com- promised passwords or not we can say this is not that easily possible. An attacker would need access to the servers database to rewrite the user entries and he would also need the passphrase for decryption. The users access to the server is managed via basic HTTP authentication and can be manipulated, but as there is no crypto on server side, an attacker could not get insights on the data stored there. This approach was intentionally chosen by Mozillas developers to ensure that no data could be accessed on the server. The only way to get access is via the passphrase on the client. All other encryptions and security measures depend on this key.

7VPN stands for Virtual Private Network.

18 4 Summary

Mozilla Sync is an amazing piece of technology that even copes with data corruption and poten- tial server breaks. Its cryptography was designed to support even more features like giving ac- cess to certain profile parts to other users without sacrificing the privacy of the complete profile. These goals were abandoned according to the Mozilla wiki page on simplified Sync cryptog- raphy, because it was very speculative, costs client computation, server storage and especially network bandwidth, which, by itself, according to the wiki page consists of around 16% API transactions for key retrieval. It is sad to see, that this nice-to-have feature was abandoned on the costs of decreased API transactions. But this step seams reasonable, if we think of mobile devices with limited UMTS data plans or computing power. The next major Firefox version 4 ships preinstalled with Sync and leaves the user the choice to synchronize its data to the cloud. Mozillas effort is very sophisticated and therefore safe to use. However, the users should watch their own computer security, since the safety of the synchronization passphrase is essential to the whole product.

19 Bibliography

[Ell09] Toby Elliott. Weave server official first cluster launch. http://tobyelliott.wordpress. com/2009/02/21/weave-server-official-first-cluster-launch/, 02 2009.

[Goo10] Google. Google chrome - der schnelle, sichere browser | kostenloser download. http://www.google.com/chrome/intl/de/landing_mac.html?hl=de&hl=de, 10 2010.

[Moz09] Mozilla. Network security services (nss). http://www.mozilla.org/projects/security/ pki/nss/, 08 2009.

[Moz10a] Mozilla. Firefox :: Firefox add-ons. https://addons.mozilla.org/de/firefox/addon/ 10868/, 10 2010.

[Moz10b] Mozilla. Firefox sync. http://www.mozilla.com/de/firefox/sync/, 10 2010.

[Moz10c] Mozilla. Firefox sync :: Versions :: Firefox add-ons. https://addons.mozilla.org/de/ firefox/addon/10868/versions/?page=2, 10 2010.

[Moz10d] Mozilla. Firefox sync privacy policy. https://services.mozilla.com/privacy-policy/, 05 2010.

[Moz10e] Mozilla. Labs/weave/sync/1.1/setup. https://wiki.mozilla.org/Labs/Weave/Sync/1. 1/Setup, 10 2010.

[Moz10f] Mozilla. Labs/weave/user/1.0/setup. https://wiki.mozilla.org/Labs/Weave/User/1.0/ Setup, 09 2010.

[Moz10g] Mozilla. Mozilla wiki: Labs/weave/crypto. https://wiki.mozilla.org/Labs/Weave/ Crypto, 08 2010.

[Moz10h] Mozilla. Mozilla wiki: Labs/weave/developer. https://wiki.mozilla.org/Labs/Weave/ Developer, 02 2010.

[Moz10i] Mozilla. Mozilla wiki: Services/sync/fxsync/releases. https://wiki.mozilla.org/ Labs/Weave/Roadmap, 07 2010.

[Moz10j] Mozilla. Mozilla wiki: Services/sync/server/api. https://wiki.mozilla.org/Services/ Sync/Server/API, 07 2010.

[Moz10k] Mozilla. Overview of nss open source crypto libraries, 12 2010.

[Moz10l] Mozilla. What are the main features of weave? http://mozillalabs.com/sync/ what-are-the-main-features-of-weave/, 10 2010.

20 [Moz10m] Mozilla. Wie lesezeichen und einstellungen zwischen computern synchro- nisiert werden können. http://support.mozilla.com/de/kb/Wie+Lesezeichen+und+ Einstellungen+zwischen+Computern+synchronisiert+werden+k%C3%B6nnen, 10 2010.

[Ope10] Opera. Opera browser | schnelleres und sicheres internet | gratis download. http: //de.opera.com/, 10 2010.

[Tod10] Todd. End of the road. http://blog.xmarks.com/?p=1886, 09 2010.

21