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@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.
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
--
## 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/
