Am 2023-12-01 18:51, schrieb Viktor Dukhovni via Postfix-users:
On Fri, Dec 01, 2023 at 01:52:19PM +0100, Alexander Leidinger wrote:> No. The problem you're reporting is with name matching. If the > certificate chain failed to be constructed, that'd be reported instead. > You'll only see name match errors if the chain construction succeeds, > but the peer name matching fails. Great to know. I didn't before you told me. Can I suggest to add this information to the TLS readme?That would Postfix documenting OpenSSL library behaviour, and is not something we can promise as a stable Postfix feature. It just so happens that OpenSSL first builds a chain, and then verifies various conditions. Perhaps building the chain first is unavoidable, because that can bring in name constraints, or other limitations that make the leaf certififate invalid. So this is unlikely to change, but is not something Postfix implements or influences.
But it's something postfix uses and it would be possible to tell that at the time of writing the docs, this is the behavior and that this is something which is not controlled by postfix but openssl. The info this would provide is very valuable to understand at which level the problem happens (in this case the chain was ok, but the hostname didn't match the expectation). In an ideal world, postfix would even print the info that this is because of the "secure" policy and that the lower "verify" policy would have resulted in success.
> The "postls-finger" program will default to "dane" or (absent DANE TLSA > records) "secure", rather than "may" in order to improve your odds of > meaningfully testing the remote cert chain.github is not DNSSEC protected, as such - if I understand the TLS readme correctly, postfix will not use DANE. As such I assume, posttls-finger willnot use DANE too.Correct. Therefore "posttls-finger" will use the "secure" level, and its matching policy:
This doesn't match my testing. See below.
The tls policy for github.com was secure in postfix, but I may have overlooked what posttls-finger is doing if there is no dane record. Byexperimantation I now think it is falling back to "verify" in that case.Actually "secure", which means that the match strategy is "nexthop:dot-nexthop" unless you specify additional command-line arguments to override the match list. switch (state->level) { case TLS_LEV_SECURE: state->match = argv_alloc(2); while (*argv) argv_add(state->match, *argv++, ARGV_END); if (state->match->argc == 0) argv_add(state->match, "nexthop", "dot-nexthop", ARGV_END); break; case TLS_LEV_VERIFY: state->match = argv_alloc(1); while (*argv) argv_add(state->match, *argv++, ARGV_END); if (state->match->argc == 0) argv_add(state->match, "hostname", ARGV_END); break; case TLS_LEV_FPRINT: state->dane = tls_dane_alloc(); while (*argv)tls_dane_add_fpt_digests(state->dane, state->options.enable_rpk,*argv++, "", smtp_mode); break; ...
This would suggest that no -l option should show the same behavior than "-l secure". This is not the case for the situation I tested (no DNSSEC for github, as such DANE can not be used, and the default of "secure" should print "Untrusted" instead of "Verified"):
---snip--- # posttls-finger -c -P /etc/ssl/certs reply.github.composttls-finger: in-5.smtp.github.com[140.82.113.31]:25: matched peername: *.smtp.github.com posttls-finger: in-5.smtp.github.com[140.82.113.31]:25: subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020 CA1, fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B, pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48 posttls-finger: Verified TLS connection established to in-5.smtp.github.com[140.82.113.31]: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
# posttls-finger -c -l secure -P /etc/ssl/certs reply.github.composttls-finger: server certificate verification failed for in-7.smtp.github.com[140.82.114.31]:25: num=62:hostname mismatch posttls-finger: in-7.smtp.github.com[140.82.114.31]:25: subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020 CA1, fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B, pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48 posttls-finger: Untrusted TLS connection established to in-7.smtp.github.com[140.82.114.31]: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
---snip---
At least the output between "-l may", "-l secure" and "-l verify" lead me to this assumption. May I suggest to add a comment to the man page of posttls-finger in this regard?The manpage is sadly long, but this is document per above.
It is even documented in the beginning, but it doesn't match the test case above.
I was under the wrong assumption that posttls-finger may have a look at mypostfix config.It does read main.cf, but it does not use the smtp(8) delivery agent settings. It uses base network and TLS settings. Perhaps there could be a switch that asks posttls-finger to "adopt" "smtp_tls_mumble" settings, but that's not the case now.
I think this is a good idea.
If your concern is privacy as an ideology and you assume it would be too costly to put a man in the middle into your communication: Maybe, maybe not.The "may" security level is sufficient for protection against passive monitoring. Certificate checks are not needed for that. They are only useful for fending off active attacks, in which case one should also include MX record forgery in the threat model.
The internet is not a static place. Once a site enables DNSSEC, validating the certificate immediately results in authentication and not only privacy. Using "verify" instead of "may" for such cases future-proofs the config in this regard. As I said, it may or may not make sense, but this doesn't depend on you or me, but the threat model and other stuff.
Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
