[exim-dev] [Bug 2594] New: CNAME handing can break TLS certi…

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
New-Topics: [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification, [exim-dev] [Bug 2594] CNAME handling can break TLS certificate verification
Subject: [exim-dev] [Bug 2594] New: CNAME handing can break TLS certificate verification
https://bugs.exim.org/show_bug.cgi?id=2594

            Bug ID: 2594
           Summary: CNAME handing can break TLS certificate verification
           Product: Exim
           Version: 4.93
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: TLS
          Assignee: jgh146exb@???
          Reporter: chris@???
                CC: exim-dev@???


When the manualroute router looks up the IP address of a name in the
route_data, if it encounters CNAME records, then it correctly follows them
until it finds an A (or AAAA) record.

However, it also uses the CNAME value as the domain name later used by the smtp
transport to verify the TLS certificate returned by the server. This is wrong -
or at least inconsistent with how web browsers work - the original (fully
qualified) name in the route_data is the correct name for certificate
verification.

For example, in our organisation our internal servers (HTTPS & SMTP) use a
wildcard certificate for *.dev.edesix.com. The mail server is resolved as
follows...

mail.dev.edesix.com CNAME mail.edesix.local
mail.edesix.local A 192.168.1.6

For context - the *.dev.edesix.com wildcard certificate is a real (non-self
signed) LetsEncrypt certificate. This set-up allows our developers to test TLS
functionality on local servers only accessible on the LAN using a real TLS
cert. It works fine with web servers and browsers, but not with exim as an SMTP
client.

Excerpt from debug of a delivery failure:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

routing root@???
--------> smarthost router <--------
local_part=root domain=juno.edesix.com
checking domains
juno.edesix.com in ""? no (end of list)
juno.edesix.com in "! +local_domains"? yes (end of list)
calling smarthost router
smarthost router called for root@???
domain = juno.edesix.com
original list of hosts = 'mail.dev.edesix.com' options = 'bydns ipv4_only'
expanded list of hosts = 'mail.dev.edesix.com' options = 'bydns ipv4_only'
set transport smarthost_smtp
finding IP address for mail.dev.edesix.com
doing DNS lookup
mail.dev.edesix.com in "*"? yes (matched "*")
DNS lookup of mail.dev.edesix.com (A) succeeded
192.168.1.6 in "<; 0.0.0.0 ; 127.0.0.0/8 ; ::1"? no (end of list)
fully qualified name = mail.dev.edesix.com
mail.edesix.local 192.168.1.6 mx=-1 sort=-470
queued for smarthost_smtp transport: local_part = root
domain = juno.edesix.com
errors_to=NULL
domain_data=NULL localpart_data=NULL
routed by smarthost router
envelope to: root@???
transport: smarthost_smtp
host mail.edesix.local [192.168.1.6]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Before I added 'bydns ipv4_only' to the route_data the DNS lookup was a little
more complicated, but with the same result:

finding IP address for mail.dev.edesix.com
doing DNS lookup
mail.dev.edesix.com in "*"? yes (matched "*")
DNS lookup of mail.dev.edesix.com (AAAA) succeeded
CNAME found: change to mail.edesix.local
DNS lookup of mail.edesix.local (AAAA) gave NO_DATA
returning DNS_NODATA
faking res_search(AAAA) response length as 65535
writing neg-cache entry for mail.edesix.local-AAAA-800041, ttl 3600
DNS lookup of mail.dev.edesix.com (A/AAAA) requested AD, but got AA
DNS lookup of mail.dev.edesix.com (A) succeeded
192.168.1.6 in "<; 0.0.0.0 ; 127.0.0.0/8 ; ::1"? no (end of list)
fully qualified name = mail.dev.edesix.com
mail.edesix.local 192.168.1.6 mx=-1 sort=-245

Here is the smtp transport debug output:

smarthost_smtp transport entered
root@???
hostlist:
'mail.edesix.local' IP 192.168.1.6 port -1
checking status of mail.edesix.local
locking /var/spool/exim/db/retry.lockfile
locked /var/spool/exim/db/retry.lockfile
EXIM_DBOPEN: file </var/spool/exim/db/retry> dir </var/spool/exim/db>
flags=O_RDONLY
returned from EXIM_DBOPEN: 0x5635b371d370
opened hints database /var/spool/exim/db/retry: flags=O_RDONLY
dbfn_read: key=T:mail.edesix.local:192.168.1.6
dbfn_read: key=T:mail.edesix.local:192.168.1.6:1jiFk5-0006UE-9S
EXIM_DBCLOSE(0x5635b371d370)
closed hints database and lockfile
no message retry record
mail.edesix.local [192.168.1.6] retry-status = usable
192.168.1.6 in serialize_hosts? no (option unset)
delivering 1jiFk5-0006UE-9S to mail.edesix.local [192.168.1.6]
(root@???)
set_process_info: 25033 delivering 1jiFk5-0006UE-9S to mail.edesix.local
[192.168.1.6] (root@???)
192.168.1.6 in hosts_require_dane? no (option unset)
Connecting to mail.edesix.local [192.168.1.6]:25 ... 192.168.1.6 in
hosts_try_fastopen? yes (matched "*")
TFO mode sendto, no data: EINPROGRESS
connected
read response data: size=72
SMTP<< 220 aulus.edesix.com ESMTP Exim 4.80.1 Mon, 08 Jun 2020 13:31:02 +0100
192.168.1.6 in hosts_avoid_esmtp? no (option unset)
SMTP>> EHLO juno.edesix.local

cmd buf flush 24 bytes
read response data: size=134
  SMTP<< 250-aulus.edesix.com Hello juno.edesix.local [192.168.1.10]
         250-SIZE 52428800
         250-8BITMIME
         250-PIPELINING
         250-STARTTLS
         250 HELP
192.168.1.6 in hosts_avoid_tls? no (option unset)

SMTP>> STARTTLS

cmd buf flush 10 bytes
read response data: size=18
SMTP<< 220 TLS go ahead
192.168.1.6 in hosts_require_ocsp? no (option unset)
192.168.1.6 in hosts_request_ocsp? yes (matched "*")
setting SSL CTX options: 0x42004000
Diffie-Hellman initialized from default with 2048-bit prime
Initialized TLS
required ciphers: HIGH:!aNULL:@STRENGTH
192.168.1.6 in tls_verify_hosts? yes (matched "*")
tls_verify_certificates: system
192.168.1.6 in tls_verify_cert_hostnames? yes (matched "*")
Cert hostname to check: "mail.edesix.local"
Setting TLS SNI "mail.dev.edesix.com"
Calling SSL_connect
SSL_connect: before SSL initialization
SSL_connect: SSLv3/TLS write client hello
SSL_connect: SSLv3/TLS write client hello
SSL_connect: SSLv3/TLS read server hello
SSL verify ok: depth=2 SN=/O=Digital Signature Trust Co./CN=DST Root CA X3
SSL verify ok: depth=1 SN=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
LOG: MAIN
[192.168.1.6] SSL verify error: certificate name mismatch:
DN="/CN=*.dev.edesix.com" H="mail.edesix.local"
SSL3 alert write:fatal:internal error
SSL_connect: error in error
TLS error '(SSL_connect): error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed'
TLS session fail: (SSL_connect): error:1416F086:SSL
routines:tls_process_server_certificate:certificate verify failed
SMTP(close)>>
192.168.1.6 in hosts_require_tls? yes (matched "*")
set_process_info: 25033 delivering 1jiFk5-0006UE-9S: just tried
mail.edesix.local [192.168.1.6] for root@???: result DEFER

--
You are receiving this mail because:
You are on the CC list for the bug.