MitM detection in Firefox 67

[Okamoi]

Hi,

This issue can probably be closed immediately, since I think leaving the preferences below to default is good for this repo's user.js.

People who are reluctant to have any network connection with Mozilla might want to at least be informed about this, and some of us might decide to disable this feature.

The following prefs by default enable some kind of man-in-the-middle detection that occurs upon certain certificate error types, such as UNKNOWN_ISSUER:

security.certerrors.mitm.priming.enabled = true
security.certerrors.mitm.priming.endpoint = "https://mitmdetection.services.mozilla.com/"

When that happens, Firefox contacts the URL above and stuff happens to sort things out. It can be something benign, like a legitimate software installed on the user's computer that failed to install proper root certificates into Firefox, or it can be something serious, i.e. a real MitM attack. Then a special error page should be displayed with maybe a button to fix things.

Or something like that. My understanding of what's going on is blurry.

Source code with, well, code, and comments of interest:
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#3135
https://dxr.mozilla.org/mozilla-central/source/browser/actors/NetErrorChild.jsm#205

Relevant bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1529643

As someone who has long disabled OCSP, waiting for the day when the entire web could be MUST_STAPLE, or until maybe DNS-over-HTTPS fixed my concerns (assuming it does), I'm tempted to disable MitM Priming, or just replace the URL with data:text/plain, or an empty string. (I'm weary that the empty string will just be ditched by some parser and result in the default value being used, I think there at least one old precedent for that, so I tend to use data:text/plain,)

Reasoning is that it's coherent with disabling OCSP, and I'm confident that my computer is safe. What do you think ? Assuming a safe computer, what increased risk is there in blocking the connection to https://mitmdetection.services.mozilla.com/ versus allowing it ? The privacy gain is very small, like turning off a ping. It could be higher than assumed depending on what is sent over there, but I don't know what is actually sent. (e.g. The domain name could be sent, making it about as "revealing" as OCSP, but my impression is that it's not that kind of security check and might really be just a ping... I really don't know)

[Thorin-Oakenpants]

Yes, these were in the last diffs #687 , there's also

• security.certerrors.mitm.auto_enable_enterprise_roots

earthlng said

the 3 security.certerrors.mitm.* might be worth considering since it's an outgoing connection that some people might not want

but, I for one am a bit sick and tired of listing every single item. There's no security risk (enabled), there's no privacy risk (if you don't trust Mozilla to be responsible here, then stop using their product: I am not saying that they are above reproach or need vetting etc and held accountable), and the default is best left alone. So I'm not really interested in documenting it, TBH.

The privacy gain is very small

There is no privacy gain. Look, I do get that some people want to kill all outgoing connections etc, but most of this is overboard and baseless. Not judging anyone here, but man, some of the nutcases on online forums spouting the same BS - and anything sent to Mozilla servers is a conspiracy theory. I could list a heap of them, but I can't be bothered.

[Okamoi]

there's also security.certerrors.mitm.auto_enable_enterprise_roots

I ruled it out, thinking it did not lead to outbound connections, or maybe was local network related at worst. Don't bother looking it up, but if you know off hand that this assumption is incorrect I'll go dig it more on my own and come back with relevant info if there's any, for posterity.

 

I blanked the endpoint URL for now and will be looking a bit deeper into the topic in hopes to find out how this outbound connection is used.

Connecting to the URL returns the following:

<Error>
    <Code>NoSuchKey</Code>
    <Message>The specified key does not exist.</Message>
    <Key>404.html</Key>
    <RequestId>16 alphanumeric characters, upper case only</RequestId>
    <HostId>A bunch of alphanumeric characters both lower and upper case, + and =</HostId>
</Error>

When triggered correctly, the message would be different. Not sure if HostId is supposed to be Mozilla's site or the domain visited when the certificate error happened. In that case, data sent is more than a ping.

 

OFF TOPIC:

earthlng said

Ah, I missed that comment

Look, I do get that some people want to kill all outgoing connections etc, but most of this is overboard and baseless.

It is coherent to use Windows while blocking outbound connections to Microsoft. Same thing with the browser.

but, I for one am a bit sick and tired of listing every single item.

I was not asking for any change anywhere, I just figured that this place is the only place on the web where this topic can be discussed with people who are monitoring how Firefox evolves over time. When someone searches for a Firefox pref, they can find insight in this repo.

Maybe you don't want this repo to be used like this though. I can understand, but there's a lot of precious resources here beyond just the user.js. I don't know, I feel like centralizing everything one way or another here would be nice.

 

I know you would like to spend less time working on shit. Before you break completely and we all lose out, it may be nice to gather everyone reading this repo and figure out how to split tasks based on everyone's comfort areas, so that you can get away with less work and we still cover Firefox changes as they go. Ask people like me to engage X hours of work per update and break down the workload in a formal way between more people than the current two. (Sorry for the missing persons if it's more than two)

What I can do: Starting from the moment a pref differential appears on Earthlng's repo, I can dig information on those preferences that could be candidate to a spot in your user.js, while pushing others to the side. I can provide some recommendations for values to set them to, but I don't know the policy you use and don't rely on the user.js myself, so I shouldn't touch it.

I can dedicate one or two hours to this every update. With three people like me maybe that will start looking better for you ?

[claustromaniac]

