Send correct SNI domain when the TLS base domain is CNAME expanded

diff --git a/postfix/HISTORY b/postfix/HISTORY
index 707bad4b7c5b73d23bffab763547f6e119b83c6f..0f0fc60fc4f75db9e1ea4487ba55d00a599968c1 100644 (file)
--- a/postfix/HISTORY
+++ b/postfix/HISTORY
@@ -23326,3 +23326,18 @@ Apologies for any names omitted.
        Bugfix (introduced: Postfix 3.1): "postfix tls deploy-server-cert"
        did not handle a missing optional argument. File:
        conf/postfix-tls-script.
+
+20200626
+
+       Bugfix (introduced: Postfix 2.11): The Postfix smtp(8) client did not
+       send the right SNI name when the TLSA base domain was a secure CNAME
+       expansion of the MX hostname (or non-MX nexthop domain).  Domains with
+       CNAME expanded MX hosts are not conformant with RFC5321, and so are
+       rare.  Even more rare are MX hosts with TLSA records for their CNAME
+       expansion.  For this to matter, the remote SMTP server would also have
+       to select its certificate based on the SNI name in such a way that the
+       original MX host would yield a different certificate.  Among the ~2
+       million hosts in the DANE survey, none meet the conditions for
+       returning a different certificate for the expanded CNAME.  Therefore,
+       sending the correct SNI name should not break existing mail flows.
+       Fixed by Viktor Dukhovni.  File: src/tls/tls_client.c.

diff --git a/postfix/src/tls/tls_client.c b/postfix/src/tls/tls_client.c
index 6bc1c3acd0f8fb4e5536bc548b56f9cb98a1cb66..72f90090c372f5d22dd2af0d0b4361984cdb7497 100644 (file)
--- a/postfix/src/tls/tls_client.c
+++ b/postfix/src/tls/tls_client.c
@@ -973,6 +973,7 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
 #ifdef TLSEXT_MAXLEN_host_name
     if (TLS_DANE_BASED(props->tls_level)
        && strlen(props->host) <= TLSEXT_MAXLEN_host_name) {
+       const char *sni;
 
        /*
         * With DANE sessions, send an SNI hint.  We don't care whether the
@@ -984,15 +985,19 @@ TLS_SESS_STATE *tls_client_start(const TLS_CLIENT_START_PROPS *props)
         * avoid SNI, and there are no plans to support SNI in the Postfix
         * SMTP server).
         * 
+        * Per RFC7672, the required SNI name is the TLSA "base domain" (the one
+        * used to construct the "_25._tcp.<fqdn>" TLSA record DNS query).
+        * 
         * Since the hostname is DNSSEC-validated, it must be a DNS FQDN and
         * thererefore valid for use with SNI.  Failure to set a valid SNI
         * hostname is a memory allocation error, and thus transient.  Since
         * we must not cache the session if we failed to send the SNI name,
         * we have little choice but to abort.
         */
-       if (!SSL_set_tlsext_host_name(TLScontext->con, props->host)) {
+       sni = props->dane->base_domain;
+       if (!SSL_set_tlsext_host_name(TLScontext->con, sni)) {
            msg_warn("%s: error setting SNI hostname to: %s", props->namaddr,
-                    props->host);
+                    sni);
            tls_free_context(TLScontext);
            return (0);
        }