Is it possible to suppress http: TLS handshake errors?
alexellis opened this issue · comments
What is your question?
Is it possible to suppress http: TLS handshake errors?
They're starting to spam and drown out real logs from bots and network scanners which are unaware of the domain and are trying to access port 80 and 443.
What have you already tried?
I've looked at the gopkg docs and past issues, I was unable to find out how to do this just yet.
Include any other information or discussion.
May 18 21:55:24 sudo[3730]: 2023/05/18 21:55:24 http: TLS handshake error from remote:port: no certificate available for 'public-ip-goes-here'
Bonus: What do you use this package for, and does it help you?
I've been using the package in a couple of places instead of a reverse proxy, because it's one less thing to configure when something needs to be on the Internet.
These logs are not required and spam application logs.
That error is emitted by the Go standard library.
In general, log consumers should simply ignore (or discard) logs that they aren't interested in, so "drowning out" problems are usually the result of a misconfiguration of a logging pipeline, or maybe even incompetent logging software that isn't capable of that.
That error is the result of CertMagic returning an error to tls.Config.GetCertificate(). If you're serving HTTP, it may be possible to customize the HTTP server's logger using http.Server. But since this log isn't emitted by CertMagic, we don't have control over it, sorry.
Interested in this as well; we're running into the same kind of logging issues. -- From what I could find, specifying the ErrorLog on the http.Server (if used) might help, but I haven't tried it yet in a production environment.
^ Yep, I think that should do it.
Note you will lose other (potentially helpful) log messages, this is a downside of turning off logging in this way. Recommended way to handle unwanted log messages is for your log ingestor to discard them.
In Caddy what we do is make an debug level logger named stdlib that we pass to http.Server's ErrorLog field: https://github.com/caddyserver/caddy/blob/38cb587e0f1b38db2c9fb422b4892e48753f00c0/modules/caddyhttp/app.go#L354 That way the logs are hidden by default, and only shown if users turn on debug level logging.
Thank you for the responses 🙏 - I'll take a look and report back what worked. This program doesn't use Zap yet, so will perhaps need to find a workaround for that.
You don't have to be using zap, just have a type that can fulfill the logger interface as per that server option.
@welteki could you provide an update when we have one please?
Thanks again folks 🦸
Implemented this basic logger that we pass to the http.Server's ErrorLog field to suppress the logs. Logs can still be enabled for debugging purposes.
type serverLogWriter struct {
Debug bool
}
func (w *serverLogWriter) Write(p []byte) (int, error) {
if w.Debug {
return os.Stderr.Write(p)
} else {
return len(p), nil
}
}
func newServerLogger() *log.Logger {
debug := false
if v, exists := os.LookupEnv("debug"); exists {
val, err := strconv.ParseBool(v)
if err != nil {
debug = false
}
debug = val
}
return log.New(&serverLogWriter{Debug: debug}, "", log.LstdFlags)
}We are also using certmagic.HTTPS in some places. What would be your recommendation to suppress the logs in this case since we can not access the http.Server to set the ErrorLog field.
certmagic.HTTPS() is a near-drop-in-replacement for http.ListenAndServe(), so you'll need to go down a layer of abstraction to customize the HTTPS server, i.e. create your own http.Server, pass in the listener; CertMagic has functions to give you listener and HTTP handler wrappers.