Viktor Dukhovni wrote in
<20200825160538.gt37...@straasha.imrryr.org>:
|On Tue, Aug 25, 2020 at 04:56:26PM +0200, Steffen Nurpmeso wrote:
|> Emmanuel Fusté wrote in
|> <ca89a3dc-097f-3b35-481c-6d5d3463a...@external.thalesgroup.com>:
|>|Le 24/08/2020 à 21:14, Steffen Nurpmeso a écrit :
|>|> Something else, maybe.
|>|> I do not understand why my (stupid) config
|>|>
|>|> smtpd_sender_restrictions =
|>|> check_ccert_access hash:/etc/postfix/relay_clientcert,
|>|> permit_tls_clientcerts,
|>|> reject_unknown_sender_domain,
|>|> #reject_sender_login_mismatch,
|>|> permit_sasl_authenticated,
|>|> reject
|>|>
|>|> succeeds only if reject_sender_login_mismatch is commented out
|>|> _unless_ i pass a valid client certificate. I.e., even if
|>|> anything is ok except for with/out client certificate:
|>
|>|Just for this part : what is your content of the map configured by
|>|smtpd_sender_login_maps ?
|>
|> I am confused. That makes no sense. To reiterate, if i pass
|> a valid client certificate check_ccert_access matches, the rest of
|> the chain is skipped, but SASL authentication is still performed,
|> permit_sasl_authenticated still matters! If i do not pass a valid
|> client certificate, reject_sender_login_mismatch triggers because
|> .. but the map is empty! Also for this test the order of the
|> chain cannot matter, because SASL authentication happens later.
|> Whatever. Note the error happens after authentication was
|> reported as being successful.
|
|What you're actually confused about has little to do with client certs
|and to some extent SASL.
|
|First and foremost you need to understand that a "permit" action in the
|sender restrictions is NOT final, it just short-circuits the *sender*
|restrictions, the rest of restrictions, and in particular the "relay"
|and "recipient" restrictions are still processed.
I have to think about that. These at least do not include SASL.
|Therefore, the "check_ccert_access" you actually care about is the one
|in "smtpd_relay_restrictions" and/or "smtpd_recipient_restrictions".
That is only as above. :)
|Your other point of confusion is that you're imagining that the
|restriction processing determines the SMTP protocol control flow, such
|that SASL authentication only happens when "permit_sasl_authenticated"
|or similar is evaluated.
|
|In fact, by the time (especially smtpd_delay_reject=yes, the strongly
|recommended default) that the restriction processing is happening, the
Ah!
|SASL authentication handshake is long in the past. It happens
Indeed.
|because:
|
| 1. The server indicated support for SASL in its EHLO response.
| 2. The client chose to perform SASL auth.
|
|If you want clients to skip SASL auth, configure them to not use
|SASL auth (no passwords, no EXTERNAL, just a client cert).
That does not work. Oh. Yes, it does!
? set smtp-config=-auth
? mail root@localhost
...
s-nail: >>> STARTTLS
s-nail: >>> SERVER: 220 2.0.0 Ready to start TLS
s-nail: TLS: applying config: MinProtocol = TLSv1.3
s-nail: TLS: applying config: Certificate = /tmp/kdcc.pem
s-nail: TLS: applying config: PrivateKey = /tmp/kdck.pem
...
s-nail: >>> EHLO kdc.localdomain
...
s-nail: >>> SERVER: 250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5 XOAUTH2
OAUTHBEARER EXTERNAL GSSAPI
...
s-nail: *smtp-config*: using pipelining extension
s-nail: >>> MAIL FROM:<steffen@kdc.localdomain>
s-nail: >>> RCPT TO:<root@localhost>
s-nail: >>> DATA
s-nail: >>> SERVER: 250 2.1.0 Ok
s-nail: >>> SERVER: 250 2.1.5 Ok
s-nail: >>> SERVER: 354 End data with <CR><LF>.<CR><LF>
...
s-nail: >>> QUIT
s-nail: >>> SERVER: 250 2.0.0 Ok: queued as E076C40547
|The protocol flow is:
...
| 250 AUTH PLAIN GSSAPI ...
| C: !!! chooses to perform or skip SASL !!!
| --- possible SASL handshake here ---
Yes, but, you know, _if_ the server announces AUTH then of course
any automatic software will choose AUTH! Because, why would the
server announce AUTH if it would not need it?
This does not make sense!
There are clients which do not even allow users to fine-tune the
authentication mechanism which is used! In fact, last years
thread on this ML caused that widely used MUA (i have forgotten)
to actually implement that possibility!! (The lengthy bugzilla or
whatever forum threads will show this. Thinkable also that the
respective people are (still) on this list and read this even.)
I would presume that the _sole_ reason why postfix have had no(t
much bigger) problems with EXTERNAL SASL is that it is likely that
EXTERNAL is not chosen automatically. This is what my MUA will do
with the next minor release
auth Authentication (RFC 4954) allows account credentials to be
passed. This word disables all authentication mechanisms,
but enables only those which can be managed automatically
without external help; for example GSSAPI requires an exter‐
nally granted ticket to exist, and is therefore excluded by
the default automatic selection, as is EXTERNAL etc.: these
mechanisms have to be enabled explicitly. The default selec‐
tion depends upon the (im- or explicit) presence of TLS.
Automatic selection of EXTERNAL would be doable if there would be
a client_certificate= configuration option, however. But we avoid
any intermediate code, and call SSL_CONF_cmd(3) with the user
strings directly, if that is available. (Otherwise not,
unfortunately.)
| C: MAIL FROM:<sender> BODY=8BITMIME SIZE=...
| S: 250-OK
| C: RCPT TO:<recipient> ORCPT=...
| S: --- evaluates *ALL* restrictions here! ---
| client restrictions -- might look at cert or SASL login
| helo restrictions -- might look at cert or SASL login
| sender restrictions -- might look at cert or SASL login
| recipient restrictions -- might look at cert or SASL login
| relay restrictions -- might look at cert or SASL login
That is very interesting to know!
| S: 250 OK (or 5XX go spam someone else)
| C: DATA
| S: ---- evaluates data restrictions here -- might look at cert \
| or SASL login
| 354 Go ahead (or 5XX go spam someone else)
| C: <message body>
| .<CRLF>
| S: ---- evaluates end of data restrictions here -- might look at \
| cert or SASL login
| S: 250 OK (or 5XX go spam someone else)
| C: QUIT
| S: 221 Goodbye
|
|With this in mind, you'll have an easier time to understand where
|SASL and client certs fit into the picture.
Absolutely! The above should really be part of the documentation,
from my shallow reading i was very undecided what to put where,
especially with the diversification that postfix had introduced
(was it relay and recipient?), and that with my simple
configuration!
|The relative order of the relay and recipient restrictions is somewhat
|in flux at the moment, it changed in Postfix 3.3, but the docs have
(Must be that, then.)
|not caught up, and I hope it will change again 3.6, provided you set
|the compatibility level high enough. But this is unlikely to matter
|terribly much in most cases.
Very helpful!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
