Contributed by grey on from the LibreSSL fixed many of the bugs, let's patch some more! dept.
A source code patch exists which remedies this problem:
This is related to CVE-2016-7056 "ECDSA P-256 timing attack key recovery (OpenSSL, LibreSSL, BoringSSL)" Additional details can be read here: http://seclists.org/oss-sec/2017/q1/52
Thanks to M:Tier https://stable.mtier.org for raising awareness on this patch.
(Comments are closed)
By Chas (142.79.57.1) on
If I never use P-256, and always set either curve = secp384r1 or curve = secp521r1, then I can safely ignore this problem?
DJB only approves of the 521 curve in any case (and I always use it unless I'm dealing with Google Chrome):
To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2^521 - 1; but the sheer size of this prime makes it much slower than NIST P-256.
Comments
By Chas (142.79.57.1) on
If you append the following output after the cert in your .pem file, you will force most (capable) OpenSSL implementations to use the 521 curve:
The curves above come from Oracle(RedHat) Linux 7.3 - supposedly this functionality was added to OpenSSL by Sun, who was very careful to avoid a number of patents in this implementation. I'm assuming that LibreSSL inherits that code.
You can check the curve that a remote TLS server is using with s_client:
Unlike Firefox, Google Chrome does not support the 521 curve, and will fall back to rsa+aes without forward secrecy. The ssllabs scanner will show what curves a browser supports.