search

virtualmin / virtualmin-gpl

Virtualmin web hosting control panel for Webmin
https://www.virtualmin.com
GNU General Public License v3.0
308 stars 95 forks source link

Verify Postfix config really enables DANE TLSA DNSSEC. #23

Open chris001 opened 6 years ago

chris001 commented 6 years ago

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.

jcameron commented 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?

chris001 commented 6 years ago

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.

chris001 commented 6 years ago

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.

chris001 commented 6 years ago

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

iliajie commented 6 years ago

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.

chris001 commented 6 years ago

@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.

iliajie commented 6 years ago

What about DNSSec?

chris001 commented 6 years ago

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.

iliajie commented 6 years ago

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?

chris001 commented 6 years ago

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.

iliajie commented 6 years ago

@chris001 Is there a manual or more info about how it can be done for Postfix?

jcameron commented 6 years ago

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?

chris001 commented 6 years ago

@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.

  1. https://github.com/mail-in-a-box/mailinabox
  2. https://serverfault.com/questions/538565/sign-outgoing-mails-automatically-with-postfix-s-mime
  3. https://github.com/fkrone/gpg-mailgate
  4. https://support.apple.com/en-us/HT202345
chris001 commented 6 years ago

@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.

jcameron commented 6 years ago

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.

chris001 commented 6 years ago

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.

jcameron commented 6 years ago

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.

chris001 commented 6 years ago

Right. It all comes down to, where do you want to terminate the encryption.

raviktiwari007 commented 4 years ago

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:

1   Aug 22 16:18:45 mail postfix/smtp[26260]: message repeated 2 times: [ warning: yahoo.com: dane configured with dnssec lookups disabled]

1   Aug 22 16:18:45 mail postfix/smtp[26260]: message repeated 2 times: [ warning: google.com: dane configured with dnssec lookups disabled]

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

chris001 commented 4 years ago

@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!

  1. Get DNSSEC confirmed up and running, for all domains as long as you're at it, in Virtualmin's BIND9 DNS.
  2. Generate proper 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.
  3. Enable 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

iliajie commented 3 years ago

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 -

https://havedane.net

Results:

image

Additional patches to review -

https://github.com/virtualmin/virtualmin-gpl/commit/34ef06a904ff21287216182f58aac884c1c4e734 https://github.com/virtualmin/Virtualmin-Config/commit/6e8fe990320b59d34d02ff647b404ee212274a82