Tech Blog.

Thoughts, stories, ideas.

Mailserver Security

15. February 2018

When it comes to SSL/TLS configuration, the focus tends to be on web servers rather than on mail servers. But mail servers should also benefit from a strong SSL/TLS configuration with valid certificates. Mail servers that have been configured completely incorrectly quickly become apparent in IMAP and POP3 protocols, but insufficient standards are often set in server-to-server communication. Frequently, invalid certificates are accepted or no certificates at all are required because a connection is more important than security!

SSL/TLS configuration for Postfix

The following is an excerpt from the Postfix Main Configuration, which may however change at any time. Very important options are smtpd_tls_security_level and smtp_tls_security_level, which are set to “none” by default. This means that the server will never use TLS. Therefore, these options should always be set to may or encrypt.

# TLS parameters
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

SSL/TLS configuration for Dovecot

This is an excerpt from the Dovecot configuration and shows a possible configuration of the SSL/TLS parameters for Dovecot.

# DH parameters length to use.
ssl_dh_parameters_length = 4096 # SSL protocols to use.
ssl_protocols = !SSLv2 !SSLv3 # SSL ciphers to use
ssl_cipher_list = ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS # Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes

Sender Policy Framework (SPF)

With the help of SPF (RFC 7208), it is possible to validate if a server which wants to deliver an email is actually authorized to send emails from the corresponding domain.
For example, the server smtp.send.example.com establishes a connection to the server smtp.recv.example.com and tries to deliver an email to it from user@mail.example.com. On the basis of SPF, the server smtp.recv.example.com can verify if the server smtp.send.example.com is a valid email server for the domain mail.example.com.
The corresponding SPF record exists in the DNS system and can look similar to the following:

mail.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all"

That means that the email is accepted if one of the following conditions is met:

  • the IP address of the server smtp.send.example.com lies within 192.0.2.0/24 or 2001:db8::1
  • the DNS A record mail.example.com matches the IP address of the server smtp.send.example.com

In all other cases the email must undergo further checks (which can be defined by the user).

DomainKeys Identified Mail (DKIM) Signatures

The idea behind DomainKeys Identified Mail (DKIM, RFC 6376) is to check that an email was not changed during transit. To ensure this, the header, the content and the attachments of an email message are signed. However, the signature is not applied to the entire header, as certain fields can change during transmission of an email. The RFC proposes to sign the following values:

  • From (REQUIRED)
  • Reply-To
  • Subject
  • Date
  • To, Cc
  • Resent-Date, Resent-From, Resent-To, Resent-Cc
  • In-Reply-To, References
  • List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

DKIM signatures are stored in the header of an email message, the field is called DKIM-Signature. The value of this field includes multiple key/value pairs. The most important are:

  • v: DKIM version
  • a: algorithm (e.g. rsa-sha256)
  • d: signing domain (origin Domain)
  • s: selector

A receiving mail server can request the current domain key via DNS, based on the domain and the selector. The DNS entry looks similar to the following:

selector._domainkey.example.com IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )

If an email with the header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.org;
s=mail; t=1498137281;
bh=ClzbA4T6yvpEouOct2aSAnFWcEUHTr6SDxrQizAy6ao=;
h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;
b=QTY/4jFXMH2piHJ478mtyQ6heutdCLw/VCrD3XcDVugITPSXnrEqiV07+N9YNQcTraCmyxT49upd8uz9fqRLz0VTZWoPF3+9eT9X2jdQU/1WpVtalFrQuBoXfzy4KZJdxp/DjwAB89CkmvRvv5aYSw0XrJsry1uMoVJx6NDCskA=

is received, the corresponding TXT DNS record which refers to the key is mail._domainkey.example.org.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) expands the two mechanisms DKIM and SPF. If a DKIM header is not present or a SPF record is not found, these two procedures do not trigger any actions and the email is treated as standard. DMARC offers the option to specify how to treat an email which is missing one or both procedures. DMARC is also a little stricter where DKIM handling is concerned, e.g. the From address field must match the domain in the DKIM signature field. Another point facilitated by DMARC is the reporting of incorrectly sent emails. Reports can be requested from receiving mail servers.
In the same way as DKIM, DMARC is published in the DNS. A possible entry looks similar to the following:

_dmarc.example.com
IN TXT
"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com"

Where the individual values have the following meaning:

  • v: Version
  • p: Policy for this domain
  • sp: Policy for subdomains
  • pct: Percentage of “bad” emails, from which the policy is to be applied
  • rua: DMARC report URI address

Test

Manual tests can be carried out with openssl. These are only basic commands, which represent the contents of the server certificate in text form. Cipher suites can also be tested, but since this involves long and numerous commands, it is recommended that existing services (e.g. Hardenize) are used for this purpose. If this is not desirable or is not possible from a technical perspective, SSL decoder can also be installed locally, because the software is Open Source and available on Github.

  • SMTP
$ openssl s_client -connect example.com:25 -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text
  • IMAP
$ openssl s_client -connect example.com:143 -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text

Additional features such as SPF and DMARC can be tested very easily by simply checking the DNS records:

# SPF Record
$ dig +short TXT example.com
"v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::1 a ~all" # DKIM
$ dig +short TXT mail._domainkey.example.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" # DMARC
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.com"

Several providers are suitable for carrying out more comprehensive tests including an evaluation of the contents, for example Hardenize or MX Toolbox.

Further information

It is also worth noting that DNS-based Authentication of Named Entities (DANE) can be used with mail servers as well. This however is beyond the scope of this blog post and will be dealt with in another post. There are also excellent How-To guides for mail servers, and the following two should be mentioned here:

Links