Postfix and TLS 1.2

In my main.cf for Postfix I have set the following TLS options:

Code:
smtpd_tls_cert_file = /usr/local/openssl/certs/mail_domain_com.crt
smtpd_tls_key_file = /usr/local/openssl/certs/mail_domain_com.key
smtpd_tls_CAfile = /usr/local/openssl/certs/mail_domain_com.ca-bundle
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1
smtpd_tls_ask_ccert = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_received_header = yes
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtp_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
smtp_tls_ciphers = $smtpd_tls_ciphers

When I sent an email from my email server to my Gmail email address the header looks as follows when viewed from within the Gmail web site:

Code:
version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128

So TLS 1.2 is being used which is good.

Now when I send an email from Gmail to my email server the header looks as follows in my email client:

Code:
using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

So why is it when I receive email its not using TLS 1.2 from Google?

I know TLS 1.2 works because when I received an email from my bank today it says the following in the header:

Code:
using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So I know my server supports it and I am running the latest OpenSSL version as of today.
 
My guess would be that Google use different servers for outgoing email than they do for incoming. Their outgoing ones are maybe just 1.0 only?

I've just sent an email from Gmail to my own server which I know definitely supports v1.2 and get this:

Code:
Apr  9 16:35:48 tao postfix/smtpd[6304]: Anonymous TLS connection established from mail-wi0-x22f.google.com[2a00:1450:400c:c05::22f]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Whereas sending an email in the other direction I get this:

Code:
Apr  9 16:40:04 tao postfix/smtp[6361]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

So perfectly normal I would say.

By the way. You really don't want to use high cipher settings for everything. Use them for mandatory by all means, but the opportunistic settings you should leave as the default which I think is export. Otherwise what will happen is if you connect to a server which doesn't support the high ciphers it will just fall back to plain text unencrypted email rather than use a low encryption. Which is better? Low encryption or clear text?
 
@xtaz: You make some excellent points...thank you.

I didn't think about Google using different ciphers/protocols depending on which way the mail is flowing.

Regarding the cipher setting in Postfix, I am tempted to change it to:

Code:
smtpd_tls_ciphers = medium

Isn't export REALLY insecure? Then again, its STILL better than no encryption at all!

Edit:

I've just noticed that when I send an email from my server to Gmail it says in the maillog:

Code:
Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.67.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Why is my connection showing as Untrusted but yours is showing as Trusted?

It also happens when I send an email from Gmail to my server:

Code:
Untrusted TLS connection established from mail-yk0-f181.google.com[209.85.160.181]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
 
Last edited by a moderator:
xtaz said:
Might be because I have configured postfix with the list of trusted root CAs.

Code:
smtp_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt

That file is installed from security/ca_root_nss.

Thanks, that worked! I set the following in main.cf:

Code:
smtpd_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt
smtp_tls_CAfile = /usr/local/share/certs/ca-root-nss.crt

Any connections to Google for email are shown as a " Trusted TLS connection". Interestingly, when my machine uses the submission port (587) to send an email, my connection from my machine is shown as "Anonymous TLS connection".
 
Is it possible to show what your email clients are in the log for Dovecot/Postfix? ie: K9 Email, Outlook 2010, Thunderbird, etc.
 
xy16644 said:
Any connections to Google for email are shown as a " Trusted TLS connection". Interestingly, when my machine uses the submission port (587) to send an email, my connection from my machine is shown as "Anonymous TLS connection".

http://www.postfix.org/FORWARD_SECRECY_README.html#status explains all. It's related to if it uses a client certificate to authenticate or not and it also depends on the direction. If it's your server connecting outgoing, or if it's a client connecting incoming.

I have no idea about your other question though. The user-agent will be available in the mail headers but I have no idea how to add it to the logs.
 
xtaz said:
xy16644 said:
Any connections to Google for email are shown as a " Trusted TLS connection". Interestingly, when my machine uses the submission port (587) to send an email, my connection from my machine is shown as "Anonymous TLS connection".

http://www.postfix.org/FORWARD_SECRECY_README.html#status explains all. It's related to if it uses a client certificate to authenticate or not and it also depends on the direction. If it's your server connecting outgoing, or if it's a client connecting incoming.

