Closed Bug 1850773 Opened 1 year ago Closed 1 year ago

Private Internet Range 192.168.0.0 - 192.168.255.255 is NOT HTTPS Related

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Version:
Firefox 116
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bel, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

In a private tab enter a private network address beginning with http://192.168.x.x

Actual results:

The message "we could not verify the certificate: reason = untrusted" blocked the router app from opening by changing the address to https://192.168.x.x

Expected results:

Domestic broadband routers use private internet addresses begining with 192.168 which means users cannot login to their router for maintenance purposes such as a reboot. Internet spec RFC1918 (https://www.ietf.org/rfc/rfc1918.txt) describes private internet ranges. This is an undesirable feature of FF especially if the user has to expose a private address in a public tab. IMHO private internet ranges should be allowed in private tabs as exceptions. Private address ranges are intranet greenside addresses but FF treats them as risky redside. Similar behaviour is to be found in the Microsoft Edge. Whats going on?

Internet specs are being changed to recommend opportunistically upgrading of all http: connections to https:, and chromium browsers (including MS Edge) are doing the same. The "https-first" functionality we use by default in Private Browsing mode does this, and should detect the mismatched certificate and fallback to the original http:. Obviously not robust in the face of an active network attack, but a privacy win in the more common case of passive network sniffing.

The behavior you describe instead sounds like you have enabled "https-ONLY" mode. Safer, but this is the downside. When there's an upgrade failure you should be given the chance to override https-only mode for that address/domain through a widget in the URL bar. Alternatively, if you're sure that is the correct certificate for that device you could enter a certificate exception so that Firefox would treat that certificate as trusted for that address.

Ah, you mentioned "private tabs". Unfortunately saving site permissions (like the https-only exception) is not possible in Private Browsing because that leaves a record that you have visited that site. For the same reason you might have to create the certificate exception in regular browsing for it to "stick", but once you do it should work in private browsing mode as well.

If you HAVE NOT enabled "https-ONLY" mode in about:preferences and are seeing this problem with default settings then we need to investigate further. This should not be the experience you encounter with the default "https-first" mode. "https-ONLY" mode has proven too blunt and annoying for most users and we are not ever likely to turn it on by default.

Private address ranges are intranet greenside addresses but FF treats them as risky redside. Similar behaviour is to be found in the Microsoft Edge. Whats going on?

The RFC 1918 addresses are separate from the public Internet, but whether they are "safe" depends on the network and the security needs of the organization. Very common examples of potentially hostile "private" networks are the WiFi networks at shops, libraries, hotels, schools, etc. In your home you may rightly have zero concern about connections to the servers you have set up, but that is not universally the case. And even in a personal home network you might have hooked up a Smart TV or other "smart" device doing who knows what. We know they hoover up and report all kinds of data on you; network sniffing wouldn't be inconceivable.

Summary:

  • what you're describing is working as designed for "https-ONLY" mode
  • if you haven't enabled that then it could be a bug
  • this report doesn't need to be hidden to protect other users from being abused by this bug
Blocks: https-only-mode
Group: firefox-core-security
Component: Untriaged → DOM: Security
Product: Firefox → Core

Actually, no, what you're reporting is mysterious. In Firefox 77 (2020) bug 1631384 implemented exactly what you're requesting. If you enter "http://" for an RFC 1918 local IP address there should be no upgrade attempt by either http-only or https-first. My own local testing confirms this is still functioning as intended. The only way you should see what you're reporting is if

  • the http site itself issues a redirect to https (my home Orbi router appears to do this)
  • you have changed the value of the preference dom.security.https_only_mode.upgrade_local from the default false
See Also: → 1631384

Confirm; dom.security.https_only_mode.upgrade_local is set to FALSE
Confirm: FF Settings Privacy & Security / HTTPS-Only Mode / Don't enable HTTPS-Only Mode is set to TRUE

This has previously worked but not now. Marking this as a none security issue is controversial in that the user in desperation may install another less secure browser that allows the router logon to take place. The router web page is believed to be hardcoded as part of its firmware so there should be no redside pathway that should be of concern. I tried this on a none private tab and got the same result. So this is either an undesirable feature that renders the router logon page inaccesible or its bug. Which is it?

Forgot to mention FF 117.0 is in use.

This has previously worked but not now.

Could you find a regression range using mozregression?

Use only private tabs is switched OFF and on all machines are laptops.

FF 117 on a newly imaged Win 10 Pro machine allows the router logon. When the Certificate Manager/Servers is looked at it shows the 192.168.x.x as an exception along with its SHA-256 Fingerprint.

On the machines where it is NOT working the Server tab allows for an exception to be entered but will not allow it to be saved saying there is no need for it because the certificate is trusted. The certificate is Internet Widgits Pty Ltd, Issuer Bitdefender Personal CA.000000000000. Validity: Not Before Fri, 01 Jan 2010 00:00:00 GMT, Not After Sat, 27 Aug 2033 13:15:39 GMT.

The router was rebooted and on the machine that DID allow the logon the Server tab no longer shows the exception. Now a Warning: Potential Security Risk Ahead with message 192.168.x.x uses an invalid security certificate. The certificate is not trusted because it is self-signed. Error Code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT. When the certificate is examined, it differs by not having an issuer tab. The Issuer is missing. The validity dates are not before 2019 and not after 2020. The risk is accepted and an exception appears in the Certificate Manager/Servers tab.

The machine is rebooted: the exception is now missing from Certificate Manager/Servers tab. When the certificate is examind, nothing has changed. The risk is accepted and continue. The exception has reappeared under the Service tab and the routers logon is allowed.

On a Win11 machine that previously allowed the logon to work it no longer does because the bug as reported is now blocking the router logon.

Marking this as a none security issue is controversial in that the user in desperation may install another less secure browser that allows the router logon to take place.

I removed the access control from this bug because this does not appear to be weaponizable by an attacker. That doesn't mean it's not a security issue, it just makes it possible to draw folks to work on it rather than limiting it to a small security team.

If HTTP-only is "OFF" then the router itself must be redirecting from http: to https:. You could capture network logs in Firefox to see if that is the case (in DevTools Network tab; see https://support.mozilla.org or https://chat.mozilla.org if you need help figuring that out). There's nothing Firefox can do with that.

I'm confused by the multiple symptoms. It's working on some machines, but not others, or others it's working on at first but not later?

The machine that sees the "Bitdefender" certificate is running anti-virus that is running as a proxy to scan all traffic. You aren't seeing the real router's certificate, you're seeing one that the proxy generates on the fly. This works because when you installed the antivirus it installed it's own root certificate so you don't have to deal with exceptions.

The router itself appears to be issuing self-signed certs, which by definition don't have issuers. That seems normal. I have NOT seen routers that issue a NEW certificate every time they're rebooted, but I suppose that's a PITA choice some manufacturers may have made.

For the "machine is rebooted.... exception is missing" one... does the same thing happen if you merely close Firefox and restart it without rebooting the machine? That sounds like there might be file corruption in the Firefox profile preventing it from saving the in-memory exception, so it only works as long as Firefox is running. The only clean fix for that would be a "Firefox Refresh" to rebuild those files. Unfortunately it's a bit of a multi-purpose problem solving tool so you will have to re-install your add-ons after (addons are a common source of hard-to-diagnose problems) and redo some preference changes, especially if you have changed any hidden prefs via about:config. It will keep all your cookies, history, localstorge, bookmarks and passwords.
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings

In summary, the original problem is

  1. the router itself, or maybe other security software on your network, is redirecting from http: to https:
  2. routers always use self-signed cert, which results in a connection warning
  3. you will have to add certificate exceptions (effectively acknowledging the warning)
  4. it should work fine after that

Steps 2-4 are necessary because of step 1, but that is not being done by Firefox. Except for that one machine that won't save the exception, this should be a minor inconvenience. It's annoying that your router appears to generate new certificates on reboot, but that is also not Firefox's (or Microsoft Edge's) fault.

Couple of questions:

  1. Is anybody able to reproduce this problem with their router?
  2. In response to the bug: browser "Brave" is now installed on every FF machine something that allows router logon each and every time once the risk is accepted. Whatever is common to FF and Edge is not apparent in this browser however it can be reproduced in the Opera browser.
    Have today opened a case with D-Link and referred the bug to them for further advice.

D-Link support have come back to say "Looking at the FF bug report link you gave, it appears the Bitdefender certificate is not from the router, it's from installed AV software". To this end each machine with the problem was rebooted into Safe Mode with Networking. The outcome was that FF on each machine allowed logon to the router once the risk was accepted. Wednesday last, the AV provider was made aware of this Bugzilla report and is in the process of responding.

The AV provider has responded by saying "This is a known issue that our developers are working on. In the meantime, whenever you need to access your router, you will need to temporarily disable the [AV identity removed] firewall, then turn it back on when you are done."

If "AV identity removed" isn't Bitdefender it's extremely suspicious that it's issuing Bitdefender certificates.

You probably don't need to run in "safe mode", you just need to disable the traffic interception feature of the A-V. You may be able to find this setting on the A-V software itself, or you can open the addon manager to disable the anti-virus addon without disabling all your other addons as Safe Mode does.

This is not a Firefox bug after all. If you need more information the folks at https://support.mozilla.org can help

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME

Hey Daniel,
This award-winning AV provider added in their last update a new feature: HTTPS protection against bad actors. In the Windows Certificate Store/Trusted Root Certification Certificates it installs a valid and trusted CA as Bitdefender Personal CA.000000000000. If the AV software is uninstalled this CA is also removed.

When FF determines that a certificate cannot be trusted it offers to the user a means of overriding this protection by accepting the risk which means that the traffic between FF and the router is unencrypted which becomes a real problem over a Wifi network, so much so that Windows 11 does not allow Safe Mode with Wifi Networking a LAN connection must be used.

Pure guesswork here but the AV is spoofing the routers HTTPS certificate which is out of date. It is doing this to allow encrypted traffic between browser and router. The certificate being caught by the bug is a trusted Widgits Pty Ltd, Issuer Bitdefender Personal CA.000000000000. However, Widgits Pty Ltd is an alias created by FF for an untrusted issuer.

The terseness of the bug report "we could not verify the certificate: reason = untrusted" and its lack of a page dedicated to what the problem is suggests that an error handler has hit its ELSE construct allowing a controlled exit.

AV support at first asked that the firewall be turned off. The bug did not go away. Other protections turned off did not make the bug go away. Only when support asked that the AV software be shutdown did the bug go away.

FF and other browsers which have the same 'bug' may be working in an undesirable way so FF may be part of the problem in that the AV providers prospective desire to encrypt browser traffic over Wifi is well worth pursuing and may require changes to FF and other browsers in due course. Let’s leave this open for the moment to see what AV developers do to eliminate the problem.

You need to log in before you can comment on or make changes to this bug.