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

[Per Hedeland]

I fixed the VirtualBox problem (again:-(), and could thus do some
testing on CentOS 7.6 with headers installed. Using OTP 21.2 and
Nicholas' VerifyCurve function - first a "normal" OpenSSL build,
i.e. straight from openssl.org source, no modifications or
algorithm-related config options:

$ openssl version
OpenSSL 1.0.2k  26 Jan 2017
$ openssl ecparam -list_curves | grep ':' | wc -l
       81

2> length(ssl:eccs()).
28
3> length([C || C <- ssl:eccs(), VerifyCurve(C) == ok]).
28
4> length(crypto:ec_curves()).
83
5> length([C || C <- crypto:ec_curves(), VerifyCurve(C) == ok]).
81

(I believe the diff here, due to
  {ipsec3,{error,badkey}},
  {ipsec4,{error,badkey}}]
may be caused by improper usage rather than lack of support. Those
curves are also not listed by 'ecparam -list_curves'.)

- and then CentOS:

$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ openssl ecparam -list_curves | grep ':' | wc -l
4

2> length(ssl:eccs()).
14
3> length([C || C <- ssl:eccs(), VerifyCurve(C) == ok]).
7
4> length(crypto:ec_curves()).
41
5> length([C || C <- crypto:ec_curves(), VerifyCurve(C) == ok]).
13

And, the installed openssl/obj_mac.h header file is identical for the
two, and has all the NID_xxx #defines that your PR adds #ifdefs for
- thus I'm afraid it makes no difference at all for *this* problem
(yes, I did test it:-).

--Per

On 2019-01-07 23:49, Per Hedeland wrote:
> On 2019-01-07 18:36, Hans Nilsson R wrote:
>> Hi,
>>
>> I've made a PR with #ifdefs for the EC names in crypto.c:
>>       https://github.com/erlang/otp/pull/2085
>>
>> The C-function algorithms() uses this for the 'curves' value in crypto:supports/0 which both SSL and SSH is supposed to use.
>>
>> Comments?
> 
> Hm, is the idea that those NID_xxx #defines in the OpenSSL headers
> will reflect what the library supports? I don't think that is the
> case, but I guess Nicholas can check if his CentOS systems have a
> different set of #defines (in /usr/include/openssl/obj_mac.h) from a
> what a "normal" build of the same OpenSSL version has. (I can atm only
> check a CentOS "live-cd", which doesn't have the headers - for some
> reason my VirtualBox install always hangs...)
> 
> --Per
> 
>> /Hans
>>
>> On 1/3/19 6:53 PM, Nicholas Lundgaard wrote:
>>> Hi,
>>>
>>> I wanted to call ERL-823 (https://bugs.erlang.org/browse/ERL-823) to this list's attention. My company operates Erlang microservices in AWS on a kerl-built OTP installation on Amazon Linux 
>>> (RedHat/CentOS-based), and we've encountered a serious challenge to upgrading to OTP 21: When you disable OpenSSL EC ciphers during an OTP build, which is necessary to build an OTP installation 
>>> that doesn't erroneously think it has a bunch of EC ciphers that aren't built into the underlying OpenSSL, you're no longer able to connect to google.com via https (not to mention many, many other 
>>> web properties, like much of AWS infrastructure).
>>>
>>> It confuses me that there is not a simpler way to align the Erlang crypto/ssl cipher support with the underlying openssl installation it's linked to, but that notwithstanding, It would be really 
>>> helpful to have a flag to build OTP with support for RedHat/Fedora's EC cipher subset, or something similar to this.
>>>
>>> Thanks,
>>> Nicholas Lundgaard
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions