On Sun, Jul 23, 2023 at 11:22:26PM +0200, Paul Menzel wrote:
> > Does it really matter why some site offering opportunistic STARTTLS does
> > not have a validatable certificate? The connection can be trivially
> > downgraded by an on-path attacker (stripping STARTTLS) to just be
> > cleartext. Or the MX records could be forged (absent DNSSEC).
>
> As these are only a few, I’d take up the task of contacting these
> postmasters, so having the reason at hand would ease that task. Doing
> this manually, these steps would be done later, where the setup could
> change, and the result/behavior might be different. So having the reason
> at hand would also make it easier to clear up these situations.
My point is that even the sites that are logged as "Trusted" are not
fully validated (no hostname checkes are attempted or even entirely
possible, given insecure MX indirection). With "Trusted" easily
downgraded. What is the point of caring whether the MX host did or not
present some random certificate from some random CA in your CA bundle?
What actual problem are you solving? I don't see any value in
certificate chain trust validation for its own sake, if no real security
goals are met as a result.
> > If you choose to use the unsupported (therefore not subject to Postfix
> > stability guarantees) "smtp_tls_loglevel = certmatch, summary" setting,
> > the additional lines are logged for every TLS handshake involving
> > certificates, not just those that are "Untrusted".
>
> We build Postfix ourselves. If somebody has a (hackish) patch to achieve
> this, we could add it to our installation.
I don't recommend attempting such a patch. If you *strongly* want the
extra logging, just accept it even for valid connections.
> > The "certmatch" logging becomes more succinct when raw public keys are
> > supported and used by the peer. Line 1 shows the public key details,
> > and line 2 the usual summary (signalling RPK use in a comment for the
> > server signature). The "-x" flag would turn off mandatory X.509,
> > enabling use of raw public keys.
> >
> > $ posttls-finger -x -F /etc/ssl/cert.pem -c -Lcertmatch,summary
> > -lmay -o 'tls_medium_cipherlist = DEFAULT' dnssec-stats.ant.isi.edu
> > 1 -> posttls-finger:
> > dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: raw public key
> > fingerprint=B1:E7:FA:AF:6E:48:2E:2A:FB:C6:53:C8:E3:B6:BE:F0:E3:35:24:24:AE:BD:24:D2:B4:80:09:29:51:BC:60:97
> > 2 -> posttls-finger: Untrusted TLS connection established to
> > dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25: TLSv1.3 with cipher
> > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature
> > RSA-PSS (2048 bit raw public key) server-digest SHA256
>
> It sounds interesting, but unfortunately, I have no idea about raw
> public keys. I quickly read the introduction of the RFC 7250 [1], but do
> not understand yet, why it shows *Untrusted* in your example, and how
> it’d would solve my original problem.
It does not solve your "original problem", this is just a caveat to let
future readers know that the logging from "certmatch" may become a
one-liner in some configurations that with cause don't care much about
certificates, when they aren't used to ensure connection security.
In fact, enabling raw public keys would take you further away from your
puzzling goal of logging certificate trust chain validity issues (for
certificates that may or may be legitimately for the host that you
expect to connect to, which may or may not be the legitimate MX host
of the destination domain).
Perhaps for "opportunsitic" TLS connections we should stop routine and
largely futile logging of whether the chain is "Trusted" or "Untrusted",
to avoid encouraging users to try to read the tea-leaves?
The summary log message for unauthenticated connections (may, encrypt or
dane in the absense of TLSA records) might then take the form:
TLS connection established
to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bit raw public key)
server-digest SHA256
And then, all temptation to fix "problems" with sites whose certificate
trust chains are "invalid" go away.
The trust status would then only be logged for destinations that require
connection security (fingerprint, dane with TLSA, verify or secure).
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