I have no idea about your other question though. The user-agent will be available in the mail headers but I have no idea how to add it to the logs.

I'm still not quite understanding how/when a cipher/protocol is chosen when an encrypted email is sent to/from my mail server. For instance I emailed someone the other day and this showed up in the logs:

Code:
postfix/smtp[2554]: Trusted TLS connection established to mx.domain.com[xxx.xxx.196.175]:25: TLSv1.2
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

So it has used TLS 1.2, was trusted and chose a secure cipher (GCM in this case). This is what I was expecting.

When I receive an email from the same domain the logs say:

Code:
postfix/smtpd[84316]: Anonymous TLS connection established from mx.domain.com[xxx.xxx.196.175]: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256)

So why has the encrypted connection now dropped to TLS 1.1 and why has a different cipher been used?

Ideally I would like TLS 1.2 to be used as much as possible and for the most secure cipher to be used. I thought my main.cf would have achieved this but apparently not. Any ideas?

NB: The examples above are for server to server encryption. (ie: not an email client using submission to send an email)

If you edit /usr/local/etc/dovecot/conf.d/20-imap.conf as follows:

Code:
imap_id_send = *
imap_id_log = *

It will (sometimes) show the email client in the logs as follows:

Code:
dovecot: imap(user@domain.com): ID sent: name=Thunderbird, version=24.4.0

Also, even after configuring Postfix to use this as this for the CA certs: security/ca_root_nss I am still seeing Untrusted TLS connections in the log for some domains?
 
OK. When a client connects to another client the client tells the server the list of ciphers that it can support and the order in which it would like to use them. The server can happily accept that and use the highest one in the list that it also supports. However it can also ignore the clients request and pick one itself based on its own list.

I suspect what you are seeing here is this in action. Each side will have a different idea of which ciphers it would like to use. The majority of mail servers are likely to just use the default cipher list and use whatever the client asks for.

I personally have this configured:

Code:
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high
tls_high_cipherlist = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

The preempt line means it will attempt to use the list according to what I have configured rather than what the client has requested. Which will work for anything connecting TO my server. But for my server connecting TO another server it is at the mercy of whatever is configured on that other server. If the other server doesn't want to override me then I guess it will use my own cipher list, but if it does then it uses whatever the other side has configured.

Also I'm only overriding it for mandatory encryption, which is when I connect to my server to send a mail via SASL. For opportunistic encryption it will just use the defaults built in to postfix. As like I said before, some encryption is better than no encryption.

Looking at this I can now actually see that I'm only overriding the cipher list for my SASL connection to the submission port. There is a possible improvement to be made here by adding one for export level, but I will have to make sure it contains a wide enough list to actually include export level ones and I don't overly restrict it. Which I don't know if it's worth bothering with?

Oh yeah and the other thing. I think you will probably see a lot of untrusted connections. A lot of mailservers just use self-signed certificates. You will have no way of verifying these because their CA root certs will not be part of the root cert bundle.
 
Hi @xtaz

I really appreciate you taking the time to type up that post!

I'm not sure about changing the export cipher list as I remember reading in the Postfix documentation that you are (in theory!) not meant to change it?

My main.cf looks as follows:

Code:
smtpd_use_tls = yes
tls_preempt_cipherlist = yes
smtpd_tls_auth_only = yes
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

smtp_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_exclude_ciphers = aNULL, eNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_mandatory_protocols = !SSLv2, !TLSv1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_mandatory_ciphers  = high
smtpd_tls_mandatory_ciphers = high
lmtp_tls_mandatory_ciphers  = high

tls_high_cipherlist = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

smtp_tls_ciphers = export
smtpd_tls_ciphers = export
lmtp_tls_ciphers = export

tls_random_source = dev:/dev/urandom
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

I hope I haven't changed any settings in the above that will screw things up! I ran a vulnerability test against my server the other day and it came back really good (after disabling SSLv2 and SSLv3).

I guess when it comes to receiving email from another SMTP server I can control the protocols/ciphers but when it comes to sending email from my mail server to another I am at their mercy.

When you look in your maillog, what protocols/ciphers do you see being used when you RECEIVE mail from another MTA?

I would have thought that when I received email, that TLS 1.2 would appear more but its not. ie:

Code:
Apr 14 16:53:18 mail postfix/smtpd[86569]: Anonymous TLS connection established from mail-yh0-f42.google.com[209.85.213.42]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Do you see TLS 1.2 much in your logs?

Is there a settting in Postfix where you can prioritise the protocols used? ie: try TLS 1.2 first, then TLS 1.1 and finally TLS 1.0?
 
Last edited by a moderator:
I've checked my logs. I get a mixture of 1.0, 1.1, and 1.2. It should prioritise it already, but it will depend on the cipher it negotiates. I'm guessing if a client doesn't have any of the TLS1.2 ciphers available to it then it will fallback to 1.1 and so on. Try typing openssl ciphers TLSv1.2 and basically if it doesn't have any of those ciphers then it will fallback to one that you can see if you type openssl ciphers TLSv1

Looking specifically at Google seems to suggest they use 1.2 for incoming and 1.0 for outgoing:

Code:
/var/log/maillog:Apr 14 13:03:25 tao postfix/smtp[35454]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
/var/log/maillog.2.bz2:Apr 11 16:35:39 tao postfix/smtpd[95371]: Anonymous TLS connection established from mail-oa0-x247.google.com[2607:f8b0:4003:c02::247]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
/var/log/maillog.4.bz2:Apr  9 16:35:48 tao postfix/smtpd[6304]: Anonymous TLS connection established from mail-wi0-x22f.google.com[2a00:1450:400c:c05::22f]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
/var/log/maillog.4.bz2:Apr  9 16:40:04 tao postfix/smtp[6361]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1b]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

Then there's things like FreeBSD:

Code:
/var/log/maillog.5.bz2:Apr  8 21:43:20 tao postfix/smtpd[35378]: Anonymous TLS connection established from mx2.freebsd.org[2001:1900:2254:206a::19:2]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

Startcom:

Code:
/var/log/maillog.1.bz2:Apr 12 18:39:45 tao postfix/smtpd[44061]: Anonymous TLS connection established from mta1.startcom.org[192.116.242.7]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

Amazon:

Code:
/var/log/maillog.2.bz2:Apr 11 16:31:22 tao postfix/smtpd[95295]: Anonymous TLS connection established from a13-30.smtp-out.amazonses.com[54.240.13.30]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

Dropbox:

Code:
/var/log/maillog.2.bz2:Apr 11 16:33:31 tao postfix/smtpd[95295]: Anonymous TLS connection established from sjd-ra1-9d.sjc.dropbox.com[108.160.165.96]: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)
 
Running openssl ciphers TLSv1.2 gives me this long list of ciphers:

Code:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:AES256-GCM-SHA384:AES256-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256:NULL-SHA256

openssl ciphers TLSv1 gives:

Code:
ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:SRP-AES-256-CBC-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:AECDH-DES-CBC3-SHA:SRP-3DES-EDE-CBC-SHA:ADH-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:SRP-AES-128-CBC-SHA:ADH-AES128-SHA:ADH-SEED-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:ADH-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-ADH-RC4-MD5:EXP-RC4-MD5:ECDHE-RSA-NULL-SHA:ECDHE-ECDSA-NULL-SHA:AECDH-NULL-SHA:ECDH-RSA-NULL-SHA:ECDH-ECDSA-NULL-SHA:NULL-SHA:NULL-MD5

The only one I find baffling in your example is from FreeBSD funnily enough. When I receive emails from the forum to notify me of a new post to something I am subscribed to, the emails aren't encrypted at all. Unless your example is for receiving something else from FreeBSD?

Thanks for checking your logs :D
 
xy16644 said:
The only one I find baffling in your example is from FreeBSD funnily enough. When I receive emails from the forum to notify me of a new post to something I am subscribed to, the emails aren't encrypted at all. Unless your example is for receiving something else from FreeBSD?

Thanks for checking your logs :D

Mailing lists. That was probably the announcements about the OpenSSL bug earlier in the week. Anyway. I think basically everything is normal and you've done everything you need to do!
 
Back
Top