4 ms·

So if I understand it correctly, the impact of these two "high" vulnerabilities is: - if you use the non-default X509_V_FLAG_X509_STRICT flag and use the new o

by lucb1e 6y ago

So if I understand it correctly, the impact of these two "high" vulnerabilities is: - if you use the non-default X509_V_FLAG_X509_STRICT flag and use the new openssl 1.1.1h feature to "disallow certificates in the chain that have explicitly encoded elliptic curve parameters" and configure a custom "purpose" value in your software then this second feature (disallowing explicit curve params) was ineffective, or - if you run a TLS1.2 server and renegotiation is enabled then someone can craft a packet that will crash the server (e.g. Nginx disabled renegotiation in 2009 and seems thus unaffected).

pjungwir 6y ago
> this second feature (disallowing explicit curve params) was ineffective Not quite. It would override the previous check about being signed by a valid CA. I imagine the implementation was something like this: is_valid = true; is_valid &= signed_by_valid_ca(cert); if (check_x509_strict) { is_valid = !has_explicitly_encoded_curve_params(cert); } is_valid &= some_other_test(cert); is_valid &= yet_another_test(cert); And it should have been: is_valid &= !has_explicitly_encoded_curve_params(cert);