On Fri, Dec 9, 2022 at 9:47 AM The Doctor via Exim-users < [email protected]> wrote:
> 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 <[email protected]> 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? > You can always do a manual compile/ install. That is what I do. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) -- ## 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/
