[erlang-questions] ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1
Mon Jan 7 23:49:38 CET 2019
On 2019-01-07 18:36, Hans Nilsson R wrote:
> I've made a PR with #ifdefs for the EC names in crypto.c:
> The C-function algorithms() uses this for the 'curves' value in crypto:supports/0 which both SSL and SSH is supposed to use.
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...)
> On 1/3/19 6:53 PM, Nicholas Lundgaard wrote:
>> 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.
>> Nicholas Lundgaard
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions