[erlang-questions] ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

[Nicholas Lundgaard]

"Well, I'm not really an expert on this stuff"

That makes two of us, at least... :) 

You're exactly right, when I compile OTP 21 on CentOS with or without OPENSSL_NO_EC2M, in either case, the built OTP correctly leaves ec_gf2m out of the public keys and filters out the GF2m named EC curves that aren't supported in the CentOS/RHEL OpenSSL. 

The remaining problem on RHEL/CentOS systems is that (for whatever reason) these systems lack support for a bunch of non-GF2m curves that Erlang/OTP's crypto/ssl modules claim to support, but emit runtime exceptions when you try to use them. It seems that is because they are explicitly hard-coded into the C headers in the OTP applications, when that information could be extracted or extrapolated from the linked SSL library itself (either dynamically at runtime or during compilation). 

For clarity, I think this situation with these missing EC curves on RHEL/CentOS has been like this for many years with almost no change, so upgrading to a newer version of RHEL/CentOS/Amazon Linux isn't going to help. Here is the output from  'openssl ecparam -list_curves' on the latest (2018.03) Amazon Linux AMI running "OpenSSL 1.0.2k-fips  26 Jan 2017":

 openssl ecparam -list_curves
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

And here is the output from  'openssl ecparam -list_curves' on a CentOS 6.9 box running "OpenSSL 1.0.1e-fips 11 Feb 2013".  The older OpenSSL library omits the secp256k1 curve, but again, pretty similar output:

openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Checking the supported curves in the OTP ssl/crypto applications seems like the natural way to reliably get this list correct, and IMO that is a better solution than expecting end-users in this situation to find this issue and resolve it by hand-filtering on every SSL connection.

Regards,
—Nicholas Lundgaard

On Fri, Jan 4, 2019, at 5:34 PM, Per Hedeland wrote:
> Well, I'm not really an expert on this stuff, but as far as I
> understand Andreas' fix, the OPENSSL_NO_EC2M (which is set in the
> relevant OpenSSL header file on the RHEL/CentOS systems) will only
> cause the sect* curves to be excluded (there is also a note to this
> effect added in lib/crypto/doc/src/crypto.xml in the commit).
> 
> And in your tests, the sect* curves are actually completely absent,
> which is not the case if you do the same thing in an OTP built with a
> "normal" OpenSSL libcrypto. So it seems the OPENSSL_NO_EC2M is working
> as expected for you, and that the failures you see are unrelated to
> this. Perhaps there is some other limitation in the OpenSSL version
> shipped with RHEL/CentOS that prevents them from working? No idea what
> that might be though...
> 
> --Per
>