Autor: Odhiambo Washington Data: A: The Doctor CC: Slavko, exim-users Assumpte: Re: [exim] Blocking a Class C
On Fri, Dec 9, 2022 at 9:47 AM The Doctor via Exim-users <
exim-users@???> 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 <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?
>
You can always do a manual compile/ install. That is what I do.
