Dňa 8. decembra 2022 14:33:01 UTC používateľ Jeremy Harris via Exim-users <exim-users@???> napísal:
>For those, use the main-config option "host_reject_connection" rather than the
>connect ACL - it operates before the TLS startup for TLS-on-connect ports,
>while the ACL is run after.
>
>I'm considering changing that, even though it's an incompatible change.
>Having the ACL operate before TLS startup (for TLS-on-connect) would align
>with the operation for STARTTLS, and possibly cause less surprise.
>Anybody want to comment?
Yes, i want, if i can, as i know nothing about exim's internals and very
little about TLS, and if my English allow me it ;-)
If i properly understand you, you want to move current "connect" ACL
to be handled before TLS handshake happens. I see that problematic,
not by implementation (i know nothing about it), but with results:
We was talk about this some time ago on IRC, if you remember... You
mentioned, that currently the "host_reject_connection" returns to client
plaintext response... I understand, that this is "historic", but Ii hope that
you will agree, that this is wrong, at least because clients will not
expect plaintext on encrypted connection. Yes, we can consider
those rejected at connect stage as bad and ignore them. But despite
this, we have to respond correctly, as we have to considef misconfigured
clients rather than malicious. Plain response is OK before STARTTLS
was issued, but with TLS-on-connect connection we have either
silently close connection or issue some TLS error. I do not know what
is proper to reject TLS handshake, but i hope that here are people
who know. Or, we can inspire eg. from nginx's solution of rejecting TLS
handshake (BTW, openssl s_client returns it as "alert number 112").
Thus, we have to distinguish connection type (plain/TLS) to choose
appropriate rejection. IMO, better can be to add separate ACL, which
will be called before current connect ACL, but only on TLS-on-connect
ports. Its semantic have to be simmilar to connect ACL, but with defer
either not allowed or treated the same as deny/drop. Simillar with
the message modiffier (ignore/not allow). If i can, i will vote for
allowing both.
Another reason to separate them is, that eg. SNI name and some
other properties are not available before TLS handshake is finished.
Yes, it can be checked latter, but checking at connect stage can
save some possibly not cheap queries in latter ACLs. Checking
SNI in current connect ACL is very effective...
One thing, which is not clear for me, is what you mean by
"align with the operation for STARTTLS", i hope that it is not
what i understand ;-)
And when we are talking about TLS, i consider as useful to allow
encrypted condition in both, the connect and helo ACLs, to one
can distinguish encrypted connections there (now one have to check
eg. $tls_in_cipher variable). Please, can it be added?
regards
--
Slavko
https://www.slavino.sk/
