Re: [exim] Blocking a Class C

Góra strony
Delete this message
Reply to this message
Autor: Slavko
Data:  
Dla: exim-users
Temat: Re: [exim] Blocking a Class C
I am sorry for delay...

Dňa 8. decembra 2022 21:37:32 UTC používateľ Jeremy Harris via Exim-users <exim-users@???> napísal:

>We could just drop the connection at the TCP level, silently; that wouldn't
>be hard to code. I don't think it'd make any difference to a client
>that didn't have a human peering at a packet capture of the connection
>attempt.


Drop silently is what i suggested and have "human" on remote side is
IMO expected on SubmissionS connections.

>"unrecognized name" ?


Yes, perhaps not good example, as that was TLS handshake rejected
from name base virtual server, there are other names which responds
to HTTPS in it... I have not opposite example -- rejecting by default, but
accepting on some names.

>71 insufficient_security might work


I cannnot comment, my knowledge is not enough, but looks OK.

>But sending anything complex enough to need the TLS library sounds like
>too much hard work. I don't think either supported library provides
>a simple way of "start the handshake and intentionally cancel it".


While i do not know how it is implemented in library, i will guess that
there is something, at least in OpenSSL. I remember that i read some
bugreport in nginx with that TLS handshake rejection and there was
mentioned some problem inside library too (both solved now), but i
never really wrote in C, nor directly used OpenSSL lib, thus i didn't read
details carefuly. I have no links noted...

>Not so. It's available early and can be used to select the server cert.


AFAIK SNI is part of TLS Client Hello. For now i understand that we
are talking about rejection before TLS handshake starts, thus no
SNI is available (nor other TLS related variables). Are you talking
about rejection in "middle" of TLS handshake or even after it is
finished?

>> 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 ;-)
>
>By "align" I mean "operates before TLS startup".


I was understanding that as common ACL for both, now it is clear.

>There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
>as you said - it's fully equivalent.


When i recently tried to use "encrypted=" ACL condition in helo ACL
i got error, thus while fully equivalent, they are not interchangable
in all related ACLs and it was not documented.

regards


--
Slavko
https://www.slavino.sk/