Collect the values of the enterprise-roots prefs in the telemetry environment
Categories
(Core :: Security: PSM, enhancement)
Tracking
()
People
(Reporter: tdsmith, Assigned: tdsmith)
References
Details
Attachments
(3 files, 1 obsolete file)
47 bytes,
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details | Review |
2.13 KB,
text/plain
|
mmccorquodale
:
data-review+
|
Details |
56 bytes,
text/x-github-pull-request
|
Details | Review |
We're planning some DoH heuristics that will want to understand whether the enterprise-roots behavior has been enabled or auto-enabled, and we want to collect telemetry to understand how often this heuristic will trigger. This seems like it ought to be of general interest in order to allow us to understand the prevalence of AV MitM and enterprise-roots configuration in the Firefox userbase, so I propose collecting it for all users.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Having these values in telemetry will let us understand the prevalence of AV MitM in the wild,
and understand how often these values have been manually configured.
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Comment 3•5 years ago
|
||
Comment on attachment 9071658 [details] Data collection review For context, a couple of recent data-reviews for adding prefs to this list: https://bugzilla.mozilla.org/show_bug.cgi?id=1485156#c4, https://bugzilla.mozilla.org/show_bug.cgi?id=1463911#c13
Comment 4•5 years ago
|
||
I just want to clarify that collecting the values of the enterprise-roots prefs in telemetry will only quantify MITM breakage occurences, but not MITM occurences.
environmentsecurity.certerrors.mitm.auto_enable_enterprise_roots will enable the enterprise roots preference only upon detection of broken MITM (i.e cert insertion issues by third party AV causing HTTPs to break when intercepted). Most MITMing that happens with AVs is not broken and unless an error is detected the enterprise roots won't be enabled.
Assignee | ||
Comment 5•5 years ago
|
||
Got it; thanks for the context, Romain.
I hadn't fully appreciated that distinction (that this toggles for broken MitM), but the DoH team will still care about the frequency at which it gets toggled, and I think this is still important to observe for the same reasons.
Comment 6•5 years ago
|
||
Agreed and if there is a way to quantify MITMed users I'd also love to get that data point!
MITM happening on the client typically involved insertion of MITMer certificate inside our cert store - By looking at the share of Windows users with an AV and the default MITMing behavior those AVs have I assume that somewhere between 20% and 30% of Windows users get MITMed on their client but validating it would be good since I assume this can have all sorts of implications for performance, security and web compatibility.
Comment 7•5 years ago
|
||
The pref you're looking for actually exists, it's called security.pki.mitm_detected
. CC Dragana who implemented that detection code.
Comment 8•5 years ago
|
||
Note that this also "just" does MitM detection on the updater service and thus in profiles where no update checks were run while under MitM or with AV software that explicitly whitelists our update servers it will not detect the MitM.
Assignee | ||
Comment 9•5 years ago
|
||
Thanks for the pointer! I updated the patch to also collect security.pki.mitm_enabled
, and here's an updated data-review form.
Updated•5 years ago
|
Comment 10•5 years ago
|
||
Comment on attachment 9072232 [details]
Data collection review
1. Is there or will there be documentation that describes the schema for the ultimate data set in a public, complete, and accurate way?
Yes, in the telemetry main ping documentation.
2. Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.
Yes, this can be turned off by opting out of telemetry collection.
3. If the request is for permanent data collection, is there someone who will monitor the data over time?
Yes, Tim Smith.
4. Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?
Category 1, technical data.
5. Is the data collection request for default-on or default-off?
Default on.
6. Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?
No new identifiers.
7. Is the data collection covered by the existing Firefox privacy notice?
Yes.
8. Does there need to be a check-in in the future to determine whether to renew the data?
No.
9. Does the data collection use a third-party collection tool?
No, this data is sent via telemetry.
Comment 11•5 years ago
|
||
Pushed by tismith@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/99fdfc9a7b82 Collect values of MitM-related preferences r=keeler
Comment 12•5 years ago
|
||
bugherder |
Assignee | ||
Comment 13•5 years ago
|
||
Comment on attachment 9071655 [details]
Bug 1558856 - Collect values of MitM-related preferences
Beta/Release Uplift Approval Request
- User impact if declined: Implementation of DNS over HTTPS could be delayed; we would not have information during the 68 cycle that we need in order to design heuristics for suggesting that users enable DNS over HTTPS without access to this data.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Not risky; adds a couple of prefs to an array driving an existing mechanism for collecting pref values in telemetry
- String changes made/needed: none
Comment 14•5 years ago
|
||
Comment on attachment 9071655 [details]
Bug 1558856 - Collect values of MitM-related preferences
approved for 68.0b12
Comment 15•5 years ago
|
||
bugherder uplift |
Comment 16•5 years ago
|
||
Description
•