Private by Design: How We Built Firefox Sync • Hacker News Board

Re: Private by Design: How We Built Firefox Sync

#151

Post by dcrn » Wed, Nov 14, 2018, 5:11 PM UTC

Vinnl wrote: post #74

nsriv wrote: post #45

Earlier quoted context omitted.

Probably this one [0], though I dislike the branding at the top of the sidebar and the fact that since FF lacks native support, you'll still have tabs on top of the window. [0]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

You can disable those tabs on the window, you just have to mess with the browser chrome's CSS yourself. Which is relatively easy, but basically the reason I haven't used it so far. But now that you mention it - I'm going to give it a shot now.

Here's a list of tweaks that you can try: https://github.com/piroor/treestyletab/wiki/Code-snippets-fo...

Re: Private by Design: How We Built Firefox Sync

#152

Post by abuckenheimer » Wed, Nov 14, 2018, 5:12 PM UTC

I've never heard of HKDF before but it is really an elegant solution to this. My first guess on how to do this would have been something stupid like split the Authentication token in half and 0 pad it. But this would have significantly reduced the entropy available on both keys, reducing the search space on the authentication token and the encryption key making them much more brute force able. HKDF instead expands the key and essentially requires the server to be able to reverse HMAC-Hash to find the encryption key from the the authentication token.

What I'm confused about is that they seem to be using HKDF as a hash [1] and not as a key generation funciton. I think this is just as secure as what I was expecting but it seems more complicated and doesn't jive with the purpose of the RCA[2] as I read it.

[1] https://github.com/mozilla/fxa-js-client/blob/1d92f0ec458ace... (separate HKDF calls with the same IKM)

[2] https://tools.ietf.org/html/rfc5869

Re: Private by Design: How We Built Firefox Sync

#153

Post by rocqua » Wed, Nov 14, 2018, 5:17 PM UTC

cyphar wrote: post #131

rocqua wrote: post #124

Earlier quoted context omitted.

if someone is using a package-manager that uses code signing then indeed, the binary is harder to attack than the JS. (only because the package-manager would need to collude). However, a lot of people get their software from downloaded .exe's or auto-upgrading installations. For them, JS or binary are equally vulnerable. (All it takes is a mozilla signature) Besides, it is undeniably better to only be vulnerable to a…

Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution. And even the "download .exes from the internet" usecase is precisely as secure as downloading JS from the internet that is verified once per install. To attack someone who has an auto-updating Firefox and downloaded it from the internet, you nee…

> So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument

I agree. I was arguing for having some form of e2e encryption (like Firefox currently has) as opposed to not having e2e encryption. I wanted to argue against the idea that, because the e2e was implemented in JS, one might as well not have it.

Then, regarding the gap between e2e in JS vs e2e in binary, my point was that JS is just as good in most cases.

> Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution.

Does that mean that the code is only signed by the package distributor, and not mozzilla? Because in that case, the package manager becomes a single point of failure. Then again, I guess that is always the case. Still, it would be weird that, as far as mozzilla trust goes, a signed exe from internet is better than a signed package from your preferred package manager.

Re: Private by Design: How We Built Firefox Sync

#154

Post by fulafel » Wed, Nov 14, 2018, 5:50 PM UTC

jniedrauer wrote: post #121

fro0116 wrote: post #108

Earlier quoted context omitted.

"Every time" for this use case is once per browser install, at the moment you perform the authentication with Firefox Sync, which is the same as the number of times you'd want to verify the binary right before authenticating. The tradeoff they made here has essentially zero impact on the number of times you need to verify their code, it's just a matter of whether you'd have to verify browser native authentication cod…

You're still not addressing the ease with which a targeted attack can be directed at a single user. In order to compromise firefox native code, they would have to compile malicious code and ship it to everyone . My distro maintainers would need to include the malicious binary in their repos, including a signed hash of the compromised binary, and I'd need to install it, where my package manager would verify the hash.…

The vast majority of Firefox users receive updates from Mozilla via the auto-update mechanism, which would also be vulnerable to the compromise in a similar way.

(A Linux distribution could also be compromised and used in a targeted way of course)

Re: Private by Design: How We Built Firefox Sync

#155

Post by noisem4ker » Wed, Nov 14, 2018, 6:16 PM UTC

Quai wrote: post #75

I was involved in implementing the first browser-to-browser, and browser-to-mobile sync. Opera Link (codename Pangea) was my first really large project in the company, and while desktop team had multiple persons working on the feature, the server side was designed, implemented and maintained by two guys plus a QA person. We decided not to encrypt the user information for multiple reasons; user friendliness, data reco…

