On 08/12/2022 20:42, 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.
That is arguably a matter of semantics and expectations. At the TCP-and-TLS
level, a TLS startup has not bee done yet (so responding with an encrypted
SMTP failure response isn't possible, and doing a TLS startup just in
order to do so is precisely what we're wanting to avoid. At the SMTP level
it could be argued that connection has not yet completed, so an SMTP response
of any kind is bad. At the application-client level, trying to make a
TLS-on-connect connection and get an (encrypted) banner... it won't be managing
to make the TLS-level connection whether we put anything on the wire
(in plaintext) or not.
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.
> 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").
"unrecognized name" ?
per
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6
at least. That should be used for an SNI mismatch; I don't see that it should be
used for an administrative denial
[
49 access_denied sounds nice, but it's apparently, per RFC 8446,
for "A valid certificate or PSK was received, but when
access control was applied, the sender decided not to proceed with
negotiation." - and we've not even assessed any such validity.
71 insufficient_security might work
]
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".
>
> 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[...]
> Another reason to separate them is, that eg. SNI name and some
> other properties are not available before TLS handshake is finished.
Not so. It's available early and can be used to select the server cert.
So, selecting a nonexistent cert depending on SNI can be done
and will result in no TLS connection.
What other properties?
> 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 ;-)
Since you didn't say, I can't tell...
By "align" I mean "operates before TLS startup".
> 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?
There is an "encrypted=" ACL condition. Or you can check $tls_in_cipher,
as you said - it's fully equivalent.
--
Cheers,
Jeremy
