Weaving secure synchronization into Mozilla Firefox - Mozillas Sync Extension - (WS10/11)
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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 BochumContents
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
iList 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
1several 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.
1
Depending on the used browser bookmarks are also called favorites.
22 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 .
1
API stands for application programming interface.
2
Open source means that the used source coded can be openly reviewed.
3
This source code was accessed on 27th October 2010 (http://hg.mozilla.org/services/fx-
sync/log?rev=c540c68ecda1).
4
This source code was accessed on 14th November 2010 (http://hg.mozilla.org/services/reg-server/).
5
This source code was accessed on 14th November 2010 (http://hg.mozilla.org/services/sync-server/).
32.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
6
See "extension dir/modules/util.js"
4groups 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
7
PBKDF2 stands for Password Key Derivation Function 2.
5Each 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
8
Cipher Block Chaining - an encryption mode for block cipher
6encoded 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
9
ASN.1 stands for Abstract Syntax Notation One.
7exact 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.
10
nginx is a web server written in C.
11
Lines 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
82.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
12
Google recaptcha (http://recaptcha.net/) is a free anti-bot service that helps digitize books.
13
PHP Data Objects Extension (PDO) http://php.net/manual/en/book.pdo.php
9The 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 JSON 14 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.
14
JSON stands for JavaScript Object Notation.
15
CNAME stands for canonical name and describes an alias name for an IP address.
103 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.
1
See http://www.wireshark.org
2
See http://portswigger.net/burp/
3
The 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.
113.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.
4
The unix timestamp is easier to calculate and to process than the human readable representation of hours and
minutes.
5
As earlier mentioned in chapter 2.1.
12Sync 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.
13Sync 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.
14Sync 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
15local 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
16Figure 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.
6
xpi is the file extension for Firefox extension installer packages.
173.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.
7
VPN stands for Virtual Private Network.
184 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.
19Bibliography
[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.
21You can also read
