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

Hans Nilsson R hans.r.nilsson@REDACTED
Tue Jan 8 13:51:10 CET 2019


Thanks Per!  I'll cancel the PR.
/Hans

On 1/8/19 1:16 PM, Per Hedeland wrote:
> 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
> 



More information about the erlang-questions mailing list