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

[Ingela Andin]

Hi again!

Maybe I should add that using filters where you can access each logical
part of the cipher suite is a more powerful way to customize cipher suites
than regular expressions over complex strings.
Also see ssl User Guide http://erlang.org/doc/search/?q=ssl&x=0&y=0 section
3.2


Regards Ingela Erlang/OTP team - Ericsson AB

Den fre 4 jan. 2019 kl 08:47 skrev Ingela Andin <ingela.andin@REDACTED>:

> Hi!
>
> Well I would not say that explicitly writing a long lists of maps is the
> best way. For instance if you want to add the removed rsa -key exchange
> suite it would be done like.
>
> add_rsa_suites(Version) ->
>
>     All = ssl:cipher_suites(all, Version),
>
>     Default = ssl:cipher_suites(default, Version),
>
>     RSASuites = ssl:filter_cipher_suites(All,[{key_exchange, fun(rsa) -> true;(_) -> false end}]),
>
>     ssl:append_cipher_suites(RSASuites, Default).
>
>
> From a security perspective that would not be my recommendation though.
>
> For backward compatibility reasons just supplying the OpenSSL names will probably still work. However we do not guarantee forward compatibility for that.
> We plan on having some support for RFC names which are similar to OpenSSL names but more consistent. We do already have suite_to_str function but we plan on having a str_to_suite too .
>
> Regards Ingela Erlang/OTP team
>
>
> Den fre 4 jan. 2019 kl 03:41 skrev Fred Hebert <mononcqc@REDACTED>:
>
>> On 01/03, Ingela Andin wrote:
>> >I say it would be a lot easier to configure the erlang cipher suites the
>> >way you like and skip trying to tweak OpenSSL.  Please see ERL382.
>> >
>> >Regards Ingela Erlang/OTP team
>> >
>>
>> Additionally, Heroku has an open source library to handle TLS servers
>> with SNI for dispatch, which comes with some default configurations and
>> ways to easily translate from a known SSL list of ciphers such as what
>> you'd find at:
>>
>> -
>> https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html
>> -
>> https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29
>>
>> In all of these lists, the format chosen is something like
>> ECDHE-ECDSA-AES128-GCM-SHA256 rather than the Erlang-specific maps like
>> #{cipher => aes_128_cbc,key_exchange => ecdhe_rsa, mac => sha256,prf =>
>> sha256} or {ecdhe_ecdsa,aes_128_gcm,null,sha256} (in OTP 20.2 and
>> earlier)
>>
>> To facilitate with this, I've written and updated their lib (PR pending)
>> to include procedures to make the conversion between both formats easy:
>>
>> https://github.com/heroku/snit/pull/36/files#diff-1ea45e0c99dd72cbe37b5b3f4f561c70R38
>>
>> It goes a bit like this:
>>
>>     %% Declare the list of suites you want in the order you need them
>>     OpenSSLSuites = [
>>         "ECDHE-ECDSA-AES128-GCM-SHA256",
>>         "ECDHE-ECDSA-AES256-GCM-SHA384",
>>         "ECDHE-RSA-AES128-GCM-SHA256",
>>         ...
>>     ],
>>
>>     %% Declare the supported TLS versions you want (you may want to drop
>>     %% tlsv1 and possibly 'tlsv1.1' as well, depending on compatibility
>>     SupportedVersions = [tlsv1, 'tlsv1.1', 'tlsv1.2'],
>>
>>     %% Then run the following (see the source file for equivalents in
>>     %% older versions of Erlang and OTP)
>>     Suites = lists:usort(lists:append(
>>         [ssl:cipher_suites(all, Vsn) || Vsn <- SupportedVersions]
>>     )),
>>     Table = [{Str, [S]}  || S <- Suites,
>>                             Raw <- [ssl_cipher_format:suite(S)],
>>                             Str <-
>> [ssl_cipher_format:openssl_suite_name(Raw)],
>>                             not is_map(Str)],
>>     [lists:keyfind(Suite, 1, Table) || Suite <- OpenSSLSuites].
>>
>> This gives a full table of all currently supported suites with both the
>> OpenSSL and the Erlang format, such as:
>>
>>     [{"ECDHE-ECDSA-AES128-GCM-SHA256",
>>       [#{cipher => aes_128_gcm,key_exchange => ecdhe_ecdsa,
>>          mac => aead,prf => sha256}]},
>>      {"ECDHE-ECDSA-AES256-GCM-SHA384",
>>       [#{cipher => aes_256_gcm,key_exchange => ecdhe_ecdsa,
>>          mac => aead,prf => sha384}]},
>>      {"ECDHE-RSA-AES128-GCM-SHA256",
>>       [#{cipher => aes_128_gcm,key_exchange => ecdhe_rsa,mac => aead,
>>          prf => sha256}]},
>>      ...
>>     ]
>>
>> Which in my opinion, makes it a lot easier to manage configurations if
>> you don't want to carefully groom them all -- just copy a list you trust
>> from some source online and get it applied directly. Snit uses that list
>> and re-validates it at start time, but it would be easy to retransform
>> it by just using lists:flatten([Map || {_Name, Map} <- Result]) for the
>> format the Erlang ssl lib uses natively.
>>
>> This also has the benefit that if you have any infosec department,
>> they'll love you for providing them a list and format they're familiar
>> with rather than the unique internal erlang format.
>>
>> Regards,
>> Fred.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190104/4d1e5e63/attachment.htm>