Am 2023-12-01 11:22, schrieb Viktor Dukhovni via Postfix-users:
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...
This is not a problem which can be solved in a purely technical manner for SMTP in an automated way (= deploy this new MTA and it works). It needs an incompatible redesign of sending "email" with the buy-in of the world. I'm well aware of that.
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 SANof the cert.An active attacker can replace "your" MX with "send.money.now" for whichhe has a handy certificate from Let's Encrypt.
Yes. I'm fully aware of that. TLS in SMTP can not make sure it delivers to the person I intended it to be delivered to. It also doesn't make sure nobody else than the recipient is able to read the mail. The same way a snail mail can not prevent someone from intercepting the envelope, and having a look inside. But like a double-envelope in snail mail, TLS is able to prevent a bystander (e.g. my ISP) besides the post-delivery-person to have a peek at what is written (like the difference between a postcard and a letter in an envelope).
> 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".
An attacker has to go through a lot of hops to break DNSSEC to make a man in the middle attack (yes, github is not DNSSEC protected, leidinger.net isn't either). There are cases where it is good enough for my use case. For my use case with github, I do not depend on validating the authenticity of the remote host. I'm even not depending on the privacy feature of TLS in terms of github.
I talk about the technicaloperation 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.
Not with github. I fully agree. With github it was about the technical issues I wanted to understand and solve (and it is solved now, see below).
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), whereasposttls-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.
Great to know. I didn't before you told me. Can I suggest to add this information to the TLS readme?
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.
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. 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. 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?
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 was under the wrong assumption that posttls-finger may have a look at my postfix config. It makes sense it doesn't, but it would also makes sense it would do it. Both are valid view points. I understand now that it doesn't have a look at the config. Just because the man page of posttls-finger is not clear enough for me (no matter if I made wrong assumptions, expected too much from it, overlooked a little detail, or whatever), it doesn't mean I'm not interested in answers. Just because you make assumptions about what I try to accomblish which may or may not match my intentions, it doesn't mean I'm not interested in answers.
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).
With the help from some private reply, I got postfix to this point (verify instead of secure) before I've read this answer. Together with my experiment with "-l" with posttls-finger, this provides me now with the understanding why the TLS error showed up in the postfix log, and why posttls-finger succeeded. I have now both applications configured so that they agree.
Please tell me what is wrong about: - the MX of domain A.c points to a.B.cYou can't in most cases rely on getting that name and not a forgery.
I know.
- 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 theresulting 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...
If your concern is an attacker impersonating the MTA: I agree.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. 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.
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 thereis a difference between the operation of both.Essentially only as a result of your explicit configuration to make it so.
The final outcome is that an automation has filled the mysql table with this policy. This automation did the wrong thing for my intend. I was trying to figure out what kind of technical option was responsible for the failure to fix the issue. After wading through the TLS readme and the man page of posttls-finger, and trying things on my own, I was coming here to understand the technical details of what leads to this result, as I was obviously not noticing the important parts in the docs and making some wrong assumptions about some of the parts which weren't documented in a way that a non-native english speaker would draw the right conclusions. Thanks for finally coming down to the technical details in this mail after a lot of non technical stuff. I think I have now a better understanding of the technical details involved here.
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".
From a technical point of view, "-l verify" works too. This is a pure technical point of view, and is othogonal to a policy based view if this makes sense for the desired security policy (or what the security policy is).
Where shall I look for which problem? Which part of myconfig 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 ofthe 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. :-(
No need to being rude. No, I didn't try to score points (the MTA in question is not subject/depending to/on checkmark security, external security certifications or similar). And yes, my concern was to learn something. But not what you wanted to teach me. Sorry if this disappoints you. I don't need to be teached that a non DNSSEC protected domain can not be trusted in terms of the results of a MX lookup. I know that since a long time. No need to teach me that validaing the cert is pointless in this case, as an attacker may provide a valid letsencrpyt cert. I know that. None of this was my problem. If my problem of not understanding the technical details which lead to not verifying the hostname and my interest to learn about the technical reasons is not a real problem for you, you shouldn't have felt obliged to answer to my mail.
Now that I understand the technical details, the priority of having mails delivered raised and I solved this with the information provided in a private reply, and now by you here in public too. Thanks again for the technical details which raised my understanding of what is going on internally in postfix by a little bit.
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
