GSoC 2016: Progress #2

Unexpected things happen all the time and plans get damaged accordingly. That was my case too: since around July 1, the Firefox Accounts server started to block direct requests to the account/login endpoint. As you may assume, this was (and still is) a real impairment to my project’s progress.

I had nothing to do but to ask for answers on the Mozilla’s sync-dev mailing list: turns out the Firefox Accounts service is currently operating with tightened security rules due to an uptick in suspicious login attempts. Unfortunately, this also increases the likelihood of blocking legitimate login attempts, if they appear too similar to the suspicious traffic.

The guys at Mozilla suggested that I should change my approach and use the JavaScript postMessage() API in order to login, rather than the protocol I’m using now, since their intention is to deprecate this protocol for general public use in the near future. Therefore, my next step is to try to implement this new login method in Epiphany. This requires a good amount of documentation to determine whether it is feasible for Epiphany in the first place, therefore my project is getting delayed accordingly.

The login phase is a crucial part to the sync flow, since this is how you obtain the sessionToken and the keyFetchToken, used to further retrieve the sync keys that enable the client to encrypt/decrypt synchronized data records.

Since I’ve pretty much spent my time on mailing lists and digging through Firefox code, I wasn’t able to make a noticeable progress in the last week. However, I managed to achieve two things:

  • implement a shortcuts window for Epiphany (during the downtime of my actual project). Shortcuts windows were introduced in GNOME 3.20 and provide a way for the user to see all the keyboard shortcuts for an application with their corresponding actions. Many applications had their shortcuts window ready before the 3.20 release, but Epiphany was not one of them.
  • implement the Fetching Sync Keys act. This means to process the keyFetchToken – which is received once the user logs in – (I had to use a restmail email to test this, apparently requests from test emails don’t get blocked by the server), and derive the tokenID and reqHMACkey that will be further used in the request to the account/keys endpoint. The server then responds with a hex bundle that undergoes multiple cryptographic operations to obtain the sync keys. This phase also gave me the opportunity to rethink some portions of my code and provide a better transparency between the crypto module and the service module.

Until I find a way to make login work again, there is nothing much I can do to advance my project. Hopefully, I’ll figure out how to implement the alternate login method, so I can proceed to establish the communication with the storage server.

Advertisements

GSoC 2016: Progress #1

This post may come a bit late, but I’ve been pretty much hooked to my end of semester finals over the last few weeks. However, exams are gone now so I can start focusing on my summer project. Accordingly, I’ve been working hard these last days to catch up with my timeline before the midterm.

For those of you who are not aware of my project, I’m working on the Web: Session Sync project, aiming to introduce a bookmarks sync feature for Epiphany with the help of Mozilla’s servers. As I’ve mentioned in my previous post, the first part of my project involves establishing a working communication with the Firefox Accounts Server. This implies implementing the client side of the onepw protocol in Epiphany a.k.a. being able to compute the protocol’s tokens, send both normal requests and Hawk requests to the server and derive the sync keys.

These being said, here are the things I’ve completed so far:

  • created different modules to divide my project’s functionality: a sync service (the core module, initiating every server-related action and invoking other modules), a cryptographic module (for computing and deriving the protocol’s tokens and generating Hawk requests headers), a secret module (for storing/retrieving encrypted tokens to/from disk – see below), and an utils module (for different utility functions).
  • implemented the PBKDF2 and HKDF algorithms used to derive the authentication tokens from the user’s email and password. One handy tool for this task was Nettle, a low-level cryptographic library, that proved very useful, having great APIs for hmac, sha256, pbkdf and many others.
  • implemented functionality for keeping the protocol’s tokens secret by encrypting them on disk with the help of libsecret. The idea behind this is that most of the tokens are persistent, meaning they won’t expire until the user logs out and the session is destroyed. Hence, once the user has logged in, the Sync Service will store the computed/retrieved tokens so they will be loaded directly from there for further use cases.
  • implemented functionality for generating headers for the Hawk requests. Hawk is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with partial cryptographic verification of the request and response. This was totally new to me but, fortunately, I was able to peek at Mozilla’s Python Hawk library on GitHub and understand how to properly generate a Hawk header.
  • added a new Sync tab to the Preferences dialog. This is the place where users should be able to log in with their Firefox Account in order to start the syncing process. As soon as the Login button is pressed, the Sync Service will stretch the user’s email and password and a subsequent call to the account/login endpoint will be issued, sending the previously computed tokens to the FxA Server. If the server validates the request, the sync service will proceed to compute the sync keys from the server’s response (this part I have yet to implement), otherwise a suggestive error message will be displayed.

sync-tab

That would be it for now. The next thing I’m planning to implement is the request to the account/keys endpoint along with the derivation of the sync keys from the response. I hope this post has shed some light on what I’m actually doing for my GSoC project!

See you the next weeks 🙂

GSoC 2016: Introduction

My name is Gabriel Ivașcu and I am a third year student at University Politehnica of Bucharest pursuing a Bachelor’s degree in Computer Science.

Ever since I joined university and got introduced to Linux I immediately became an avid fan of free and open source software, my passion evolving constantly since then. I’ve been using GNOME under Fedora as my standard desktop environment for about two years now.

I started contributing to GNOME in October 2015 with the help of my colleague and friend, Iulian Radu, a former participant of GSoC 2015 program and also a current participant in the 2016 edition. I worked mainly on Nibbles, Iulian’s 2015 project, and, later in February, we also began contributing to Web (a.k.a. Epiphany) under the guidance of Michael Catanzaro, our current mentor, who was kind enough to accept mentoring two projects this year.

Regarding my project, the ultimate goal is to introduce a session sync feature to GNOME Web. Session sync is an already present feature in many other popular web browsers such as Firefox, Chrome and Safari, which Epiphany lacks. As stated on the ideas page, the aim is to provide a simple and easy way for users to synchronize their bookmarks, history, saved passwords and open tabs between multiple devices.

Between Mozilla and OwnCloud, together with my mentor we concluded that Mozilla is a better option because it would allow users to seamlessly sync data with Firefox with only a Firefox account, no configuration required (OwnCloud would require the users to set up their own server). Yet Mozilla imposes a rather complex protocol that FxA clients need to use in order to communicate with the FxA server. Since implementing this protocol would require a considerable amount of work that I probably won’t have enough time left to finish all forms of sync (bookmarks, history, passwords, open tabs) my mentor agreed that I should focus on getting the protocol work and only implement bookmarks sync for the moment. Having a working form of bookmarks sync as reference, adding the extras at a later time would be relatively easy.

Due to my exams session between May 28 and June 17 I intend to start my work earlier during the Community Bonding period so I can cover the time lost with my unavailability during my exams.

I am very excited to be part of this and I hope good things will come out. Looking forward to the summer!