diff --git a/src/acknowledgements.tex b/src/acknowledgements.tex index 7978982d..cfd291f4 100644 --- a/src/acknowledgements.tex +++ b/src/acknowledgements.tex @@ -13,6 +13,7 @@ \section*{Acknowledgements} Grigg, Ian \\ Horenbeck, Maarten \\ Huebl, Axel \\ +Koetter, Patrick Ben \\ Kovacic, Daniel \\ Lenzhofer, Stefan \\ Lorünser, Thomas \\ @@ -28,6 +29,7 @@ \section*{Acknowledgements} Roeckx, Kurt \\ Rublik, Martin \\ Seidl, Eva (PDF layout) \\ +Strotmann, Carsten \\ Wagner, Sebastian («sebix») \\ Zangerl, Alexander \\ }\end{multicols} diff --git a/src/common/names.tex b/src/common/names.tex index 75585ee3..ffedd52b 100644 --- a/src/common/names.tex +++ b/src/common/names.tex @@ -22,6 +22,8 @@ \newacronym{EDH}{edh}{Ephemeral Diffie-Hellman} \newacronym{EECDH}{eecdh\alsoidx{Diffie--Hellman}\alsoidx{elliptic curve}}{% elliptic curve ephemeral Diffie--Hellman} +\newacronym{MSA}{msa}{% + A message submission host from which messages sent by MUAs originates and will be transported towards its final destination} \newacronym{PFS}{pfs}{% perfect forward secrecy} \newacronym{RSA}{rsa}{Rivest Shamir Adleman} diff --git a/src/configuration/DNS/resolv.conf/resolv.conf b/src/configuration/DNS/resolv.conf/resolv.conf new file mode 100644 index 00000000..b7dc71e7 --- /dev/null +++ b/src/configuration/DNS/resolv.conf/resolv.conf @@ -0,0 +1,6 @@ +search example.com +# Local resolver +nameserver 127.0.1.1 +# Trustworthy fallbacks +nameserver 192.0.2.1 +nameserver 203.0.113.254 diff --git a/src/configuration/MailServers/Postfix/main.cf b/src/configuration/MailServers/Postfix/main.cf index 15aede5d..c3b8ba7e 100644 --- a/src/configuration/MailServers/Postfix/main.cf +++ b/src/configuration/MailServers/Postfix/main.cf @@ -17,25 +17,55 @@ append_dot_mydomain = no readme_directory = no -readme_directory = no +## General TLS options +tls_ssl_options = NO_COMPRESSION -# TLS parameters -smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key -# use 0 for Postfix >= 2.9, and 1 for earlier versions +## Server-side TLS +# Server certificate +smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem +# Server key +smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key +# TLS Logging +# Use 0 for Postfix >= 2.9, and 1 for earlier versions smtpd_tls_loglevel = 0 -# enable opportunistic TLS support in the SMTP server and client +# Enable opportunistic TLS support in the SMTP server smtpd_tls_security_level = may +# Optional: If you have SMTP AUTH enabled, offer it after STARTTLS only +# in order to protect SASL's unencrypted PLAIN and LOGIN mechanisms +smtpd_tls_auth_only = yes + +## Submission server TLS +# Disable unwanted protocols +mua_tls_mandatory_protocols = !SSLv2, !SSLv3 +# Demand high ciphers +mua_tls_mandatory_ciphers=high +# Limit the cipher list +mua_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA +# TODO +mua_tls_eecdh_grade=ultra + +## Client-side TLS +# Enable opportunistic TLS support in the SMTP client smtp_tls_security_level = may +# Client certificate +smtp_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem +# Client key +smtp_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key +# Log when remote server offers STARTTLS (useful to identify partners for +# policies) +smtp_tls_note_starttls_offer = yes +# TODO smtp_tls_loglevel = 1 -# if you have authentication enabled, only offer it after STARTTLS -smtpd_tls_auth_only = yes -tls_ssl_options = NO_COMPRESSION -smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 -smtpd_tls_mandatory_ciphers=high -tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA -smtpd_tls_eecdh_grade=ultra + +## Client-side DANE TLS +# Enable opportunistic and identified TLS support in the SMTP client +smtp_tls_security_level = dane +# Require DNSSEC DNS lookups +smtp_dns_support_level = dnssec + + + smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache diff --git a/src/configuration/MailServers/Postfix/master.cf b/src/configuration/MailServers/Postfix/master.cf index 545a2f9e..e1d887a7 100644 --- a/src/configuration/MailServers/Postfix/master.cf +++ b/src/configuration/MailServers/Postfix/master.cf @@ -10,8 +10,12 @@ # ========================================================================== smtp inet n - - - - smtpd submission inet n - - - - smtpd - -o smtpd_tls_security_level=encrypt - -o tls_preempt_cipherlist=yes + -o smtpd_tls_security_level=encrypt + -o tls_preempt_cipherlist=yes + -o smtpd_tls_mandatory_protocols=$mua_tls_mandatory_protocols + -o smtpd_tls_mandatory_ciphers=$mua_tls_mandatory_ciphers + -o tls_high_cipher_list=$mua_high_cipherlist + -o smtpd_tls_eecdh_grade=$mua_tls_eecdh_grade # -o smtpd_sasl_auth_enable=yes # -o smtpd_client_restrictions=permit_sasl_authenticated,reject # -o milter_macro_daemon_name=ORIGINATING @@ -37,7 +41,7 @@ proxywrite unix - - n - 1 proxymap smtp unix - - - - - smtp # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - - - - smtp - -o smtp_fallback_relay= + -o smtp_fallback_relay= # -o smtp_helo_timeout=5 -o smtp_connect_timeout=5 showq unix n - - - - showq error unix - - - - - error @@ -102,7 +106,7 @@ ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient -scalemail-backend unix - n n - 2 pipe +scalemail-backend unix - n n - 2 pipe flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension} mailman unix - n n - - pipe flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py diff --git a/src/practical_settings.tex b/src/practical_settings.tex index a7cbf831..f16f8fe7 100644 --- a/src/practical_settings.tex +++ b/src/practical_settings.tex @@ -1,3 +1,6 @@ +\section{DNS} +\label{sec:dns} +\input{practical_settings/dns} \section{Webservers} \label{sec:webservers} \input{practical_settings/webserver} diff --git a/src/practical_settings/dns.tex b/src/practical_settings/dns.tex new file mode 100644 index 00000000..1d8a4907 --- /dev/null +++ b/src/practical_settings/dns.tex @@ -0,0 +1,364 @@ +The Domain Name System is of fundamental importance to end users and many +services. It's availability and authenticity of its data are critical. DNS +servers fall into two parts -- resolver and authoritative name server. +Resolvers only resolve DNS queries, whereas authoritative name servers may also +serve DNS data to others. + +Authoritative name server are more vulnerable than resolvers, because they get +exposed to remote systems. A malicious attacker will typically try to decrease +a DNS services availability or forge the data it serves. Serving data also +requires a larger code base in the server's components, which by definition +makes an authoritative name server more complex and more vulnerable to bugs and +malicious code. + +Overall it takes greater caution to run an authoritative name server than a +local resolver. Unless you serve your own domain there's no need to run an +authoritative name server. + +\subsection{resolv.conf} + +The resolver configuration file \verb|/etc/resolv.conf| specifies which +resolvers (\verb|nameserver|) your system library will query in order to resolve +hostnames and IP addresses. You may specify more than one nameserver using the +\verb|nameserver| option. They will be read as list from top to bottom. + +Always add more than one nameserver in case the first one or the second one +fails. It does not make sense to list more than three \verb|nameserver| options. +Mailservers, for example, will not try more than three name servers in a row +when they try to resolve a destination. + +A good order to sort the list of \verb|nameserver| options is by proximity +first and by availability second. + +A local, caching resolver should always be listed first \verb|nameserver| in +\verb|/etc/resolv.conf|. Properly configured it will deliver query results +fastest, because it runs on the same system and is not subject to network or +service latency due to high load. + +Even more important it is also the trustworthiest source of DNS information. DNS +data could be forged on a remote system that is not under your control without +your notice. It might also get tampered while it is in transit to your host. +These things are harder to manipulate if the application serving the data is on +your system. + +\configfile{resolv.conf}{1-6}{List local resolver first} + +\paragraph{DNSSEC} Take special care of the name servers you list if you plan to +use DNSSEC to secure your services! + +A properly configured DNSSEC-enabled resolver will verify the data it retrieves. +The fact it can't verify data from a DNSSEC-domain may be an indicator the DNS +server queried or its data has been compromised. + +Regular resolvers and DNSSEC-capable resolvers that don't verify omit this fact +and serve the result to the application that initiated the DNS query. A +verifying resolver will not -- it will protect the service and its users and +keep the data away. + +Make sure your \verb|nameserver| list in \verb|/etc/resolv.conf| consists of +DNSSEC-capable resolvers only. If only one resolver in the +\verb|nameserver| list does not verify DNS data, the whole verification chain is +broken. + +\subparagraph{Background on DNSSEC validation signalling} + +To understand the need for only DNSSEC-validating resolver in the +\verb|/etc/resolv.conf|, it is important to understand how +DNSSEC-validation results are signalled to the client. + +A DNS-resolver with enabled DNSSEC-validation will always try to +validate the received DNS data, unless the client has set the CD-Flag +(CD=checking disabled) in the query. + +If the client has send the query with an DO-flag set (DO=DNSSEC OK), +the client has indicated that it does unterstand the extended DNSSEC +signalling. The DNS-resolver will set the AD-flag (AD=Authenticated +Data) in an successful validated DNS response to the client. DNSSEC +aware clients can now make a security decision on the trustworthiness +of the data (AD-Flag=more trustworthy). + +If the client has not send the query with a DO-flag (legacy DNS +client), the DNS-resolver will still send successfull validated +DNS-data in an response to the client, but will not set any extra +flags other than permitted by the original DNS. + +In both cases (DNSSEC-aware client or legacy client), if the DNS-data +does not validate, the DNS-resolver will \emph{NOT} return the +DNS-data to the client, instead it will return a SERVFAIL error +condition. + +Because SERVFAIL is an generic error condition, the client will not be +able to tell if the data is bad (compromised) or if the DNS-resolver +has some technical issues. The client will therefor fallback to the +next DNS-resolver in \verb|/etc/resolv.conf| and retry the query. + +If there is only one non-DNSSEC-validating DNS-resolver listed in +\verb|/etc/resolv.conf|, the bad data will be returned by that +DNS-resolver and the DNSSEC security is broken. + +\subparagraph{Example} + +The following example shows a dig-reply indicating the domain queried is +DNSSEC-enabled. This is indicated by the \verb|ad|-flag (authenticated data) in +the HEADER-section. The \verb|+dnssec| switch sets the \verb|DO|-Flag +in the outgoing query, indicating to the DNS-resolver that this client +does unterstand DNSSEC and that the \verb|ad|-flag should be returned. + +\begin{lstlisting} +$ dig +dnssec example.com + +; <<>> DiG 9.9.5-P2 <<>> +dnssec example.com +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49123 +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 +\end{lstlisting} + +\textbf{Note:} The example above requires a DNSSEC-enabled +resolver. Legacy (non-DNSSEC-validating) resolvers cannot tell +\verb|dig| the domain in question has been authenticated. + +\subparagraph{on the future of DNS stub resolver configuration on + Unix} + +As IP-Network-configuration becomes more enhanced over time (DHCP, +DHCPv6, IPv6-RA, mDNS), operating-system vendors move away from a +simple \verb|/etc/resolv.conf| text file towards more ``integrated'' +network configuration databases (for example \verb|systemd-networkd| +on Linux, \verb|netadm|/\verb|netcfg| on Solaris, \verb|configd| on +MacOS X). + +With these new network configuration systems, care must be taken that +all configured DNS-resolver have DNSSEC-validation +enabled. Unfortunatly, this becomes more difficult with network based +provisioning that is itself not authenticated (DHCP, IPv6-RA ...). + +\subsection{DNS-Resolver} + +A DNS-Resolver is a DNS-Server configured to accept DNS-queries from +client machines with the ``Recursion-Desired''-Flag set. Some +DNS-Server products allow the DNS-Resolver function to run in the same +process as an authoritative DNS-Server (hosting DNS-Zones), for +example BIND 9 and Microsoft DNS. Other DNS-Server products implement +a dedicated DNS-Resolver, for example Unbound. + +For a DNSSEC deployment, it is recommended best practice to dedicated +DNS-resolver that are separate from any authoritative +DNS-data. A DNS-Server can only validate (check) DNSSEC signed data +that is being received from an external server, it cannot validate its +own authoritative data. + +\subsubsection{BIND 9} + +The BIND 9 DNS-Server is a DNS-Resolver and DNS-authoritative Server +from ISC (\url{http://www.isc.org}. BIND 9 is available under the +liberal ISC License and part of almost all Linux/Unix-Distributions. + +\paragraph{Version 9.7.x-9.8.x} + +To enable DNSSEC validation in BIND 9 Versions 9.7 to 9.8, the +trust-anchor of the DNS root-zone ``.'' must be configured in the BIND +9 configuration file \verb|named.conf|. The trust-anchor is a copy of +the Key-Signing-Key (KSK) used to sign the DNS root-zone: + +\begin{lstlisting} +// this is the trust-anchor for the DNS root-zone "." +managed-keys { + "." initial-key 257 3 8 + "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF + FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX + bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD + X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz + W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS + Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq + QxA+Uk1ihz0="; +}; + +options { + directory "/var/named"; + // enable DNSSEC + dnssec-enabled yes; + // enable DNSSEC-validation + dnssec-validation yes; + // enable the build-in DLV trust anchor + dnssec-lookaside auto; + // more options following +}; +\end{lstlisting} + +DLV (DNSSEC-lookaside validation) is an alternative validation path +for DNSSEC signed domains that cannot be secured via a chain-of-trust +to the root zone (mainly because their parent ccTLD has not yet been +DNSSEC signed). + +DLV is specified in RFC 5074 +(\url{http://tools.ietf.org/rfc/rfc5074.txt}), and the main DLV +registry is operated by ISC (\url{http://dlv.isc.org}). Only BIND 9 +and Unbound DNS-Resolver support the alternative DLV lookup path for +DNSSEC. + +Enabling DLV is recommended but not required. + +BIND 9 will automatically updated the trust-anchor via the RFC 5011 +(\url{http://tools.ietf.org/rfc/rfc5011.txt}) mechanism. + +\paragraph{Version 9.9.0+} + +BIND 9 starting with BIND 9.9.0 comes with the trust-anchor for the +root-DNS-zone preinstalled (in a file named \verb|bind.keys|), the +trust-anchors does not need to be configured in the \verb|named.conf| +file. + +\begin{lstlisting} +options { + directory "/var/named"; + // enable DNSSEC + dnssec-enabled yes; + // enable DNSSEC-validation via the + // build in trust-anchor + dnssec-validation auto; + // enable the build-in DLV trust anchor + dnssec-lookaside auto; + // more options following +}; +\end{lstlisting} + +\subsubsection{Unbound} + +Unbound is a validating, recursive, and caching DNS resolver from +NLnetLabs. It is licensed under the BSD-License. Unbound has been +designed with security and DNSSEC in mind. Sourcecode and +documentation can be found at \url{http://unbound.net}. + +Unbound has DNSSEC validation enabled by default, however care must be +taken that Unbound has a valid trust-anchor for the Internet +root-DNS-zone. Without a valid trust-anchor, DNSSEC validation will +not be possible. + +The smallest possible Unbound DNSSEC configuration is: +\begin{lstlisting} +server: + # The following line will configure unbound to perform cryptographic + # DNSSEC validation using the root trust anchor. + auto-trust-anchor-file: "/var/lib/unbound/root.key" +\end{lstlisting} + +Unbound comes with an tool to securly fetch (via TLS from the IANA +website) the Internet root-DNS-trust anchor. This tool us usually run +from the start-script that starts the Unbound DNS-Resolver: +\begin{lstlisting} +# unbound-anchor -v +/var/lib/unbound/root.key has content +success: the anchor is ok +\end{lstlisting} + +The Unbound trust-anchor-file is a text file that contains the +Root-Zone KSK as well as information on the freshness of the data: +\begin{lstlisting} +# cat /var/lib/unbound/root.key +; autotrust trust anchor file +;;id: . 1 +;;last_queried: 1405160756 ;;Sat Jul 12 12:25:56 2014 +;;last_success: 1405160756 ;;Sat Jul 12 12:25:56 2014 +;;next_probe_time: 1405202059 ;;Sat Jul 12 23:54:19 2014 +;;query_failed: 0 +;;query_interval: 43200 +;;retry_time: 8640 +. 172800 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVV... ;{id = 19036 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchange=1350651872 ;;Fri Oct 19 15:04:32 2012 +\end{lstlisting} + +For roaming users (Laptops, Smartphones and Pads) there is a special +version of Unbound bundled with a tool that monitors the ability to +use DNSSEC (which is not possible is certain captive WLAN +portals). This bundle is called ``DNSSEC-trigger'' +(\url{http://nlnetlabs.nl/projects/dnssec-trigger/}) and is available +for Linux, Windows and MacOS X. + +\subsubsection{Microsoft DNS} + +\subsubsection{dnsmasq} + +\subsection{authoritative DNS-Server} + +\subsubsection{Transaction signatures - TSIG and SIG(0)} + +\paragraph{TSIG} +what is TSIG, choice of key algorithms and sizes, generating keys, +configuration, test + +\paragraph{SIG(0)} +what is SIG(0), choice of key algorithms and sizes, generating keys, +configuration, test + +\subsubsection{signed DNS zones - DNSSEC} + +\paragraph{recommended DNS design for DNSSEC} + +split of DNS-resolver and authoritative server, mutual exlusive AA- +and AD-Flags + +\paragraph{Parameters for DNSSEC signing} + +Choice of algorithms, key-length, key-rollover interval, RFC 6781 + +\paragraph{DNSSEC troubleshooting} + +links, tools and tips for DNSSEC troubleshooting + +\paragraph{BIND 9} + +how to sign a Zone with BIND 9 + +\subparagraph{key generation} + +how to generate DNSSEC keys with \verb|dnssec-keygen| + +\subparagraph{manual/offline signing} + +howto sign a zone manually with \verb|dnssec-signzone| + +\subparagraph{DNSSEC automation for dynamic zones} + +howto sign a dynamic zone with \verb|rndc sign| and update the zone +content with \verb|update-policy local;| and \verb|nsupdate|. + +\subparagraph{inline-signing of static zones} + +howto sign a static zone with \verb|rndc sign| and update the zone +content with a text editor + +\subparagraph{BIND 9 and Hardware Security Modules} + +How to interface BIND 9 with an HSM or SoftHSM to securly store DNSSEC +key material + +\paragraph{Knot-DNS} + +how to sign a zone with Know-DNS + +\paragraph{NSD} + +how to sign a zone for NSD with the ldns tools + +\paragraph{PowerDNS} + +how to sign a zone with PowerDNS, how PowerDNS automatically signs +data from a database store + +\paragraph{Y.A.D.I.F.A} + +how to serve a DNSSEC signed zone from the Y.A.D.I.F.A. DNS-Server. + +\paragraph{Bundy} + +how to server a DNSSEC signed zone from the BUNDY DNS-Server + +\paragraph{Microsoft Windows DNS Server} + +how to sign a zone with the Windows DNS server + +\paragraph{OpenDNSSEC} + +how to manage DNSSEC-maintenance and key-rollovers with the OpenDNSSEC +tool + diff --git a/src/practical_settings/mailserver.tex b/src/practical_settings/mailserver.tex index 678ee7b0..3693c2d0 100644 --- a/src/practical_settings/mailserver.tex +++ b/src/practical_settings/mailserver.tex @@ -145,8 +145,14 @@ \subsubsection{Tested with Versions} \item Postfix 2.9.6, Debian Wheezy \end{itemize*} +TLS in Postfix may take place in two Postfix programs - the \verb|smtpd| SMTP server and the \verb|smtp| SMTP client. This compartmentalized architecture is reflected in the following subsections. We'll start with the \verb|smtpd| SMTP server first. -\subsubsection{Settings} +\subsubsection{TLS in Postfix' smtpd SMTP Server} +As discussed in section \ref{subsection:smtp_general} "any encrypted mail transport is better than forcing a remote client to resort to plaintext transport" simply because the server offered a limited cipher suite and the client couldn't find any cipher to use. Thus, unless you setup a dedicated and controlled SMTP server (e.g. on submission port \verb|587|), you should not restrict the list of supported ciphers for a publicly referenced MX host listening on the default Port \verb|25|. + +In order to enable opportunistic TLS for a publicly referenced SMTP server add the following configuration to Postfix' \verb|main.cf|: + +\configfile{main.cf}{20-35}{Opportunistic TLS in Postfix} %% I (cm) consider the generation of own DH parameters to be voodoo until %% someone can explain the contrary. They are, after all, public, and @@ -178,28 +184,66 @@ \subsubsection{Settings} %% smtpd_tls_dh1024_param_file = /etc/postfix/dh_param_1024.pem %% \end{lstlisting} -\paragraph{MX and SMTP client configuration:} -As discussed in section \ref{subsection:smtp_general}, because of opportunistic encryption we do not -restrict the list of ciphers. There are still some steps needed to -enable TLS, all in \verb|main.cf|: +\paragraph{MSA:} +Things change if you plan to run a dedicated \verb|smtpd| SMTP server listening on the submission port \verb|587|. This port is special because MUAs should use it to submit mail. In order to do so they MUST authenticate (SMTP AUTH). -\configfile{main.cf}{22-33}{Opportunistic TLS in Postfix} +The most widely supported AUTH mechanisms in MUAs are PLAIN and LOGIN. These mechanisms allow AUTH passwords to be stored in crypted backends, but they are transmitted base64 encoded only and SHOULD be protected by an encrypted transport layer. Since the clients are more or less well-known you may limit the cipher suite in this controlled environment. + +The following MSA configuration demands TLS (mandatory TLS) from all clients connecting and limits the cipher suite at the same time. The configuration needs to be added in two Postfix configuration files: -\paragraph{MSA:} -For the MSA \verb|smtpd| process, we first define the ciphers that are -acceptable for the ``mandatory'' security level, again in -\verb|main.cf|: +The first settings in Postfix \verb|main.cf| establish new configuration parameters and assigns TLS options as desired. All configuration names begin with \verb|mua_| which are non-default names on purpose. They create a namespace that cannot collide with Postfix own \verb|smtpd_| parameter names adressing the \verb|smtpd| SMTP server -- they will never accidentally influence TLS behaviour of other SMTP servers, e.g. the one listening on port \verb|25|. + +\configfile{main.cf}{37-45}{MSA TLS configuration in Postfix} + +The second file that needs to be edited is Postfix \verb|master.cf|. The changes enable the Postfix submission service, create options for mandatory TLS and server-side cipher control and finally map settings from \verb|main.cf| onto the newly created submission server. + +\configfile{master.cf}{12-18}{MSA smtpd service configuration in Postfix} + +%% commented until PFS has been described +%% For those users who want to use EECDH key exchange, it is possible to customize this via: +%% \configfile{main.cf}{45-45}{EECDH customization in Postfix} +%% The default value since Postfix 2.8 is ``strong''. + +%% \subsubsection{Settings for Opportunistic TLS using DANE} +%% +%% If the DNS-domain the Postfix smtp client connects to is DNSSEC-enabled and if that domain offers a TLSA ressource record +%% +%% As of version 2.11 Postfix may also automatically identify +%% +%% supports DNS-Based Authentication of Named Entities (DANE) via DNSSEC-enabled domains. + +\subsubsection{TLS in Postfix' smtp SMTP Client} + +Enabling opportunistic TLS in the Postfix \verb|smtp| client is simple. Set \verb|smtp_tls_security_level| to \verb|may| and you are done. Additionally, if you want to and if your certificate has been signed for client usage also and not only server usage, provide the paths to your x509 certificate and key. When a server asks your Postfix \verb|smtp| client to identify itself with a TLS client certificate Postfix will send what you have provided during configuration. -\configfile{main.cf}{35-37}{MSA TLS configuration in Postfix} +\textbf{Note:} Asking a client for its TLS certificate is not default behaviour. It has to be enabled on the SMTP server side explicitly. It often remains disabled because not all client are able to handle TLC client certificate requests properly. Postfix has not been reported to be among these erroneous clients. -Then, we configure the MSA smtpd in \verb|master.cf| with two -additional options that are only used for this instance of smtpd: +%% Mist klappt nicht \ref{section:DNS} + +\configfile{main.cf}{47-58}{TLS client configuration in Postfix} + +In the example above \verb|smtp_tls_note_starttls_offer| causes Postfix to log servers that offered \verb|STARTTLS|. This offers a convenient way to find out about destinations to whom explicit SMTP TLS policies could be written down in \verb|smtp_tls_policy_maps| (see also: \verb|postconf(5)|). + +Setting up policies in \verb|smtp_tls_policy_maps| is a first step towards identified TLS. Identified TLS requires to verify the servers identity and putting it down in \verb|smtp_tls_policy_maps| so Postfix' \verb|smtp| client is able to use the provided data to identify the server it communicates with. + +Usually this means to extract the servers' x509 certificate fingerprint, call the team that runs the server, verify the fingerprint and - once verified - write it down so Postfix can use it. This is costly and error-prone and only few people make that extra effort. + +\paragraph{DANE} DNS-Based Authentication of Named Entities (DANE) automates this task. It uses a DNSSEC-enabled domain to distribute the SMTP servers certificate via TLSA Ressource Records (see: ???). Postfix (2.11.1) is the world's first MTA to implement "SMTP security via opportunistic DANE TLS". Using TLSA RRs, distributed via a DNSSEC-enabled domain, it can automatically identify a remote server offering \verb|STARTTLS|. This adds another level of security, since it eliminates Man-in-the-Middle-attacks. + +\textbf{Note:} TLSA RRs allow to publish publicly signed certificates from CAs, but also self-signed ones. If you don't trust in CAs DNSSEC-enabled distribution of server identities is a good way to go. + +Enabling DANE TLS in Postfix' \verb|smtp| client is simple. It requires a DNSSEC-aware DNS Resolver as described in \ref{subsection:Resolver} and the following options in \verb|main.cf|: + +\configfile{main.cf}{61-65}{DANE TLS client configuration in Postfix} + +Once you've reloaded Postfix you will begin to notice logo lines indicating identified TLS like this: +\begin{lstlisting} +Jul 11 12:20:01 mail postfix/smtp[9067]: Verified TLS connection established to mail.sys4.de[194.126.158.139]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) +\end{lstlisting} -\configfile{master.cf}{12-14}{MSA smtpd service configuration in Postfix} +This testifies Postfix was able to identify the remote server via DNS-Based Authentication of Named Entities. -For those users who want to use EECDH key exchange, it is possible to customize this via: -\configfile{main.cf}{38-38}{EECDH customization in Postfix} -The default value since Postfix 2.8 is ``strong''. +If you want to offer DANE to other mail servers you need to DNSSEC-enable your MX domain. This is described in \ref{chapter:DNS}. \subsubsection{Limitations}