Thorsten Habich:
> I increased the log level. Looks like the correct certificate was found
> in the tafile
>
> 2020-06-20T09:38:18.632247+02:00 servername postfix/tlsproxy[17324]:
> mail.somedomain.net[10.11.12.13]:25: depth=1 matched trust anchor
> certificate sha512 digest
> 2020-06-20T09:38:18.632323+02:00 servername postfix/tlsproxy[17324]:
> mail.somedomain.net[10.11.12.13]:25: depth=0 trust-anchor certificate
> 2020-06-20T09:38:18.632396+02:00 servername postfix/tlsproxy[17324]:
> mail.somedomain.net[10.11.12.13]:25: depth=1 verify=0
> subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
I did some further experiments, with posttls-finger and an explicit
trust anchor, fixed the problem, and certificate verfication now
works.
Demo: on a non-DNSSEC host, use "posttls-finger -X " for force
tlsproxy usage, and specify the remote SMTP server's server's own
self-signed certificate as the trust anchor.
# posttls-finger -X -A spike.porcupine.org.pem -l secure spike.porcupine.org
posttls-finger: Connected to spike.porcupine.org[168.100.189.2]:25
posttls-finger: < 220 spike.porcupine.org ESMTP Postfix (3.6-20200610)
posttls-finger: > EHLO wzv.porcupine.org
posttls-finger: < 250-spike.porcupine.org
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-SIZE 52428800
posttls-finger: < 250-ETRN
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-SMTPUTF8
posttls-finger: < 250 CHUNKING
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: spike.porcupine.org[168.100.189.2]:25:
subject_CN=spike.porcupine.org, issuer_CN=porcupine.org,
fingerprint=DE:DA:83:61:79:C1:1D:E1:3F:F0:F5:A7:CF:84:FF:AD:85:6B:3A:9B,
pkey_fingerprint=23:38:29:6E:29:0F:93:FC:A1:70:8F:9D:B3:A6:E8:9B:51:F6:F1:A1
posttls-finger: Verified TLS connection established to
spike.porcupine.org[168.100.189.2]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
RSA-PSS (2048 bits) server-digest SHA256
. . .
Below are the bug summary and patch.
Wietse
20200620
Bugfix (introduced: Postfix 3.4): SMTP over TLS connection
reuse was broken for configurations that use explicit trust
anchors. Reported by Thorsten Habich. Fixed by calling DANE
initialization unconditionally (WTF). File: tlsproxy/tlsproxy.c.
diff '--exclude=man' '--exclude=html' '--exclude=README_FILES'
'--exclude=INSTALL' '--exclude=.indent.pro' -r -ur
/var/tmp/postfix-3.6-20200610/src/tlsproxy/tlsproxy.c src/tlsproxy/tlsproxy.c
--- /var/tmp/postfix-3.6-20200610/src/tlsproxy/tlsproxy.c 2020-05-15
09:29:14.000000000 -0400
+++ src/tlsproxy/tlsproxy.c 2020-06-20 14:55:59.216357419 -0400
@@ -997,12 +997,12 @@
state->client_start_props->ctx = state->appl_state;
state->client_start_props->fd = state->ciphertext_fd;
/* These predicates and warning belong inside tls_client_start(). */
- if (!TLS_DANE_BASED(state->client_start_props->tls_level)
- || tls_dane_avail())
- state->tls_context = tls_client_start(state->client_start_props);
- else
+ if (!tls_dane_avail() /* mandatory side effects!! */
+ &&TLS_DANE_BASED(state->client_start_props->tls_level))
msg_warn("%s: DANE requested, but not available",
state->client_start_props->namaddr);
+ else
+ state->tls_context = tls_client_start(state->client_start_props);
if (state->tls_context != 0)
return (TLSP_STAT_OK);
