Open chris001 opened 6 years ago
For DANE and DNSSEC, we actually rely on SpamAssassin to enforce these on incoming email.
By enforcing TLS, do you mean rejecting email that isn't TLS encrypted?
By enforcing TLSA
, I mean, the TLSA
record in DNS, this is part of the relatively new DANE
security standard - "DNS Authentication of Named Entities" - remember when we talked about this, and you added the TLSA record generator feature to Virtualmin, it sticks a record in DNS containing the domain name of the server, a port number, and a figerprint hash of the authorized cert to expect to be coming out on that port of that server.
To have Dovecot fully enforce DANE TLSA, it looks like Dovecot requires that a number of conditions be met.
So the big question is, Is virtualmin attempting to satisfy the conditions required by Dovecot. If yes, is it actually satisfying them to the level Dovecot requires to make DANE TLSA enforcement work.
The relevant section of http://www.postfix.org/TLS_README.html is this:
Configuring TLS in the SMTP/LMTP client
Similar to the Postfix SMTP server, the Postfix SMTP/LMTP client implements multiple TLS security levels. These levels are described in more detail in the sections that follow.
none
No TLS.may
Opportunistic TLS.encrypt
Mandatory TLS encryption.dane
Opportunistic DANE TLS.dane-only
Mandatory DANE TLS.fingerprint
Certificate fingerprint verification.verify
Mandatory server certificate verification.secure
Secure-channel TLS.
The Postfix config (/etc/postfix/main.cf
) doesn't contain any setting for the security variable smtp_tls_security_level
( http://www.postfix.org/postconf.5.html#smtp_tls_security_level ) so it falls back to the default setting, which is empty. This is potentially a huge security hole, if all email relayed outward by the Virtualmin Postfix server, is going out in the clear, when it should be encrypted when possible.
This is also a 2016 Email TLS requirement by Google, to avoid having Virtualmin-transmitted emails being tagged inside GMail with the dreaded "red padlock" as being possibly tampered with and untrustworthy. https://community.letsencrypt.org/t/how-to-meet-gmails-new-2016-email-tls-requirement-red-lock/28097
dane
) which falls back to opportunistic TLS (may
) when DANE TLSA records are not available for the destination mail server.may
because the SMTP RFC requires support for incoming clear text email.
smtpd_tls_security_level = may
smtp_tls_security_level = dane
We already discussed it with Joe, I remember.
All Postfix needs is
smtpd_tls_security_level = may
smtp_tls_security_level = may
It will use TLS all the time when it's possible or fall back to insecure connection, in case other server doesn't support it.
Having mentioned lines in the config doesn't hurt and will let to have TLS lock in GMail.
@iliarostovtsev
I think smtp_tls_security_level = dane
is the right setting, rather than may
, because dane
defers forwarding your private email to servers on domains with invalid TLSA records, this is correct, because the server could be an imposter/fraud/scammer/hijacked.
What about DNSSec?
DANE depends on DNSSEC to provide security of the DANE TLSA records. https://security.stackexchange.com/questions/151961/why-is-the-dane-protocol-depending-on-dnssec Without DANE, a criminal could pay a CA to issue a cert for (for example) an online banking domain that they didn't own, for the purpose of hijacking your session via a DNS cache poisoning attack.
That is cool. Well, it wouldn't be trivial to do.
With DANE enabled, what do you get in Gmail? Gray lock with regular TLS, not green, right?
Yes, with DANE enabled, Gmail shows a regular Gray lock with regular TLS: "Standard encryption (TLS) Learn more", because Virtualmin Postfix transmitted the clear text email to Gmail thru TLS. Green padlock is only for S/MIME end-to-end public/private key encryption, which requires you to install a public/private key pair at Gmail, and share/publish your S/MIME public key for others to install in their email app, so that it can encrypt mail with your public key when sending to your Gmail address.
@chris001 Is there a manual or more info about how it can be done for Postfix?
It sounds like we should enable this for Postfix as part of the Virtualmin install, or perhaps when SSL is enabled for Postfix.
What needs to be turned on for Dovecot though?
@qooob Here's some more information and working implementations of S/MIME and PGP end-to-end email encryption for Postfix.
Note: Exchange, Apple iOS, and Gmail have had full support for S/MIME for a long time!
It's about time that Virtualmin add S/MIME for Postfix.
@jcameron
I made a request to the Dovecot folks to improve Dovecot by specifying to accept a folder tree of certs, such as the /etc/letsencrypt/live
folder, and then Dovecot would automatically use the correct cert, determined by checking which cert has the hostname embedded inside it. Maybe they'll implement this very sensible suggestion one day soon!
Until then, the issue with the Dovecot solution is #21 near the bottom of the thread.
For Dovecot, since there is already a way to specify per-domain certs, Virtualmin already sets this up by default for all domains with SSL enabled.
Regarding s/mime - is this really something that's commonly configured at the mail server level? I though it was usually done in mail clients. Whereas TLS is definitely done by the mail server, so we will make sure that smtpd_tls_security_level
is set.
For webmail, SOGo (web mail front end for postfix/dovecot), Exchange Outlook Office365, Gmail, Apple icloud.com, Zarafa, roundcube, S/MIME can be terminated at the mail server level for convenience, so that the user doesn't have to carry around their key pair. Instead, the mail server app manages the user's key pair, Outgoing messages get encrypted by the public key of the destination email address. Which the webmail app retrieves from from your address book on the server. You CAN manage the key pair inside your thick mail client app running on your PC/device, but then it's cumbersome when you want to log in from another device, nobody wants to load their key pair onto another device, and you might not have access to your address book with all your contacts' public keys for sending them mail. You can carry around your private key, but it's not the best or most secure way of managing your key.
Interesting ... I'll look into that. Seems like it violates one of the big benefits of s/mime though, which is that the mail server owner cannot read end-users email.
Right. It all comes down to, where do you want to terminate the encryption.
I am surprised that a post for such a massive security issue is still open and there is no update on it for last 2 years.
Having said that I just checked my own postfix/main.cf and I have: smtp_tls_security_level = dane
However, this is now giving me multiple warnings (like 30-40 errors in 24 hours) via logwatch saying:
Anyone, any idea, what's going on here and how I can get rid of this warning.
Just so you know, I have not enabled DNSSec on this server (I am still working on it on test server).
Thx: RK
@jcameron @iliarostovtsev @raviktiwari007 @swelljoe
It's a multi-step process to enable DANE
in postfix
. This is why it isn't working yet. Not all the steps have been completed! Namely, step 2 hasn't been fully completed, as it allows invalid TLSA
records to linger in DNS
, and doesn't update them with the new, current, valid TLSA
records! To complete the job, Virtualmin needs to periodically run a cron
job, to check and update any invalid TLSA
record that has become stale/invalid because the underlying TLS
cert that the TLSA
record validates, has either expired and been renewed with a new one, or simply has been replaced with a different TLS
cert!
DNSSEC
confirmed up and running, for all domains as long as you're at it, in Virtualmin's BIND9 DNS
.TLSA
records for postfix
ports (and every other web service port ie Apache, Nginx, Dovecot, ProFTPd, BIND9, SSHd, etc), and insert (or update) them into your BIND9 DNS
zones. FYI in case you missed it, TLSA
records are DNS
records containing the port number, and a hash of the TLS
cert/key that you should encounter when you connect to the Virtualmin server on that postfix
port, which secures postfix
as it prevents man-in-the-middle attacks, because man-in-the-middle attackers must use their own, different, TLS
cert/key.DANE
setting in postfix
config main.cf
:
# DANE-Settings
smtp_dns_support_level=dnssec
smtp_host_lookup=dns
smtp_tls_security_level = dane
smtp_tls_loglevel=1
More details on a postfix
DANE
config that supposedly works:
https://tech.feedyourhead.at/content/postfix-verified-tls-with-dane
Okay, we set smtp_tls_security_level
upon copying Postfix SSL service already. I also added it to be set upon install time. https://github.com/virtualmin/Virtualmin-Config/commit/7bd2e74d74247b4c450b9d82daae84d01e6fb4d3
@jcameron @swelljoe I am sure it's time to step up and make it available with Virtualmin. I made it easily work and at the same time not fail, for older systems.
It's testable here -
Results:
Additional patches to review -
https://github.com/virtualmin/virtualmin-gpl/commit/34ef06a904ff21287216182f58aac884c1c4e734 https://github.com/virtualmin/Virtualmin-Config/commit/6e8fe990320b59d34d02ff647b404ee212274a82
Is Virtualmin really configuring Postfix so that it can fully enforce DANE and TLSA?? Reading the official Postfix README on the topic, it's very doubtful that Virtualmin really satisfies all the required settings rigorously. http://www.postfix.org/TLS_README.html It'd be great to take a close look at what Virtualmin does regarding TLSA, DANE, DNSSEC, Postfix, and TLS certs, and answer the question, is a Virtualmin server provide all of the modern security functionality available with Postfix.