Thanks for sharing your experience.

Re: Private by Design: How We Built Firefox Sync

#156

Post by tomrittervg » Wed, Nov 14, 2018, 6:55 PM UTC

zimbatm wrote: post #105

Benjamin_Dobell wrote: post #88

Earlier quoted context omitted.

Did you personally, and at least one other trusted party, sign off on every single commit, or are you trusting Mozilla? Where did you get the hash you're comparing against? Firstly, no matter what you're trusting the developers of the software you're running on your computer. Secondly, the software (and/or its hash), just like this JavaScript, is delivered to you in a verifiably secure fashion i.e. SSL. What's the di…

The question is how hard it is to detect tampering. My linux distribution builds firefox from source and signs the build. The builds are also checked to be reproducible. Raising the bar is a good thing.

I wasn't aware that any distribution (besides Tor Browser) was building Firefox (or anything really) reproducibly.

There's debian's https://reproducible-builds.org/ effort, but I thought that wasn't making much progress lately, nor was it deployed.

Could you provide more info on what distro you're using, or how they're doing this?

Re: Private by Design: How We Built Firefox Sync

#157

Post by Vinnl » Wed, Nov 14, 2018, 6:59 PM UTC

dcrn wrote: post #151

Vinnl wrote: post #74

Earlier quoted context omitted.

You can disable those tabs on the window, you just have to mess with the browser chrome's CSS yourself. Which is relatively easy, but basically the reason I haven't used it so far. But now that you mention it - I'm going to give it a shot now.

Here's a list of tweaks that you can try: https://github.com/piroor/treestyletab/wiki/Code-snippets-fo...

Thanks! I was looking for the best snippet to hide it, and this one is a bit more specific than the one I was using. (Plus, it allowed me to hide the bar in full-screen.)

Re: Private by Design: How We Built Firefox Sync

#158

Post by tomrittervg » Wed, Nov 14, 2018, 7:01 PM UTC

qwerty456127 wrote: post #112

Cool but there is a lot more that can be done to improve a browser privacy by fighting fingerprinting. I.e. provide standardized sets of data about the host system via JS APIs: only list a standard set of fonts (+ those a user consciously chooses to expose), a most common display resolution that is less or equal to the real display resolution of the machine, obfuscate canvas/webgl/cache response time etc. Extensions…

I happen to also work on Firefox/Tor Browser's anti-fingerprinting work, so yea - we're trying to make improvements there too =)

Containers is a big Firefox feature (exposed through an Add-On) in this category too.

As far as Web Extension APIs, I don't know much about that, but if you have an API that would enable a use case that Mozilla doesn't have a bug on and haven't considered; you are welcome to file a bug explaining what you would like and what you would use it for, and the Web Extension team will consider it.

Re: Private by Design: How We Built Firefox Sync

#159

Post by tomrittervg » Wed, Nov 14, 2018, 7:06 PM UTC

abuckenheimer wrote: post #152

I've never heard of HKDF before but it is really an elegant solution to this. My first guess on how to do this would have been something stupid like split the Authentication token in half and 0 pad it. But this would have significantly reduced the entropy available on both keys, reducing the search space on the authentication token and the encryption key making them much more brute force able. HKDF instead expands th…

From the RFC: "Its goal is to take some source of initial keying material and derive from it one or more cryptographically strong secret keys."

In our case, the initial keying material is the output of PBKDF; and the two outputs we use are used as an encryption key and a bearer token (essentially a password but I call it an authentication token to avoid confusion with your actual password). There are less complicated ways to do this; but this one is cryptographically conservative.

"essentially requires the server to be able to reverse HMAC-Hash to find the encryption key from the the authentication token" - the server can't do that; which is why the server can't figure out your encryption key from your authentication token. (The best the server could do would be to try a password guessing attack.)

Re: Private by Design: How We Built Firefox Sync

#160

Post by tomrittervg » Wed, Nov 14, 2018, 7:11 PM UTC

m000 wrote: post #130

How portable is Firefox Sync to other browsers? I find myself in need to keep both Firefox and Chrome open at all times (different websites work better with either of them). I would like to have at least my bookmarks and passwords synced—don't really care for history or tabs. LastPass and others provide a cross-browser password sync service. But after Xmarks having been discontinued, I could not find find any cross-b…

There are more details above but the short version is that it is possible to build extensions for other browsers that work with Firefox Sync. But the only one linked seemed to be for Gnome's browser, so no one may have actually done it.