Hi all,
Robert has mentioned https://nvd.nist.gov/vuln/detail/CVE-2021-3449 on
the -security list where a TLS server could crash with some crafted
renegociation message. We already disable SSL renegociation
initialization for some time now, per 48d23c72, but we don't prevent
the server from complying should the client wish to use renegociation.
In terms of robustness and because SSL renegociation had its set of
flaws and issues for many years, it looks like it would be a good idea
to disable renegociation on the backend (not the client as that may be
used with older access points where renegociation is still used, per
an argument from Andres).
In flavor, this is controlled in a way similar to
SSL_OP_NO_COMPRESSION that we already enforce in the backend to
disable SSL compression. However, there are a couple of compatibility
tweaks regarding this one:
- SSL_OP_NO_RENEGOTIATION controls that. It is present in OpenSSL >=
1.1.1 and has been backported in 1.1.0h (it is not present in older
versions of 1.1.0).
- In 1.0.2 and older versions, OpenSSL has an undocumented flag called
SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS, able to do the same as far as I
understand.
Attached is a patch to use SSL_OP_NO_RENEGOTIATION if it exists, and
force that in the backend. We could go further down, but using
undocumented things looks rather unsafe here, to say the least. Could
there be a point in backpatching that, in light of what we have done in
48d23c72 in the past, though?
Thoughts?
--
Michael
