On Fri, Aug 14, 2020 at 02:30:03PM +0300, Thorsten Habich wrote:
> Another remote MTA which is configured with TA file option, doesn't seem
> to support connection re-use. ("re-using session with untrusted
> certificate, look for details earlier in the log" is not mentioned in
> our logs).
s/connection reuse/session reuse/
> Mail delivery to this MTA frequently fails due to certificate validation
> problems but mails are being delivered on the next attempt.
The real problem is the validation failures on initial handshake,
everything else is a distraction. You have problems delivering to both
servers, but for one (random) recovery happens sooner.
You likely also have had some infrequent unreported issues validating
"secure" destinations without a configured "tafile", that resolve
after the cached session expires.
On Wed, Aug 19, 2020 at 10:52:20AM +0300, Thorsten Habich wrote:
> On 8/14/2020 8:22 PM, Viktor Dukhovni wrote:
> > On Fri, Aug 14, 2020 at 02:30:03PM +0300, Thorsten Habich wrote:
> >
> >> the certificate verification with TA file option still occasionally fails:
> > How is the use of a TA file relevant here?
>
> It only happens with the domains configured with TA file option.
This is relevant, but probably not 100% accurate, likely some domains
also intermittently failed routine CAfile-based validation.
On Thu, Aug 20, 2020 at 04:59:49PM +0300, Thorsten Habich wrote:
> > - Do FAILURES happen ONLY after a session is RESUMED.
>
> Sorry, no. The first connection decides if the problem occurs or not. If
> the session is resumed the error only occurs *if the first connection
> failed*.
>
> If the first connection was successful the error will not appear. The
> status then seem to change in case of a restart (as clarified by Victor
> that clears the session cache) or after I assume
> tlsproxy_tls_session_cache_timeout (default: 3600).
Thats useful information, Thanks.
> 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.
>
> Might there still be a problem?
Yes, try the below patch (Postfix 3.4 and 3.5 only, NOT NEEDED in
earlier releases or in Postfix 3.6 or later).
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
index 7aad011b..91af4d07 100644
--- a/src/tlsproxy/tlsproxy.c
+++ b/src/tlsproxy/tlsproxy.c
@@ -998,7 +998,7 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE
*state)
state->client_start_props->fd = state->ciphertext_fd;
/* These predicates and warning belong inside tls_client_start(). */
if (!tls_dane_avail() /* mandatory side effects!! */
- &&TLS_DANE_BASED(state->client_start_props->tls_level))
+ && TLS_DANE_HASTA(state->client_start_props->dane))
msg_warn("%s: DANE requested, but not available",
state->client_start_props->namaddr);
else
@@ -1427,7 +1427,7 @@ static void tlsp_get_request_event(int event, void
*context)
}
state->appl_state = tlsp_client_init(state->tls_params,
state->client_init_props,
- TLS_DANE_BASED(state->client_start_props->tls_level));
+ TLS_DANE_HASTA(state->client_start_props->dane));
ready = state->appl_state != 0;
break;
case TLS_PROXY_FLAG_ROLE_SERVER:
On Thu, Aug 20, 2020 at 06:32:34PM +0300, Thorsten Habich wrote:
> > I hope you're not still conflating session resumption with connection
> > reuse.
>
> If I got it right, the tlsproxy is only handling the certificate
> validation in case connection_reuse is on, I am actually neither
> assuming a session issue nor a connection reuse issue but somehow an
> issue with the certificate validation in tlsproxy.
OK, just at times too concise/fuzzy in your choice of terminlogy then.
You're forgiven. :-)
--
VIktor.
