Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=3035

--- Comment #4 from ivanov17 <ivanov17@riseup.net> ---
????

--
You are receiving this mail because:
You are on the CC list for the bug.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3035

Andrew Aitchison <exim@aitchison.me.uk> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |exim@aitchison.me.uk

--- Comment #5 from Andrew Aitchison <exim@aitchison.me.uk> ---
> ????

> The SSL_OP_NO_EXTENDED_MASTER_SECRET and
> SSL_OP_IGNORE_UNEXPECTED_EOF options were added in OpenSSL 3.0
> https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html

SSL_OP_NO_EXTENDED_MASTER_SECRET exists to block use of RFC7627
which allows the "secure" in "secure renegotiation".
So this option *forces* *insecure* renegotiation.

For SSL_OP_IGNORE_UNEXPECTED_EOF that page says:
You should only enable this option if the protocol running over TLS
can detect a truncation attack itself, and that the application is
checking for that truncation attack.
Presumably Exim is not checking for that attack
- assuming that is possible in SMTP.

> I think it would also be useful to support the
> SSL_OP_ALLOW_CLIENT_RENEGOTIATION option, which enables
> client-initiated renegotiation, since it is disabled by default.
> It seems it was also introduced in Openssl 3.0.

Renegotiation (even secure renegotiation) is obsolete.
TLS1.3 does not support it.

Properly supporting renegotiation would require Exim to revert its state
to what it was before the previously negotiated "session security upgrade".
I don't know whether anyone has worked out what that would mean,
but we have had previous cases (eg STARTTLS) where insecure information
has been trusted by accident.

Your logs show instances where the secure connection failed.
Do you know that these were legitimate attempts at connection,
rather than attackers seeing what they could get away with ?

Also, OpenSSL disables these features by default.
Why should Exim think it knows better than OpenSSL about the details of TLS ?

--
You are receiving this mail because:
You are on the CC list for the bug.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/