[Enhancement]: Allow disabling certificate validation in SMTP email settings (self-signed certificates)

[jecpr]

What happened?

I am still having this issue (https://github.com/advplyr/audiobookshelf/issues/2765) after the fix. Current version 10.0.1. Running proton mail bridge and have verified i can connect and authenticate. Proton serves smtp on port 1025. I have tried with both secure selected and not. Log output when secure not selected:

[2024-05-29 20:27:05.018] INFO: [EmailManager] Sending test email
[2024-05-29 20:27:05.024] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34)
    at TLSSocket.emit (node:events:519:28)
    at TLSSocket._finishInit (node:_tls_wrap:1085:8)
    at ssl.onhandshakedone (node:_tls_wrap:871:12) {
  code: 'ESOCKET',
  command: 'CONN'
} (EmailManager.js:17)

and with secure:

[2024-05-29 20:27:51.521] INFO: [EmailManager] Sending test email
[2024-05-29 20:27:51.527] ERROR: [EmailManager] Failed to verify SMTP connection config Error: self-signed certificate
    at TLSSocket.onConnectSecure (node:_tls_wrap:1674:34)
    at TLSSocket.emit (node:events:519:28)
    at TLSSocket._finishInit (node:_tls_wrap:1085:8)
    at ssl.onhandshakedone (node:_tls_wrap:871:12) {
  code: 'ESOCKET',
  command: 'CONN'
} (EmailManager.js:17)

What did you expect to happen?

Ideally it wouldn't be validating tls certificates, so that it supports self signed certs on email bridges run by users.

A potential fix might be: include the following in the getTransportObject within /server/objects/settings/EmailSettings.js:

payload.tls = {
    rejectUnauthorized: false
  }

Steps to reproduce the issue

1. set up protonmail bridge or other bridge which relies on self signed cert
2. attempt to send mail

Audiobookshelf version

v2.10.1

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

No response

Additional Notes

No response

[advplyr]

Are there security implications to using that flag? I haven't dug into it

[jecpr]

Yeah, I think basically it would allow a man-in-the-middle style attack on the mail traffic. If you were pointing to a FQDN then technically someone could impersonate that server with a self-signed cert. Not sure this amounts to much of a risk in practice though? Could this be an option provided for users who wish to take that risk (i.e. in development environments or internal only environments)?

[advplyr]

Yeah possibly. Can you share where you think the option would be and what alert message we should show the user?

[jecpr]

Hmm, one option would be to just put the warning on secure being off to give a warning and make it the default for secure being off. Otherwise, probs another button next to it which says 'certificate verification' or 'ssl verification' and gives a warning when off.

The warning might say something like: "Disabling SSL certificate validation may expose your connection to security risks, such as man-in-the-middle attacks. Only disable this option if you understand the implications and trust the mail server you are connecting to."

[nichwall]

I think those are good messages and having it be another toggle is good, but it should default to secure being on. If a user wants to use it insecurely that is a manual choice.

[advplyr]

I added this. If you want to test this you can switch to using the edge docker image

Defaults to enabled

[jecpr]

Tested this and it works exactly as described. Many thanks!!!

Some additional context for developer / alternative solution: Protonmail bridge uses self-signed certificates as a privacy feature. It is intended to only be hosted locally, hence is less of a security risk for MITM style attacks, but means there aren't any registered and searchable certificates (hence privacy). If you have it running as a service on your homelab though, it becomes slighly more complicated because it is sending self-signed certificates for hostname "localhost". So it fails most frameworks certficate checking in both ways: can't be verified and wrong subject name. For other applications, I've created a custom self-signed cert with the correct subject name, and then imported this cert into the ca store for the container / system. This works for most systems, but doesn't with this - I THINK because node doesn't trust the containers CA store, and just does it's own checking. So even when I import a CA cert with the correct subject to the container, the app still fails, warning it is a self-signed certificate. Alternative solution: a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature.

[advplyr]

Great, thanks for testing!

a less user friendly alternative would be to configure node to trust the containers CA, and have some documentation to the effect of the above. Way less user friendly for anyone using protonmail or similar set-up, but it is an option in case of future issues with this feature.

I'm not sure this is the issue but have no idea how nodemailer is handling this. If you can find a solution with https://www.nodemailer.com/ or maybe someone commented about it, that would be helpful.

[advplyr]

Added in v2.11.0