Closed Bug 1700378 Opened 7 months ago Closed 7 months ago

Nonstop logging in Browser Console of "HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt."

Categories

(Core :: Networking: HTTP, defect)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: cpeterson, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

I was looking in the browser console for an error and I see a nonstop stream of messages about HTTPS-Only Mode logged multiple times per second.

I'm using 88 Nightly on macOS.

HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.

Christoph, do we actually need this warning ?
Should we remove it?

Flags: needinfo?(ckerschb)

I mean if this is expected behavior then it makes sense to talk about disabling this warning by default.

But I think the bigger issue is that the captive portal service is sending out so many requests in such a short amount of time.

I don't see these messages in a clean profile, so presumably some setting or extension I have installed is causing this. I disabled all my extensions and restarted in Safe Mode, but I still see these log messages.

This issue only happens when I switch my DoH provider from Cloudflare to NextDNS. But I still can only reproduce the issue in my regular profile, not a clean profile.

I have "Enable HTTPS-Only Mode in all windows" checked.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #1)

Christoph, do we actually need this warning ?
Should we remove it?

I thought that our console consolidates such messages so it's less noisy. I thought we just increment some counter at the end of the line.

Anyway, we can certainly disable the warning, though as Julian pointed out. Why do we send it so often?

Flags: needinfo?(ckerschb)
Attached file about:support

(In reply to Julian Gaibler from comment #2)

I mean if this is expected behavior then it makes sense to talk about disabling this warning by default.

But I think the bigger issue is that the captive portal service is sending out so many requests in such a short amount of time.

We do these checks periodically (every minute for the first 10 minutes), or on every network change.
Could we disable the warnings if they are triggered by the system principal?

Hi Chris,

I'm rather curious why the messages would appear several times a second.
Could you maybe record some HTTP logs for us? https://firefox-source-docs.mozilla.org/networking/http/logging.html
Set the logging modules to: sync,timestamp,CaptivePortalService:5,nsHostResolver:5,nsHttp:5,nsNotifyAddr:5
Thanks!

Flags: needinfo?(cpeterson)

Here is a networking log.

I noticed that right before each HTTPS-Only Mode warning was a log message about polling a google.com domain (calendar.google.com, docs.google.com, or play.google.com). I have multiple tabs with Google Docs, Google Calendar, and Gmail open.

Alternate Service Mapping found: https://play.google.com:-1 to https://play.google.com:443
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.
Alternate Service Mapping found: https://docs.google.com:-1 to https://docs.google.com:443
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv4” because it is exempt.
HTTPS-Only Mode: Not upgrading insecure request “http://detectportal.firefox.com/success.txt?ipv6” because it is exempt.
Flags: needinfo?(cpeterson)

Thank you for the logs! They are very useful.

It seems the captive portal checks are triggered by the cert errors when connecting to the nextDNS DoH server.

2021-03-25 05:29:56.195 ⁃ nsHttpChannel ⁃ 1b0ccf000 ⁃ released ⁃ status=805a2ff4 ⁃ http-status=n/a ⁃ url=https://firefox.dns.nextdns.io/
...
2021-03-25 05:29:56.260536 UTC - [Parent 30658: Main Thread]: V/nsHttp nsHttpChannel::OnStopRequest [this=1b0ccf000 request=13ffd77e0 status=805a2ff4]

It seems you have the following prefs set:
network.trr.bootstrapAddress: 1.1.1.1
network.trr.confirmationNS: skip
network.trr.mode: 2
network.trr.uri: https://firefox.dns.nextdns.io/

The bootstrap address is set to the cloudflare IP, but the URI is set to nextdns.
That means we connect to the cloudflare server and expect a response with the nextdns certificate, which triggers a cert error.
Normally after a few of these failures we'd stop using TRR, but the confirmationNS is set to skip, so we keep doing it, and each cert error triggers a captive portal check.

Please clear these two prefs:
network.trr.bootstrapAddress: 1.1.1.1
network.trr.confirmationNS: skip

Things should be back to normal afterwards.
Thanks!

Flags: needinfo?(cpeterson)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #11)

Please clear these two prefs:
network.trr.bootstrapAddress: 1.1.1.1
network.trr.confirmationNS: skip

Things should be back to normal afterwards.

Thanks. Clearing the prefs stopped the log messages.

Sorry for the wild goose chase. I think I had changed these network.trr. * prefs long ago when trying to test DoH with other providers (like Quad9 DNS).

Status: NEW → RESOLVED
Closed: 7 months ago
Flags: needinfo?(cpeterson)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.