Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Private by Design: How We Built Firefox Sync

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#91

Post by krageon »

Benjamin_Dobell wrote: post #88
hnaccy wrote: post #85

Earlier quoted context omitted.

You can verify hash with others or compile it yourself.

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…

With attack vectors it's also about ease of exploitation. In this case, the ease is high. If the person you are responding to compiles their own browser, the bar to put an exploit in there is already much higher. Yes, there are still attack vectors. And there always will be. The point is they're harder to access.

Re: Private by Design: How We Built Firefox Sync

#92

Post by alpaca128 »

d0100 wrote: post #78

I use sync. Unfortunately, sending tabs works very randomly. Sometimes I have to send tabs from one device, just to receive tabs I had sent (like "refreshing" the tab sender)...

My experience with that feature is better. It may take a couple of minutes until it's actually synced and opened on the other device, but recently it's been quite reliable for me.

Re: Private by Design: How We Built Firefox Sync

#93

Post by Benjamin_Dobell »

krageon wrote: post #91
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…

With attack vectors it's also about ease of exploitation. In this case, the ease is high. If the person you are responding to compiles their own browser, the bar to put an exploit in there is already much higher. Yes, there are still attack vectors. And there always will be. The point is they're harder to access.

Your initial comment was pretty adamant that Mozilla had really messed up by delivering the code as JS. However, what is the attack vector that they've introduced by taking this approach?

It sounds to me like you're referring to a man-in-the-middle style attack. However, to be best of everyone's current knowledge, that's simply not possible with SSL.

It's only possible if the attack vector includes having already compromised the user's computer and installed a root certificate. At which point this is all pretty moot.

Re: Private by Design: How We Built Firefox Sync

#94

Post by beatle_sauce »

The new Firefox sync (v1.5) is surely great and has good usability, I preferred the old Firefox sync (v1.1), because it didn't require a Mozilla account (for password retrieval). The new service requires two servers for one's fully own setup (for managing accounts and a sync server), although it is possible to use Mozillas account server.

Also, from the description of the protocol ( https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... ) it was not clear to me, what exactly is encrypted? Only the passwords? I had the impression that the bookmarks were stored in a way readable by Mozilla.

Update. It is not clear what kind of data is in "Class-A" as described here: https://wiki.mozilla.org/Identity/AttachedServices/Architect... ... It also says:

> we can share e.g. bookmarks with a third party (by telling them the decryption key)

Re: Private by Design: How We Built Firefox Sync

#95

Post by krageon »

Benjamin_Dobell wrote: post #93
krageon wrote: post #91

Earlier quoted context omitted.

With attack vectors it's also about ease of exploitation. In this case, the ease is high. If the person you are responding to compiles their own browser, the bar to put an exploit in there is already much higher. Yes, there are still attack vectors. And there always will be. The point is they're harder to access.

Your initial comment was pretty adamant that Mozilla had really messed up by delivering the code as JS. However, what is the attack vector that they've introduced by taking this approach? It sounds to me like you're referring to a man-in-the-middle style attack. However, to be best of everyone's current knowledge, that's simply not possible with SSL. It's only possible if the attack vector includes having already com…

I think you have me confused with someone else. I have made no points except the ones in the post you are responding to.

In this case it looks like you're missing the fact that you can change the JS on the server with a high amount of ease and a low discoverability (it can be changed just for you and it won't show anywhere else).

Re: Private by Design: How We Built Firefox Sync

#96

Post by superflyguy »

I love Firefox but sync is by far the worst aspect. You can't use password syncing if you have a master password. Why, and more importantly, why doesn't the user get told this rather than passwords just silently not syncing? Who decided that was that the user would want or expect? Even without the master password I find password syncing rather hit and miss.

Re: Private by Design: How We Built Firefox Sync

#97

Post by Benjamin_Dobell »

krageon wrote: post #95
Benjamin_Dobell wrote: post #93

Earlier quoted context omitted.

Your initial comment was pretty adamant that Mozilla had really messed up by delivering the code as JS. However, what is the attack vector that they've introduced by taking this approach? It sounds to me like you're referring to a man-in-the-middle style attack. However, to be best of everyone's current knowledge, that's simply not possible with SSL. It's only possible if the attack vector includes having already com…

I think you have me confused with someone else. I have made no points except the ones in the post you are responding to. In this case it looks like you're missing the fact that you can change the JS on the server with a high amount of ease and a low discoverability (it can be changed just for you and it won't show anywhere else).

> I think you have me confused with someone else. I have made no points except the ones in the post you are responding to.

My apologies, that's what I get for reading on my mobile.

> In this case it looks like you're missing the fact that you can change the JS on the server with a high amount of ease and a low discoverability (it can be changed just for you and it won't show anywhere else).

You raise a reasonable point. It is indeed something everyone should be aware of. It's mostly a matter of trust, not security.

However, the same is equally true of someone you trust changing the binaries, source and/or hashes that are delivered to you; whether you got those from Mozilla, or somewhere else.

For example, the relatively recent Handbrake release compromise - https://news.ycombinator.com/item?id=14281808

Re: Private by Design: How We Built Firefox Sync

#98

Post by AsyncAwait »

mmirate wrote: post #51
riquito wrote: post #48

Earlier quoted context omitted.

If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high bar

On larger Linux distributions, the trust is less with Mozilla and more with the distro-package maintainers - use of dynamically remote-loaded JavaScript here shifts the trust back to Mozilla; if you trust your maintainers but not Mozilla, then this is a problem.

You really need to trust both. A browser vendor has so many layers to attack you, if they're malicious, that there's no way around it. Same for package maintainers.

Re: Private by Design: How We Built Firefox Sync

#99

Post by callahad »

beatle_sauce wrote: post #94

The new Firefox sync (v1.5) is surely great and has good usability, I preferred the old Firefox sync (v1.1), because it didn't require a Mozilla account (for password retrieval). The new service requires two servers for one's fully own setup (for managing accounts and a sync server), although it is possible to use Mozillas account server. Also, from the description of the protocol ( https://github.com/mozilla/fxa-aut…

Everything is Class-B. Class-A and Class-C are relics of ideas we had back in 2013 that we did not pursue.

Specifically, once of the consequences of Class-B is that your encryption key is derived from your password. If you forget and reset your password, you necessarily lose access to all of your synced data. (Though we did recently add support for recovery keys: https://support.mozilla.org/en-US/kb/reset-your-firefox-acco...)

The idea behind Class-A was to let users choose to place some less sensitive data--like bookmarks--into a bucket which survived password resets at the cost of Mozilla holding a copy of the encryption key.

The idea for Class-C was to allow users to generate and an entirely separate encryption key entirely separate from their password, as with Sync 1.1, but at the cost of more complex setup when adding a new device: you have to either maintain a backup copy of the key, or always have a previously configured device on hand for PAKE. Our experience with Sync 1.1 taught us that this does not work with real people at scale; people often lost data as a consequence of this design.

Re: Private by Design: How We Built Firefox Sync

#100

Post by joekrill »

rauhl wrote: post #44

Sadly, I believe that Firefox Accounts — upon which Firefox Sync is built — are insecure in execution. The security of the whole system relies on keeping your password secret from Mozilla, but as you can see when accessing https://accounts.firefox.com/oauth/signin?scope=profile&clie... your browser downloads the JavaScript it will use to derive your authentication token from Mozilla. There’s nothing stopping Mozilla…

How could this even possibly be mitigated, though? At some point you have to trust something, right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.
Post reply on HN