localhost:2812 on Firefox >= 84: The connection to the server was reset while the page was loading.

[Jérôme Borme]

I installed monit on a gentoo linux with all default parameters. It does the job, but the monitoring page (localhost:2812) cannot be opened with Firefox versions starting 84 (released 2020-12-15, 1 year before this report). The error is “The connection to the server was reset while the page was loading.” It works with older version of Firefox, and with other browsers on the same machine: chromium-96, opera-82, KDE_falkon-3.1.0, dillo-3.1_pre, links-2.25, palemoon-29.4.3.

It also does not open with netsurf-3.10 ("Failure when receiving data from the peer") and lynx-2.9.0_pre9 (lynx did ask for username and password but returned "HTTP/1.0 400 Bad Request") but that could be limitations of their implementation, and I am more concerned with using Firefox.

The releases notes of Firefox 84 say something about localhost addresses (https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/84#security) so it could be they made a change or have a preference in about:config that needs to be used. But other services that also have a localhost page such as cups (http://localhost:631) and syncthing (http://localhost:8384) work without problem.

Tested with monit 5.27.2 and 5.29.0

[Tildeslash]

i’m unable to reproduce the problem (using Firefox 95.0.2)

please can you take a network trace (using for example wireshark) and send the “set httpd” statement from your monit configuration file?

[Jérôme Borme]

This is the trace for a request to http://localhost:2812 on my firefox 95.0.1 with monit 5.29.0, captured by wireshark 3.6.0

‌

[Jérôme Borme]

Trace with browser palemoon 29.4.3, where it works. First 18 lines of the trace are up to asking the password, then it takes me 4 seconds to type "admin/monit", then 98 lines fetching the data.

[Jérôme Borme]

/etc/monitrc

set httpd port 2812 and
    use address localhost  # only accept connection from localhost (drop if you use M/Monit)
    allow localhost        # allow localhost to connect to the server and
    allow admin:monit      # require user 'admin' with password 'monit'
    with ssl {            # enable SSL/TLS and set path to server certificate
    #    pemfile: /etc/ssl/certs/monit.pem
    }

‌

[Tildeslash]

Thanks for data. It seems monit send RST during SSL/TLS handshake … are there any errors on the Monit side? (you can run monit in debug mode by stopping it and starting in foreground: “monit -vI”).

We have seen similar symptoms in the past due to some SSL library incompatibility (it could be even due to SSL protocol or cyphers configuration). Monit 5.29.0 by default allows only TLSv1.2 or later, lots of unsecure ciphers are disable by default as well.

Which SSL library version is linked with your Monit? Which SSL library version is linked with your Firefox?

[Jérôme Borme]

I just noticed, the traces above used monit compiled without ssl support (I wanted to force it not to use ssl as a test, then I forgot to revert to the other binary).

(As a side note, I would expect monit to say something about including the ssl directive into the config file, for the version without ssl compiled in). I can take the trace with ssl enabled if helpful.

As far as I understand, Firefox does not link to an ssl library, it uses its own internal security library, nss-3.73.1. I used both a local firefox build and official Mozilla binaries. I was able to bissect the FF nightly builds to a change 2020-10-26 to -27 (previous versions work, more recent versions fail). The corresponding mercurial pushlog (provided by the bissection tool mozregression) contains 309 changesets: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b1a74943bc51bd3e62ea52242ec5e403ea3760bb&tochange=ab66bd46c2d6874336d5fad4faceaa9b9448ff5f

I can continue the bissection inside the changeset (but now local build everytime) if it is helpful.

monit -vI replied:

Firefox 95 : Denied connection from non-authorized client [127.0.0.1]
Other browsers: HttpRequest: access denied -- client [::1]: missing or invalid Authorization header (then I enter the password, then no more messages and it works)

Now with ssl enabled, I noticed I can make it work if I edit /etc/hosts the following way:

/etc/hosts
::1 localhost
→ does not work (this is how it was configured originally)

127.0.0.1 localhost
→ monit/firefox works

(monit -V reports ipv6 support)

[Tildeslash]

You ‘set httpd’ statement contains ‘allow localhost’ … if your /etc/hosts contained only IPv6 ‘::1 localhost’ and Firefox established connection using IPv4 127.0.0.1, then this address was not allowed. Please can you check if your /etc/hosts contained both IPv4 and IPv6 for localhost?

[Jérôme Borme]

Indeed it contained only one of them, and when I put both it solves the problem.

I identified the specific Firefox revision that caused the issue to me :

• https://hg.mozilla.org/mozilla-central/rev/376f506827661cf4be852cb948e28095f5586c27
• https://bugzilla.mozilla.org/show_bug.cgi?id=1673364

The code changes the logic on how the network socket is created.

Monit never had an issue, thanks for the support.

[Jérôme Borme]

Not a bug of monit, system configuration issue