Many companies, including my own, use Erlang/OTP built and running on a RedHat/CentOS/Fedora-based Linux system, such as Amazon Linux. These systems use a customized OpenSSL installation that eschews most elliptic curve ciphers due to patent concerns on the part of RedHat. This means that, in order to get a reliable working Erlang installation on the platform, a developer's only option (outside of baking one's own OpenSSL a generally discouraged practice for enterprise systems) is to compile Erlang/OTP with
export CFLAGS="-O2 -g -DOPENSSL_NO_EC=1"
Now, using OPENSSL_NO_EC=1 has worked fine for all Erlang/OTP releases through Erlang/OTP 20.3 (with the exception of 20.0-20.2, which had a compilation bug). Unfortunately, as of Erlang/OTP 21.0, the available cipher_suites when building OTP in this way is so pared down that you really can't use SSL at all.
In OTP 20.3 built with OPENSSL_NO_EC=1, this was the available list of ciphers in the ssl module:
In Erlang/OTP 21 built with OPENSSL_NO_EC=1, this is the list:
The cipher suites have been cut from 21 to 12, and as a result, clients can't even negotiate an SSL connection to google.com:
Not to mention many other important HTTPS servers, like most of AWS's internal services (S3, DynamoDB, etc).
It would be ideal if Erlang/OTP actually consulted the linked OpenSSL installation for available ciphers during compilation, since they can be consulted directly. However, barring that, perhaps it is possible to provide a compilation option that would allow RedHat/CentOS users to build an OTP with some, but not all, of the EC ciphers and the attendant SSL cipher suites.