On Mon, Sep 25, 2023 at 04:24:55PM +0200, Patrick Ben Koetter via Postfix-users
wrote:
> > Do you have SMTP client TLS connection reuse enabled? If so, TLS
> > connections are made via tlsproxy(8), with the smtp(8) client
> > unaware of any initialisation issues until STARTTLS.
>
> Well spotted and that was the reason Postfix failed. We've added a SELinux
> policy to let tlsproxy do what it wants and things went back to normal.
Thanks for the confirmation. I feel some pride in intuiting the cause
in this case, the link with the reported symptoms was fairly subtle.
> Also: As of today list.sys4.de offers and uses RSA *and* ECDSA certificates.
> TLSA RRs had been extended before we activated the new certs.
No worries, I trust you'll be able to manage the TLSA records
accordingly, and have monitoring in place that tests both algorihtms.
> > If you also have TLS client certs configured (typically without just
> > cause) to be sent to servers that happen to request them (also typically
> > without just cause), then a failure to load the client certs breaks TLS
> > support in tlsproxy(8), which makes all attempts at "STARTTLS" fail.
>
> Yes, list.sys4.de also uses TLS client certs and I'm not really sure I like
> you writing "typically without just cause". I'd rather have it the other way
> around and be irritated if clients do not identify themselves in TLS sessions
> as well. But then this leads to another discussion about mutual DANE-based
> identification where the client side need to identify itself to a
> DANE-verifying server as well.
Well, very few servers will actually request the client certificates, so
you can configure them to your heart's content, but they'll almost never
be sent. The few servers that do ask, won't in practice know what to do
with them. So, unfortunate as it may seem, they just increase
opportunities for failure, without adding anything by way of security.
> > The best solution is [to] configure client certs *sparingly*, only
> > for transports dedicated to destinations that definitely need the
> > client certs, and not otherwise.
>
> Why? I feel a little like I was feeling in the early 2000s when we had
> to justify offering STARTTLS on the server side. IMHO TLS should be
> default on both ends and any service not complying should need to
> explain why.
Client certificates serve no purpose unless the server requests them and
knows what to do with them. That's pretty much just:
- submission servers that use client certs instead of passwords.
- dedicated mail store servers that restrict delivery (or skip
spam filters, ...) to just authorised sources.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
