SSL: read error -- Success

[Matt P]

Each browser refresh (every 30 seconds by default) when accessing the monit service manager via https produces an entry in /var/log/monit.log that looks like:

[MDT Mar 12 11:40:18] error : SSL: read error -- Success

This happens for both versions 5.12.1 and 5.12.2_20150310 but it is fine for 5.11 which I have presently reverted to.

This was compiled on Slackware Linux 14.1 64-bit via:

./configure --prefix=/usr --datarootdir=/usr --sysconfdir=/etc/monit --enable-optimized --without-pam --build=x86_64-slackware-linux --host=x86_64-slackware-linux

The SSL PEM file is created via:

( umask 077 ; openssl req -x509 -sha256 -newkey rsa:4096 -days 3653 -keyout monit.pem -out monit.pem -nodes -subj /CN=www.example.com )

[Tildeslash]

That error shows up, because the browser started with weak ciphers or unsupported SSL method (e.g. SSLv3) - the SSL_accept() succeeds, but when Monit tries to read the HTTP request (using SSL_read), it gets EOF and it is logged by 5.12.1 with the mentioned (confusing) message. The log message is fixed in the development version 5.12.2_20150312. The browser then restarts the SSL handshake and succeeds, but the first request is logged too.

Requests from browsers like Chrome and Safari will log the mentioned message, (latest) Firefox works with no error logged, as it disabled SSLv3 support already.

[Tildeslash]

Yet note regarding the browsers:

1.) Safari tries with weak ciphers, gets "Change cipher specs" from Monit and resets the connection and tries again with correct ciphers - it is able to learn though, so "only" two errors (see bellow) are logged on first connection, subsequent refreshes don't log any error:

SSL: read error -- error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure
SSL: write error -- error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure
HttpRequest error: HTTP/1.0 400 No request found

2.) Google Chrome logs error with each refresh, as it forgets the cipher spec and re-negotiates ciphers each time:

SSL: read error -- EOF
HttpRequest error: HTTP/1.0 400 No request found

3.) Firefox (36, but most probably older versions too) don't have any problem as it uses strong ciphers automatically.

[Matt P]

Confirmed - monit-5.12.2_20150312 now reports the error as "SSL: read error -- EOF" when using Chrome.

Perhaps a general logging feature of including a message like "Last message repeated X times." so that these less secure browsers don't fill up the logs.

I realize this is not a bug with Monit, as it is logging information appropriately.

In the meantime, I will stick with Monit 5.11. Thank you!

[Matt P]

Some additional thoughts:

SSL support is really going beyond the scope of monit's purpose, imho. These messy SSL issues are easily handled by specialized software, such as nginx, which is especially timely given that monit now can listen on sockets in version 5.12. I solved the above problem in this way:

In monitrc:

set httpd
    unixsocket /var/run/monit.sock
    allow user:"password"

In nginx.conf:

server {
        listen       443 ssl;
        ...
        location /monit/ {
            proxy_pass http://unix:/var/run/monit.sock:/;
        }
}

Since I run nginx under user=www and group=www, I had to modify the permissions of monit.sock accordingly:

chown :www /var/run/monit.sock
chmod g+w /var/run/monit.sock

It would be great if the user/group ownership and permissions of /var/run/monit.sock could be specified in monitrc, so that we don't have to run the process that interacts with the socket as root.

[Tildeslash]

If better access control is needed it is also possible to bind the monit HTTP interface to loopback with the same effect as unix socket:

 set httpd
    port 2812
    use address 127.0.0.1
    allow myuser:mypassword

[Tildeslash]

closing the issue - not bug (caused by SSL renegotiation as described)

[Tildeslash]

Removing version: 5.12 (automated comment)