Reasoning is that it's coherent with disabling OCSP, and I'm confident that my computer is safe. What do you think ? Assuming a safe computer, what increased risk is there in blocking the connection to https://mitmdetection.services.mozilla.com/ versus allowing it ? The privacy gain is very small, like turning off a ping. It could be higher than assumed depending on what is sent over there, but I don't know what is actually sent. (e.g. The domain name could be sent, making it about as "revealing" as OCSP, but my impression is that it's not that kind of security check and might really be just a ping... I really don't know)

AFAICT only headers are sent. It's an XMLHttpRequest using the HEAD method (it merely asks the server to return headers), and it even has the mozAnon flag set to true, meaning it doesn't send cookies or auth headers. They can get your IP from that and little more than that.

No matter how safe your computer is, detecting the presence of a MitM programatically requires the help of an external source (in one way or another). Even if you yourself tried to manually confirm the authenticity of a server (by comparing fingerprints), you would most certainly need the help of a third party for that (unless you go thru life recording fingerprints, and you just happened to have records on the specific server whose authenticity you wanted to verify)

[Okamoi]

Thanks. If you found that it's an XHR from the source, would you mind sharing the link ? (EDIT: Right here)

This check is only triggered upon a certificate error, meaning the user *should* get to see a certificate error regardless, and it should happen on (tentatively) secure connections only, not on HTTP, since there's a cert error. Considering that my computer is secure and I don't care about getting a more specific error page, the gain in security seems as small as the loss in privacy.

I'd clearly not advise anyone to turn the pref off, but I'm doing it for myself until I review my policy on OCSP. I'll keep an eye out to make sure errors like UNKNOWN_ISSUER do redirect the user to a certificate error page regardless of this pref, which just sets the page to one that makes a specific claim on MitM, from what I understand.

I hate those borderline preferences which require mass digging to make a decision.

[Thorin-Oakenpants]

When earthlng posts a new diff, feel free to make comments on anything significant: some will be obvious, but others need digging, despite E's bugzilla links. So anything that can speed up insights like extra links and thoughts is always welcome

[claustromaniac]

Actually, that code seems to be specifically aimed at detecting system-wide MitM, so it doesn't really have much to do with OCSP. The idea is that the check is made during a SEC_ERROR_UNKNOWN_ISSUER, to see if the error applies only to that connection, or if the same happens with the attempt to connect to https://mitmdetection.services.mozilla.com/. If that check throws the same error, you're most likely fucked.

[claustromaniac]

Back to your question...

Assuming a safe computer, what increased risk is there in blocking the connection to https://mitmdetection.services.mozilla.com/ versus allowing it ?

AFAICT, disabling priming or blocking requests to that host is not riskier, because the check itself requires the SEC_ERROR_UNKNOWN_ISSUER error to trigger in the first place. The real tradeoff is that Firefox can no longer reliably inform you that the error happened because you're likely being MitM'd. Also, the code for security.certerrors.mitm.auto_enable_enterprise_roots seems to depend on priming.. but, if I understand correctly, that's more for fixing breakage than for security.

[Okamoi]

, because the check itself requires the UNKNOWN_ISSUER error to trigger in the first place.

Which I assume does lead to display the corresponding UNKNOWN_ISSUER error page. (Like I think it did before Firefox 67)

The real tradeoff is that Firefox can no longer reliably inform you that the error happened because you're likely being MitM'd.

If you mean that Firefox cannot display the specific MitM error page, so it will stay on the default UNKNOWN_ISSUER error page, then great, that was my best guess, so if it's yours too, we're done ! As long as there's still *an* error page, I'm good.

(EDIT : And yes, there is, we can see that the MitM page is triggered from a block of code that was building a regular certificate error page)

so it doesn't really have much to do with OCSP.

Yeah, it's not the same purpose as OCSP; I was trying to say that data sent could be similar (from what you said, MitM priming is actually even less data) and that if a user is disabling something like OCSP, it seems incoherent to enable MitM priming. Both have in common that they rely on a third party to ensure certificates are valid, if I recall correctly. MitM priming is triggered way more rarely though, so much less of a privacy risk.

 

Thanks for taking the time to dig into this.

(EDIT: After a more comprehensive look at the code, I concluded that I would disable MitM Priming completely and not just neuter the URL. I'll review the decision when DNS-over-HTTPS is widespread, as part of a larger pref review. At any rate, the privacy exposure of this MitM Priming feature is ridiculous, almost non-existent, and the information provided can be critical as a MitM on secure connections is a really nasty thing, so readers should not copy me and keep the default values.)  

@Thorin-Oakenpants

So we don't duplicate work, as a first attempt and to test the workload, I can cover the last twenty items of the "New preferences" list and post in the yet-to-exist 67-to-68 issue, if you like. I hope I can react before you get there.

[claustromaniac]

(EDIT : And yes, there is, we can see that the MitM page is triggered from a block of code that was building a regular certificate error page)

Yes. I've seen those errors (and many others) with my own two eyes as I was developing an extension for Firefox <shamelessSelfPromotion>HTTPZ</shamelessSelfPromotion>. You can confirm there is such an error page just by looking at the code for priming though (3149-3152)

// Make sure the user is still on the cert error page.
      if (!browser.documentURI.spec.startsWith("about:certerror")) {
        return;
      }

The code in that function below that return statement doesn't run unless you're still seeing a cert error page, and just below that (in the next conditional), the error type is checked to make sure it's specifically SEC_ERROR_UNKNOWN_ISSUER, otherwise the function is aborted right there.