1605023 - DoH Rollout Extension: Don't treat an auto-enabled enterprise roots setting as a heuristic to disable DoH

Status: NEW

(Core :: Networking: DNS, defect, P3)

Description

[Maxx Crawford [:maxx]]

Ported from GitHub issue #105

:tdsmith: pointed out that Firefox sometimes automatically enables enterprise roots when a MITM is detected. When that happens, it's probably not a good signal of an enterprise configuration (it's typically antivirus software), so it could cause us not to enable DoH for lots of users who would benefit from DoH (even if their device is intercepting their TLS connections locally). The recommendation is that we don't disable DoH when both security.enterprise_roots.enabled and security.enterprise_roots.auto-enabled are true (the latter indicates that enterprise roots was enabled due to our MITM detection logic).

Comment 1

[Nhi Nguyen (:nhi)]

Nihanth, please re-triage this bug.

Comment 2

[(inactive) Nihanth Subramanya [:nhnt11]]

I talked to Dana about this briefly and it seems to be the case that we can't tell between AV and corporate middleboxes. Based on this, I'd err on the conservative side here and keep the disable-DoH action in this case.

Perhaps we should consider investing resources into figuring out which one is the majority case and make a more informed choice. Nhi, what do you think? I think we can close this bug and file a new one for this if we want.

Comment 3

[(inactive) Nihanth Subramanya [:nhnt11]]

Dana suggested Johann might have ideas about how to differentiate between AV software and corporate middleboxes when we detect MITM.

Comment 4

[Johann Hofmann [:johannh]]

Overall I would suspect a lot of MitM to be due to AV, so I wouldn't discard this case as unlikely in any scenario. What's tricky is that (AFAIU) security.enterprise_roots.auto-enabled could also be enabled in an enterprise setting, when the company performs a MitM but only imported the roots into the OS store. So I wouldn't rely on (only) that to detect AV.

Instead, we literally have a list of installed antivirus software available at runtime, via Services.sysinfo.getProperty. The most concise example how to use it is probably here: https://searchfox.org/mozilla-central/rev/9e45d74b956be046e5021a746b0c8912f1c27318/toolkit/modules/Troubleshoot.jsm#308

I would recommend to use that, instead, optionally in combination with security.enterprise_roots.auto-enabled :)

Maybe Romain has a list of known AV softwares that perform MitM?

Comment 5

[Johann Hofmann [:johannh]]

Also note that security.enterprise_roots.auto-enabled will not be immediately available on startup on a fresh install, but will be added after the user encounters their first certificate error due to mitm and we need to fix it.

Comment 6

[Romain Testard [:RT]]

Maybe Romain has a list of known AV softwares that perform MitM?
Most AVs do MITM but most also can have it disabled through a preference.
Also I think that the data Services.sysinfo.getProperty offers is not enough to make a call on whether the user is MITMed by his AV because:

• This string does not offer details of product type and version. Features vary per product and version and AVs ofter don't apply different strings for products and version
• An AV deployed in a corporate environment will likely have non default settings managed centrally by a sys admin, meaning MiTM may be enabled even though it is disabled by default on the software version/product

Comment 7

[Nhi Nguyen (:nhi)]

It sounds there's really no reliable way to distinguish AV and enterprise ? I agree that we should err on the side of precaution on this case and not enable DoH (small difference in wording but meaningful regardless: we're not disabling DoH for those users, we're just not taking any action to turn it on for them).

Comment 8

[Wayne Thayer]

Since our goal is to enable DoH for as many users a s possible, further investigation into the heuristic is worthwhile, in order to reduce the number of "enterprise false positives".