Sebastian Nielsen via Exim-users <exim-users@???> (Fr 06 Sep 2019 20:50:37 CEST):
> Shouldn't this be in connect ACL?
> How would the deny in MAIL FROM prevent the exploit? What I have understand is that there is exploit in the SNI of the TLS negotiation, thus the whole connect attempt must be rejected right?
>
The variables are available *after* the TLS negotiation is done.
For TLS-on-connect (mostly port 465) I suppose, the HELO ACL will have
them already. (Not the CONNECT ACL, since it is triggered right after
the TCP connect, IMHO - but about that fact I'm not sure, I need to read
the source or the docs.)
The STARTTLS ACL isn't a good candidate too, as it is called right after
receiving the STARTTLS command - so, no handshake yet.
The HELO ACL doesn't help either, as the first EHLO comes before
STARTTLS, and the second EHLO doesn't have to come, the client may send
EHLO
<--- 250
STARTTLS
<--- 220
MAIL FROM
<--- 250
So from what I understand, the MAIL FROM is the first point, where we
can kick in and theck the SNI and the peer's CN.
Yes, you *could* check it in the HELO ACL, but as you can't rely on the
2nd EHLO you need to check in the MAIL ACL anyway.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
