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@exim.org> 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 doc...@nk.ca Ici doc...@nk.ca 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
