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.
> > 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 will
> not use DANE too.
Correct. Therefore "posttls-finger" will use the "secure" level, and
its matching policy:
-l level (default: dane or secure)
The security level for the connection, default dane or secure
depending on whether DNSSEC is available. For syntax and
semantics, see the documentation of smtp_tls_security_level.
When dane or dane-only is supported and selected, if no TLSA
records are found, or all the records found are unusable, the
secure level will be used instead. The fingerprint security
level allows you to test certificate or public-key fingerprint
matches before you deploy them in the policy table.
Note, since posttls-finger(1) does not actually deliver any
email, the none, may and encrypt security levels are not very
useful. Since may and encrypt don't require peer certificates,
they will often negotiate anonymous TLS ciphersuites, so you
won't learn much about the remote SMTP server's certificates at
these levels if it also supports anonymous TLS (though you may
learn that the server supports anonymous TLS).
However, because posttls-finger is not the smtp(8) delivery agent, it
does not use any of the "smtp_tls_..." parameters. Instead it uses only
the "tls_..." parameters and base main.cf parameters such as
"inet_protocols", ... The rest is via a kitchen sink of command-line
options (starting to run out of single letters, and we don't yet have
"long option" support).
> 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. By
> experimantation 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;
...
> 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.
> I was under the wrong assumption that posttls-finger may have a look at my
> postfix 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.
> 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.
> Security is not a fixed set of actions, and what a security issue may
> be in on place may not be a concern in another place. Security has
> multiple faces and meanings depending on what you try to accomblish /
> what your thread model is.
Indeed, see for example: https://datatracker.ietf.org/doc/html/rfc7435
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
