On Sat, Mar 26, 2022 at 12:32:03PM +0530, Vipul Mehta wrote:
> If we consider ECDHE_ECDSA cipher based TLS handshake, then it is possible
> that the client can send invalid public session key to the server causing
> the vulnerability. Is this assumption correct ?
The CVE only affects situations in which the untrusted peer can specify
malign "explicit" curve *parameters*, not just the public point.
> If yes, then I think disabling ECC cipher suites should prevent the
> vulnerability if we don't want to upgrade openssl considering there is no
> other cryptographic operation except w.r.t. TLS.
Unless I'm missing something, there's no need to disable ECC ciphers,
since with TLS 1.0 through 1.2 the curve parameters are chosen by the
server.
With the TLS 1.3, the client typically sends a key share first, which
consists of a named group and again a public point. There is no
mechanism for conveying "explicit" ECC parameters
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8
https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8.2
So either way, TLS servers are safe if they don't solicit client
certificates, or otherwise in some form consume X.509 SPKI public keys
(which with ECC do signal either a named group or provide explicit
parameters).
--
Viktor.
