Dear Viktor,
Thank you for your reply.
Am 23.07.23 um 23:42 schrieb Viktor Dukhovni via Postfix-users:
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.
Ah, sorry for missing to clarify that. My goal is of course to set the
level to *verify* in the future. With so few exceptions, that goal gets
closer and closer. (Also from the legal perspective, without being a
lawyer, I’d say, that actually all German (European) companies are
required to only transmit messages over a verified TLS connection.)
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).
I see your point. No idea, how often these questions come up, but maybe
changing the logging format is not warranted as it might cause other
confusion. Just my two cents, I have no preference.
Kind regards,
Paul
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
