1303183 - Add-on update metadata needs to use content-signing

Status: NEW

(Toolkit :: Add-ons Manager, enhancement, P3)

Description

[Daniel Veditz [:dveditz]]

Currently add-on updates rely solely on the TLS connection for security. We do pin AMO to a number of trusted CAs but it's still weak:
  * corporate MITM bypasses pinning (by default; not in Tor)
  * built-in pins expire in really old clients
    ** AMO doesn't serve HPKP header to refresh clients
    ** that only helps if those clients are used
  * bugs can result in expired pins (bug 1303127)
  * not unthinkable that our pinned CAs could get hacked although we've
    tried to pick trustworthy ones.
  * if you're really paranoid, gov'ts could compel our pinned
    CAs to produce certs

We really need to sign the update.rdf content in addition to securing the communication channel with TLS and pinned certs. We should be able to use the Kinto content-signing stuff we're adding to the blocklist.

Would be super-nice if we got this done in time to ship with 52 so it's on the next ESR branch (Tor browser, Linux distros). If not it still might be worth back-porting to that branch if we haven't diverged too much by time it's done.

Comment 1

[Daniel Veditz [:dveditz]]

"sec-moderate" is somewhat misleading. If all goes to plan there's no problem, but if any one of those bullet points go wrong (not easy) then someone could MITM our updates and fully compromise the user (sec-critical).

Comment 2

[Kris Maglione [:kmag]]

(In reply to Daniel Veditz [:dveditz] from comment #0)
> Currently add-on updates rely solely on the TLS connection for security. We
> do pin AMO to a number of trusted CAs but it's still weak:
>   * corporate MITM bypasses pinning (by default; not in Tor)

Does it? If they use local certs to bypass pinning, they should still be
rejected by the update service for not using built-in certs.

>   * built-in pins expire in really old clients
>     ** AMO doesn't serve HPKP header to refresh clients

We can (and should) fix that.

>     ** that only helps if those clients are used

What clients would it not help in?

>   * not unthinkable that our pinned CAs could get hacked although we've
>     tried to pick trustworthy ones.

Couldn't that also be solved verifying the ID of the TLS cert rather than
adding another signature check on top of it?

Comment 3

[Julien Vehent]

> Couldn't that also be solved verifying the ID of the TLS cert rather than
> adding another signature check on top of it?

That's a good bad idea. If the private key of said cert leaks and we need to rotate it in emergency, clients will break. We could always have two keys, just in case, but the operational burden is non-null.

> if you're really paranoid, gov'ts could compel our pinned CAs to produce certs

If you're really paranoid, gov'ts could also compel us to hack into our users. That threat model is really hard to defend against. Transparency and canaries might make a good safety net here.

Comment 4

[Kris Maglione [:kmag]]

(In reply to Julien Vehent [:ulfr] from comment #3)
> > Couldn't that also be solved verifying the ID of the TLS cert rather than
> > adding another signature check on top of it?
> 
> That's a good bad idea. If the private key of said cert leaks and we need to
> rotate it in emergency, clients will break. We could always have two keys,
> just in case, but the operational burden is non-null.

The same goes if the private key for the content signing cert is leaked.

Comment 5

[Andy McKay]

I'd be interested in seeing how much of the kinto blocklist service and protocol we could use just to make maintenance easier. The update service gets a large amount of traffic, but the changes are actually infrequent and could be probably be pre-calculated, signed and cached.

cc'ing Tarek for kinto stuff.

Comment 6

[Julien Vehent]

> The same goes if the private key for the content signing cert is leaked.

Content signing uses the same PKI used for addons signing, so if a private key leaks, we just revoke it in onecrl and generate a new one. (The PKI root private key is stored in offline HSMs)

> I'd be interested in seeing how much of the kinto blocklist service and protocol we could use just to make
> maintenance easier. The update service gets a large amount of traffic, but the changes are actually infrequent
> and could be probably be pre-calculated, signed and cached.

All of it! The service (autograph) is independent from Kinto and used by Normandy as well. VersionCheck can be a third consumer. If changes are infrequent and we can cache the signatures, the current service will get you going in no time.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to Kris Maglione [:kmag] from comment #2)
> >   * corporate MITM bypasses pinning (by default; not in Tor)
> 
> Does it? If they use local certs to bypass pinning, they should still be
> rejected by the update service for not using built-in certs.

You're right. The articles even mentioned that error message.

> >     ** that only helps if those clients are used
> 
> What clients would it not help in?

If someone left a Firefox lying around on disk unused then it's not getting any updates, neither to the built-in static pins nor from pinging AMO for updates (once we fix the server to send HPKP). Then when the user decides to brush the dust off their Firefox (to compare something to their normal browser? because we had a compelling ad or social word of mouth and they want to try it again?) then the pins will have expired and they will be unprotected when Firefox does its various update checks.

Comment 8

[mancha]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> If someone left a Firefox lying around on disk unused then it's not getting
> any updates, neither to the built-in static pins nor from pinging AMO for
> updates (once we fix the server to send HPKP). Then when the user decides to
> brush the dust off their Firefox (to compare something to their normal
> browser? because we had a compelling ad or social word of mouth and they
> want to try it again?) then the pins will have expired and they will be
> unprotected when Firefox does its various update checks.

As an additional wrinkle, dynamic pins are type DataStorage_Private for Tor Browser users (and vanilla Firefox users who set Private Browsing Mode). In these cases AMO dynamic pins will be ephemeral even if AMO's HPKP headers eventually set max-age=5184000 (or whatever the max lifetime ends up being).

This means older Firefoxes, whose static pins have expired, are vulnerable to MITM every time they start up if in private browsing mode.

Comment 9

[Tarek Ziadé (:tarek)]

(In reply to Andy McKay [:andym] from comment #5)
> I'd be interested in seeing how much of the kinto blocklist service and
> protocol we could use just to make maintenance easier. The update service
> gets a large amount of traffic, but the changes are actually infrequent and
> could be probably be pre-calculated, signed and cached.
> 
> cc'ing Tarek for kinto stuff.

As pointed by julien, the signing service is independent, and already integrated in Kinto
with automatic signing. Also, everything is cached in Cloudfront.

We have a deployed instance right that's used for the blocklist and we could see to add
new records for the update.rdf signing.

Happy to talk about this in a meeting, will ping you