On Fri, Dec 01, 2023 at 09:53:25AM +0100, Alexander Leidinger via Postfix-users
wrote:
> > > Why should it expect reply.github.com?
> >
> > Because that name is securely known from the recipient address.
Because, whether you're willing to understand the point or prefer to
"dig in", verifying a certificate against an attacker-supplied name is
pointless. You gain no security by checking attacker-supplied names.
You want to deposit a bunch of cash into your bank account, I meet you
in a bar wearing a name tag that says I'm the manager of your bank, you
give me a hefty sum of money in cash to deposit into your account...
> If then someone send mails to alexan...@leidinger.net, why should it
> match the hostname against leidinger.net?
Because that's the only name worth verifying, otherwise skip the
potential delivery issues and don't verify.
> My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net,
> and I expect the sending MTA to match the hostname in the MX against the SAN
> of the cert.
An active attacker can replace "your" MX with "send.money.now" for which
he has a handy certificate from Let's Encrypt.
> > The MX hostname is typically obtained via an insecure (subjet to MiTM
> > tampering) DNS lookup, so you lose all security when validating
> > certificates against the payloads of MX records.
>
> You (and the link) are talking about trust.
Really about the futility of going through the motions of verifying
certificates in the absence of trustworthy "reference identifiers".
> I talk about the technical
> operation of establishing a TLS connection and verifying the certificate.
You can go through the motions if you want, but it won't achieve any
security goals.
> The technical problem I have is that postfix seems to use parts of the cert
> store (it validates the MX of FreeBSD, but not the MX of github), whereas
> posttls-finger uses the complete cert store.
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.
> As answered to Wietse, the cert store is readable no permission
> problem, no user access problem, no security polcies, no chroot.
As evidenced by the fact that you got a name matching problem.
> He didn't tell that posttls-finger uses a different
> validation policy than postfix.
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.
Otherwise, it uses default settings, but you have a policy table and
verious "smtp_tls_..." settings, that don't apply to posttls-finger.
> If I understand it correctly: if both have the same access to the cert
> store and the network, they should produce the same result (valid or
> not valid). They don't.
You don't appear to be interested in answers. Rather one gets the
impression you want to make a point. Your point has been made. It
is wrong, but it is clear.
> I want to solve this technical problem and let them both agree, that
> the cert is valid (which it is, the SAN of the MX of github has
> *.smtp.github.com, and this is a match from a certificate validation
> point of view with the hostname the MX presents).
If you want an insecure outcome, just set the destination policy to
"may", or for a false sense of security to "verify". The latter
will match the MX hostname (by default), but the result is pointless,
unless the domain's MX records are DNSSEC-signed, or you've configured
the expected MX hostnames explicitly (using actual names for that
site, not the "hostname" pattern).
> Please tell me what is wrong about:
> - the MX of domain A.c points to a.B.c
You can't in most cases rely on getting that name and not a forgery.
> - a sending MTA has to take a.B.c and match it against the SAN the server
> a.B.c provides (ignoring details of doing a reverse lookup and resolving the
> resulting IP and validating that too)
A sending MTA can just skip going through pointless ceremoy verifying a
name that may be supplied by the attacker...
> In HTTP the name to match against what is provided by the user in the URL,
> in SMTP it is the MX, as the domain part of the email address is not at all
> significant for the name of the MX (see above the Google workspace example).
https://www.postfix.org/TLS_README.html#client_tls_limits
https://datatracker.ietf.org/doc/html/rfc7672#section-1.3
> > No, there's a mismatch between the configuration of your Postfix SMTP
> > client and what you posttls-finger was asked to do.
>
> That's the reason why I come her and ask what I do wrong. I agree that there
> is a difference between the operation of both.
Essentially only as a result of your explicit configuration to make it so.
> What do I have to do to the MTA, to let it agree with the result of
> posttls-finger?
Use "may" as the security level for the destination in your
configuration, and pass "-lmay" as a command-line option to
"posttls-finger".
> Where shall I look for which problem? Which part of my
> config is affecting that and should check for X or provide for inspection?
The policy table.
> > Since delivery was deferred when TLS authentication failed, you were not
> > actually using "may", so the policy table MUST be matching the
> > destination.
>
> You are correct, I overlooked a line in the DB. Connections to github have a
> "secure" policy. This explains why it fails instead of delivering anyway,
> but this is not my concern. What I care about currently is the validation of
> the TLS part of the work postfix has to do.
It should be your concern, unless you're just trying to score points,
rather than solve real problems and learn. :-(
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
