[actions] email action broken in 7.11.0 for mail servers that don't support TLS

[pmuellr]

Kibana version: 7.11.0 - worked on releases up to this though

Describe the bug:

Email servers that don't support TLS cannot be used with Kibana 7.11.0, but worked in previous versions. The best example is using the maildev npm package. If you run via npx maildev (no need to install anything), it will launch a mail server and a web client to read the emails that get sent.

$ npx maildev
npx: installed 118 in 6.567s
MailDev webapp running at http://0.0.0.0:1080
MailDev SMTP Server running at 0.0.0.0:1025

When sending an email through this server in 7.11.0, you'll see the following error:

error sending email: self signed certificate

We are seeing a similar issue with a cloud email proxy, not clear if it's the same, but sounds like it is, as it also does not support TLS AFAIK.

Steps to reproduce:

I have a pre-configured action for maildev in my kibana.dev.yml file, but you can also create the same one manually:

xpack.actions.preconfigured:
  maildev-no-auth:
    name: 'email: maildev no auth'
    actionTypeId: '.email'
    config:
      from: 'from@example.com'
      host: 'localhost'
      port: '1025'

From the Kibana UI, find this connector, and then go to the test tab. Fill in the To / Subject / Message fields, and click the Run button. You should see the error message in the Results section.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

So it turns out, if you set the global Kibana config xpack.actions.rejectUnauthorized to false, it works.

I added some debug logging in the email action for it's "transport" settings, and this is what it prints, when not setting that to false (not configuring it at all):

email action maildev-no-auth sending mail with transport: {
  "host":"localhost","port":1025,"secure":false,"tls":{"rejectUnauthorized":true}
}

Here's what it looks like when I set the config value to false:

email action maildev-no-auth sending mail with transport: {
  "host":"localhost","port":1025,"secure":false,"tls":{"rejectUnauthorized":false}
}

In 7.10.0, if xpack.actions.rejectUnauthorized is not set (and so defaults to true), this is used for the transport config:

{"host":"localhost","port":1025,"secure":false,"tls":{"rejectUnauthorized": undefined}}

The rejectUnauthorized parameter passed to this function (as part of the options) is always undefined, it's never set in the caller. That seems like a bug itself, and I'd guess that the undefined is being treated as false by nodemailer, so we were never rejecting invalid certs before.

I'm tempted to use the secure action setting to also influence the tls.rejectUnauthorized value nodemailer setting, but that's a bit dangerous. It would mean that for servers that REQUIRE the secure false setting (eg, office365), they would be running without the tls auth check, which would be not good.

It may be though that we could be a little more precise in applying that. The two known servers this is a problem with both do not accept user/pass values - so they are already somewhat insecure. Could we use something like this to set the value?

if (user == null && password == null && secure === false) {
    tls.rejectUnauthorized = false
}

If that's not acceptable, we could add a new rejectUnauthorized: boolean property explicitly to the email config, but I really hate to do that as it's already a complicated set of config values to deal with, unless you are intimately familiar with SMTP.

Long-term, the resolution of this issue should be the real fix: #80120

[pmuellr]

PR #91760 seems to fix this, but we'll need to think about the ramifications.

Not sure how to go about testing this on cloud. I'm thinking I used to create deployments with nightly images, so we'd need to promote this to master and wait till then to test it.

[trengrj]

Thanks @pmuellr, looking at nodemailer TLS options https://nodemailer.com/smtp/#tls-options, the connection is always upgraded to TLS via STARTTLS if the SMTP server supports it (even when secure is set to false). The ignoreTLS option would need to be used to fully disable STARTTLS.

Watcher decided to use two separate config options https://www.elastic.co/guide/en/elasticsearch/reference/current/notification-settings.html#email-notification-settings starttls.enabled and starttls.required.

[pmuellr]

Thx for that info @trengrj ! We should include that option in issue #80120 (I'll add to the design doc I'm working on).

At least for the cloud proxy and nodemailer, also implementing a way to ignore cert verification checks would work here, as that's how it worked in the past. The current logic in 7.11.0 doesn't give us a way to do that though. And perhaps that's better, than not using TLS at all - at least you'd get on-the-wire encryption for that.