On Thu, Dec 08, 2022 at 08:42:46PM +0000, Slavko via Exim-users wrote:
> 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
>
Looks like a fix for 4.97 .
I still wonder why the FReeBSD porters never went up to 4.96?
--
Member - Liberal International This is doctor@??? Ici doctor@???
Yahweh, King & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism
https://www.empire.kred/ROOTNK?t=94a1f39b
Happy Christmas 2022 and Merry New Year 2023 Beware
https://mindspring.com
