[Go Faster] Q3 Goal Tracking -Security policy updates through new update service

RESOLVED FIXED

Status

()

Core
Security: PSM
P3
normal
RESOLVED FIXED
3 years ago
8 months ago

People

(Reporter: Larissa Shapiro, Assigned: tarek)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [psm-tracking])

Attachments

(1 attachment)

Comment hidden (empty)
(Assignee)

Updated

3 years ago
Summary: [Go Faster] Q3 Goal Tracking -Security policy updates through new update service ("Balrog 2.0") → [Go Faster] Q3 Goal Tracking -Security policy updates through new update service
(Assignee)

Updated

3 years ago
Depends on: 1187936
(Assignee)

Updated

3 years ago
Depends on: 1187938
Depends on: 1187983
Noting for the record: the updater on Android is a separate Java service. When filing client implementation bugs, please file Fennec's in Android Background Services :: Updater and CC me, :snorp, and :esawin.
Depends on: 1193877
Depends on: 1187949
(Assignee)

Updated

3 years ago
Depends on: 1189435
Depends on: 1197703

Updated

3 years ago
Blocks: 1189435, 1197703
No longer depends on: 1189435, 1197703
We've made the following decisions:

Basics
------

    - Updater has a public + private certificate that can be used to sign a hash of the records + the collection.

    - Destination has the updater's public certificate that can be used to check the signature of the records.

    - Each Certificate Revocation Entry is represented with its fingerprint (it can be intermediates certificates fingerprint)

    - All the hashing and signing is done on the clients to avoid attack vectors (if an attacker obtain access to the Kinto server)



First issuance of the list
--------------------------

    1. All items in the CRL are gathered and put in a collection of JSON items.

       Each item contains a client-side generated UUID. e.g.

> {"id": "b7dded96-8df0-8af8-449a-8bc47f71b4c4", 
>  "fingerprint": "11:D5:D2:0A:9A:F8:D9:FC:23:6E:5C:5C:30:EC:AF:68:F5:68:FB:A3"}


  2. Compute the collection hash, sign it and upload it to the server.


How to check for data integrity?
--------------------------------


    1. Gather all the records from the remote server + the collection hash and signature;

    2. Check the signature of the retrieved collection hash. Compute the collection hash locally. Check if it matches with the one retrieved from the server.



Update of the list
------------------

    1. Check the validity of the data we are building upon, as specified in "How to check data integrity".

    2. Add new records, as specified in "First issuance of the list".



How to compute the hash of the collection?
------------------------------------------

    1. Sort all items in the collection (by id);

    2. For each item, serialize the wanted fields (concat them together)

    3. Compute the hash from the serialization.


Steps forward
-------------

- Add the ability to store metadata information on collections on Kinto. https://github.com/Kinto/kinto/issues/158 This will be used to store the signature and hash.
- mgoodwin writing a kinto client in JS that will be burned into Firefox and take care of verifying signatures.
- Architecture to be more defined (where every machine leaves and how they are isolated from each other.
  How do we add caching to the mix etc).

Timelines
---------

- We want to have "something" in the browser by the end of this quarter; We'll have something shipped inside Firefox behind a flag to start with.
- 43 is the target to have this the earliest. We need to figure out how to connect to the HSM from AWS.
Created attachment 8652436 [details]
kinto_signing_omphalos.JPG

Attached is a diagram of the workflow we agreed on today.
(Assignee)

Updated

3 years ago
Depends on: 1198614
(Assignee)

Updated

3 years ago
Assignee: nobody → tarek

Updated

2 years ago
Component: Tracking → Security: PSM
Priority: -- → P3
Whiteboard: [psm-tracking]
(Assignee)

Comment 4

2 years ago
Can we close this ?
Flags: needinfo?(dkeeler)
If this is meant to only target OneCRL, then sure. My impression from the summary is that this is intended to track implementing other security-related policy updates as well, though (e.g. the HSTS/HPKP preload lists).
Flags: needinfo?(dkeeler)
(Assignee)

Comment 6

2 years ago
I would be tempted to create a new bug for HSTS/HPKP since it's just client-side integration at this point - but it's up to your team I guess. Mark?
Flags: needinfo?(mgoodwin)
(In reply to Tarek Ziadé (:tarek) from comment #6)
> I would be tempted to create a new bug for HSTS/HPKP since it's just
> client-side integration at this point - but it's up to your team I guess.
> Mark?

These have been created:
See bug 1306470 and bug 1283109
Flags: needinfo?(mgoodwin)
(Assignee)

Updated

8 months ago
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.