ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Nicholas Lundgaard
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Ingela Andin
Hi!

This is a configuration problem I suggest solutions in the ERL-823.

Regards Ingela Erlang/OTP team

Den tors 3 jan. 2019 kl 21:18 skrev Nicholas Lundgaard <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Guilherme Andrade
In reply to this post by Nicholas Lundgaard
Hello,

Some people have worked around the issue by building OpenSSL separately and statically linking it against ERTS. This does have the disadvantage of not benefiting from distro package upgrades, though.

There's a tutorial that lists the appropriate steps[1].

(I know this doesn't solve your particular problem, but it might work out as an alternative in case you haven't considered it already - depending on your particular requirements.)

[1]: https://github.com/lrascao/erlang-ec2-build

On Thu, 3 Jan 2019 at 20:18, Nicholas Lundgaard <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Ingela Andin
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

Den tors 3 jan. 2019 kl 22:29 skrev Guilherme Andrade <[hidden email]>:
Hello,

Some people have worked around the issue by building OpenSSL separately and statically linking it against ERTS. This does have the disadvantage of not benefiting from distro package upgrades, though.

There's a tutorial that lists the appropriate steps[1].

(I know this doesn't solve your particular problem, but it might work out as an alternative in case you haven't considered it already - depending on your particular requirements.)

[1]: https://github.com/lrascao/erlang-ec2-build

On Thu, 3 Jan 2019 at 20:18, Nicholas Lundgaard <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Guilherme Andrade
Fair enough :-)

The intention behind my suggestion to Nicholas was not to misguide, but rather to present an alternative in case everything else fails - one that has worked for me in the past, albeit for different reasons (using EC ciphers in Amazon Linux.)

However, this being cryptography and me a layman in it, I'll humbly atone for my heresy in case I've given terrible advice (no sarcasm, truly.)

On Thu, 3 Jan 2019 at 22:11, Ingela Andin <[hidden email]> 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

Den tors 3 jan. 2019 kl 22:29 skrev Guilherme Andrade <[hidden email]>:
Hello,

Some people have worked around the issue by building OpenSSL separately and statically linking it against ERTS. This does have the disadvantage of not benefiting from distro package upgrades, though.

There's a tutorial that lists the appropriate steps[1].

(I know this doesn't solve your particular problem, but it might work out as an alternative in case you haven't considered it already - depending on your particular requirements.)

[1]: https://github.com/lrascao/erlang-ec2-build

On Thu, 3 Jan 2019 at 20:18, Nicholas Lundgaard <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Guilherme Andrade
I've in the mean time noticed Nicholas mentioned custom OpenSSL builds in the ticket, which I obviously didn't read through well enough. Long week, I apologize for the noise.

On Thu, 3 Jan 2019 at 23:08, Guilherme Andrade <[hidden email]> wrote:
Fair enough :-)

The intention behind my suggestion to Nicholas was not to misguide, but rather to present an alternative in case everything else fails - one that has worked for me in the past, albeit for different reasons (using EC ciphers in Amazon Linux.)

However, this being cryptography and me a layman in it, I'll humbly atone for my heresy in case I've given terrible advice (no sarcasm, truly.)

On Thu, 3 Jan 2019 at 22:11, Ingela Andin <[hidden email]> 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

Den tors 3 jan. 2019 kl 22:29 skrev Guilherme Andrade <[hidden email]>:
Hello,

Some people have worked around the issue by building OpenSSL separately and statically linking it against ERTS. This does have the disadvantage of not benefiting from distro package upgrades, though.

There's a tutorial that lists the appropriate steps[1].

(I know this doesn't solve your particular problem, but it might work out as an alternative in case you haven't considered it already - depending on your particular requirements.)

[1]: https://github.com/lrascao/erlang-ec2-build

On Thu, 3 Jan 2019 at 20:18, Nicholas Lundgaard <[hidden email]> 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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
Guilherme


--
Guilherme

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Fred Hebert-2
In reply to this post by Ingela Andin
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.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Ingela Andin
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 <[hidden email]>:
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.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>:
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 <[hidden email]>:
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.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Andreas Schultz-3
In reply to this post by Nicholas Lundgaard
Nicholas Lundgaard <[hidden email]> schrieb am Do., 3. Jan. 2019 um 21:18 Uhr:
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:

ECC Ciphers are supported since RHEL 7.6 (also newer CentOS versions), Amazon Linux 2018.03 also has support (`openssl ciphers -v` does contain ECDH ciphers).

Maybe it is time to upgrade your systems to something more current?

Regards,
Andreas
--
--
Dipl.-Inform. Andreas Schultz

----------------------- enabling your networks ----------------------
Travelping GmbH                     Phone:  +49-391-81 90 99 0
Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
39108 Magdeburg                     Email:  [hidden email]
GERMANY                             Web:    http://www.travelping.com

Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
---------------------------------------------------------------------

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Per Hedeland
On 2019-01-04 10:38, Andreas Schultz wrote:
> Nicholas Lundgaard <[hidden email] <mailto:[hidden email]>> schrieb am Do., 3. Jan. 2019 um 21:18 Uhr:
>
>     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:
>
>
> ECC Ciphers are supported since RHEL 7.6 (also newer CentOS versions), Amazon Linux 2018.03 also has support (`openssl ciphers -v` does contain ECDH ciphers).

Actually I think there is some confusion here - also older versions of
RHEL/CentOS(/Fedora?) support ECC cipher suites (I checked CentOS 7.2
just now) - it is only a specific *set of curves* they don't support
(and probably newer versions don't either), due to concerns about
potential patents.

And there was actually a time when you *had* to use the brutal
OPENSSL_NO_EC=1 workaround/hack to get OTP crypto to work on these
systems, since crypto.c couldn't handle this "partial" exclusion of
curves - depending on how you built it (excluding static linking* of
libcrypto), you would get a failure either at build or run time.

But that was long ago, crypto.c was fixed in this respect already for
OTP 17, in https://github.com/erlang/otp/commit/8837c1be2ba, by -
Andreas Schultz! Thanks for that!:-)

So, if you use OTP 17 or newer:

- If you build with the libcrypto shipped with RHEL/CentOS, it will
   "just work", without the OPENSSL_NO_EC hack.

- If you for some reason build with a libcrypto that *includes* the
   curves that are excluded on those systems, you can still do a build
   that works there, *and* makes ECC suites in general available, by
   using OPENSSL_NO_EC2M=1 *instead* of OPENSSL_NO_EC=1.

I guess the moral is that if you are given a recipe for some problem,
make sure that you understand why it is needed, so you can stop using
it when the actual problem is fixed...:-)

*) I Am Not A Lawyer, but I will still advise at least those shipping
commercial products based on Erlang/OTP to look carefully into the
general legal issues with statically linking libcrypto into those
products. And after having done that, to think again about the wisdom
of doing the static linking specifically to be able to include
algorithms that may be patented.

--Per Hedeland
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Fred Hebert-2
In reply to this post by Ingela Andin
On 01/04, Ingela Andin wrote:
>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
>

Agreed, it's more powerful.

But when working with established teams and policies, having a unique
format just for Erlang tends to be problematic as non-standard. In some
places where I've been, if you can't get the security team to approve
the list, you are not greenlit to go to prod.

It's much, much simpler to work with non-erlang folks when we have a way
to more easily communicate and review the lists -- mostly there may just
be a list that will be adopted by all stacks, whether they're Erlang,
Go, C#, ruby, or servers like nginx, and so on.

At least getting the direct mapping between both can be very useful to
validate filtering rules and everything else :)
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Ingela Andin
Hi Fred!

Agree that a mapping functions are good. That is sort of why we like to accomplish with suite_to_str and we are working on the inverse. They will use the RFC-names that are more general and  better documented. But most
of the code to create the OpenSSL names exist so maybe we will expose that too as a utility function. Although we do not want to be dependent on OpenSSL configuration, we only want to have dependencies to its cryptolib.

Regards Ingela Erlang/OTP team - Ericsson AB

Den fre 4 jan. 2019 kl 17:32 skrev Fred Hebert <[hidden email]>:
On 01/04, Ingela Andin wrote:
>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
>

Agreed, it's more powerful.

But when working with established teams and policies, having a unique
format just for Erlang tends to be problematic as non-standard. In some
places where I've been, if you can't get the security team to approve
the list, you are not greenlit to go to prod.

It's much, much simpler to work with non-erlang folks when we have a way
to more easily communicate and review the lists -- mostly there may just
be a list that will be adopted by all stacks, whether they're Erlang,
Go, C#, ruby, or servers like nginx, and so on.

At least getting the direct mapping between both can be very useful to
validate filtering rules and everything else :)

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Nicholas Lundgaard
In reply to this post by Per Hedeland
Thanks for your insights, all.

I've looked at Erlang/OTP 21 builds from our CentOS box that were built with no OPENSSL_NO_EC* set, and also just tried one built with OPENSSL_NO_EC2M set, as advised below. It looks like it's true that these options are ideal for my company's use, and in both cases we properly get an Erlang/OTP build that has a fine set of cipher suites that work with the underlying OpenSSL library on the OS.

It seems like there is still some potential problem with this setup, though: both the ssl and crypto modules claim to support EC curves that the underlying SSL library does not, in fact, support. A simple function that wraps a key-generate/sign/verify process in a try-catch can be used to verify this:

VerifyCurve = fun(Curve) ->
    Msg = <<"hello world!">>,
    try
        {PublicKey, PrivKeyOut} = crypto:generate_key(ecdh,Curve),
        Signature = crypto:sign(ecdsa, sha512, Msg, [PrivKeyOut, Curve]),
        true = crypto:verify(ecdsa, sha512, <<"hello world!">>, Signature, [PublicKey, Curve]),
        ok
    catch
       Err:Reason ->
           {Err, Reason}
    end
end.

When I run this on ssl:eccs/0 or crypto:ec_curves/0, I get this result:

2> [{C, VerifyCurve(C)} || C <- ssl:eccs()].
[{secp521r1,ok},
 {brainpoolP512r1,ok},
 {brainpoolP384r1,ok},
 {secp384r1,ok},
 {brainpoolP256r1,ok},
 {secp256k1,ok},
 {secp256r1,ok},
 {secp224k1,{error,badarg}},
 {secp224r1,{error,badarg}},
 {secp192k1,{error,badarg}},
 {secp192r1,{error,badarg}},
 {secp160k1,{error,badarg}},
 {secp160r1,{error,badarg}},
 {secp160r2,{error,badarg}}]

3> rp([{C, VerifyCurve(C)} || C <- crypto:ec_curves()]).
[{secp160k1,{error,badarg}},
 {secp160r1,{error,badarg}},
 {secp160r2,{error,badarg}},
 {secp192r1,{error,badarg}},
 {secp192k1,{error,badarg}},
 {secp224k1,{error,badarg}},
 {secp224r1,{error,badarg}},
 {secp256k1,ok},
 {secp256r1,ok},
 {secp384r1,ok},
 {secp521r1,ok},
 {prime192v1,{error,badarg}},
 {prime192v2,{error,badarg}},
 {prime192v3,{error,badarg}},
 {prime239v1,{error,badarg}},
 {prime239v2,{error,badarg}},
 {prime239v3,{error,badarg}},
 {prime256v1,ok},
 {wtls7,{error,badarg}},
 {wtls9,{error,badarg}},
 {wtls12,{error,badarg}},
 {brainpoolP160r1,{error,badarg}},
 {brainpoolP160t1,{error,badarg}},
 {brainpoolP192r1,{error,badarg}},
 {brainpoolP192t1,{error,badarg}},
 {brainpoolP224r1,{error,badarg}},
 {brainpoolP224t1,{error,badarg}},
 {brainpoolP256r1,ok},
 {brainpoolP256t1,ok},
 {brainpoolP320r1,ok},
 {brainpoolP320t1,ok},
 {brainpoolP384r1,ok},
 {brainpoolP384t1,ok},
 {brainpoolP512r1,ok},
 {brainpoolP512t1,ok},
 {secp112r1,{error,badarg}},
 {secp112r2,{error,badarg}},
 {secp128r1,{error,badarg}},
 {secp128r2,{error,badarg}},
 {wtls6,{error,badarg}},
 {wtls8,{error,badarg}}]

So.. this is what actually is troubling me about an OTP that is installed this way: these two modules definitely report named curves that cause runtime errors. The underlying OpenSSL library definitely reports which ones it supports, so I guess my question is why doesn't ssl/crypto leverage this?

I think in point of fact, this concern isn't significant. It appears that Erlang/OTP 21 (built on RHEL/CentOS) has an SSL that works out of the box for most SSL connections, certainly to the hosts we care about (AWS services and ELBs/gateways in front of our infrastructure) and I'm guessing that's because the first 7 curves from "ssl:eccs/0" are, in fact, supported by the underlying OpenSSL library (and the list is in preference order). If I understand correctly, it would only be a problem to negotiate a connection with a peer  who does not support any of the first 7 preferred curves.

So, I understand that a workaround that I could implement in my HTTPS clients in Erlang is to cull the list of eccs, which can be passed explicitly when connecting (e.g., [{eccs, [secp521r1, brainpoolP512r1, brainpoolP384r1, secp384r1, brainpoolP256r1, secp256k1, secp256r1]}]). However, I feel that this begs the question, what is the reason for the ssl/crypto modules not reporting a lack of support for unsupported curves?

Thanks again! I will copy-paste this comment into the ERL-823 issue as well, for the record.

Regards,
—Nicholas Lundgaard

On Fri, Jan 4, 2019, at 6:07 AM, Per Hedeland wrote:

> On 2019-01-04 10:38, Andreas Schultz wrote:
> > Nicholas Lundgaard <[hidden email] <mailto:[hidden email]>> schrieb am Do., 3. Jan. 2019 um 21:18 Uhr:
> >
> >     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:
> >
> >
> > ECC Ciphers are supported since RHEL 7.6 (also newer CentOS versions), Amazon Linux 2018.03 also has support (`openssl ciphers -v` does contain ECDH ciphers).
>
> Actually I think there is some confusion here - also older versions of
> RHEL/CentOS(/Fedora?) support ECC cipher suites (I checked CentOS 7.2
> just now) - it is only a specific *set of curves* they don't support
> (and probably newer versions don't either), due to concerns about
> potential patents.
>
> And there was actually a time when you *had* to use the brutal
> OPENSSL_NO_EC=1 workaround/hack to get OTP crypto to work on these
> systems, since crypto.c couldn't handle this "partial" exclusion of
> curves - depending on how you built it (excluding static linking* of
> libcrypto), you would get a failure either at build or run time.
>
> But that was long ago, crypto.c was fixed in this respect already for
> OTP 17, in https://github.com/erlang/otp/commit/8837c1be2ba, by -
> Andreas Schultz! Thanks for that!:-)
>
> So, if you use OTP 17 or newer:
>
> - If you build with the libcrypto shipped with RHEL/CentOS, it will
>    "just work", without the OPENSSL_NO_EC hack.
>
> - If you for some reason build with a libcrypto that *includes* the
>    curves that are excluded on those systems, you can still do a build
>    that works there, *and* makes ECC suites in general available, by
>    using OPENSSL_NO_EC2M=1 *instead* of OPENSSL_NO_EC=1.
>
> I guess the moral is that if you are given a recipe for some problem,
> make sure that you understand why it is needed, so you can stop using
> it when the actual problem is fixed...:-)
>
> *) I Am Not A Lawyer, but I will still advise at least those shipping
> commercial products based on Erlang/OTP to look carefully into the
> general legal issues with statically linking libcrypto into those
> products. And after having done that, to think again about the wisdom
> of doing the static linking specifically to be able to include
> algorithms that may be patented.
>
> --Per Hedeland
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Per Hedeland
On 2019-01-04 18:41, Nicholas Lundgaard wrote:
> Thanks for your insights, all.
>
> I've looked at Erlang/OTP 21 builds from our CentOS box that were built with no OPENSSL_NO_EC* set, and also just tried one built with OPENSSL_NO_EC2M set, as advised below. It looks like it's true that these options are ideal for my company's use, and in both cases we properly get an Erlang/OTP build that has a fine set of cipher suites that work with the underlying OpenSSL library on the OS.
>
> It seems like there is still some potential problem with this setup, though: both the ssl and crypto modules claim to support EC curves that the underlying SSL library does not, in fact, support. A simple function that wraps a key-generate/sign/verify process in a try-catch can be used to verify this:

Well, I'm not really an expert on this stuff, but as far as I
understand Andreas' fix, the OPENSSL_NO_EC2M (which is set in the
relevant OpenSSL header file on the RHEL/CentOS systems) will only
cause the sect* curves to be excluded (there is also a note to this
effect added in lib/crypto/doc/src/crypto.xml in the commit).

And in your tests, the sect* curves are actually completely absent,
which is not the case if you do the same thing in an OTP built with a
"normal" OpenSSL libcrypto. So it seems the OPENSSL_NO_EC2M is working
as expected for you, and that the failures you see are unrelated to
this. Perhaps there is some other limitation in the OpenSSL version
shipped with RHEL/CentOS that prevents them from working? No idea what
that might be though...

--Per
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Nicholas Lundgaard
"Well, I'm not really an expert on this stuff"

That makes two of us, at least... :)

You're exactly right, when I compile OTP 21 on CentOS with or without OPENSSL_NO_EC2M, in either case, the built OTP correctly leaves ec_gf2m out of the public keys and filters out the GF2m named EC curves that aren't supported in the CentOS/RHEL OpenSSL.

The remaining problem on RHEL/CentOS systems is that (for whatever reason) these systems lack support for a bunch of non-GF2m curves that Erlang/OTP's crypto/ssl modules claim to support, but emit runtime exceptions when you try to use them. It seems that is because they are explicitly hard-coded into the C headers in the OTP applications, when that information could be extracted or extrapolated from the linked SSL library itself (either dynamically at runtime or during compilation).

For clarity, I think this situation with these missing EC curves on RHEL/CentOS has been like this for many years with almost no change, so upgrading to a newer version of RHEL/CentOS/Amazon Linux isn't going to help. Here is the output from  'openssl ecparam -list_curves' on the latest (2018.03) Amazon Linux AMI running "OpenSSL 1.0.2k-fips  26 Jan 2017":

 openssl ecparam -list_curves
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

And here is the output from  'openssl ecparam -list_curves' on a CentOS 6.9 box running "OpenSSL 1.0.1e-fips 11 Feb 2013".  The older OpenSSL library omits the secp256k1 curve, but again, pretty similar output:

openssl ecparam -list_curves
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field

Checking the supported curves in the OTP ssl/crypto applications seems like the natural way to reliably get this list correct, and IMO that is a better solution than expecting end-users in this situation to find this issue and resolve it by hand-filtering on every SSL connection.

Regards,
—Nicholas Lundgaard

On Fri, Jan 4, 2019, at 5:34 PM, Per Hedeland wrote:

> Well, I'm not really an expert on this stuff, but as far as I
> understand Andreas' fix, the OPENSSL_NO_EC2M (which is set in the
> relevant OpenSSL header file on the RHEL/CentOS systems) will only
> cause the sect* curves to be excluded (there is also a note to this
> effect added in lib/crypto/doc/src/crypto.xml in the commit).
>
> And in your tests, the sect* curves are actually completely absent,
> which is not the case if you do the same thing in an OTP built with a
> "normal" OpenSSL libcrypto. So it seems the OPENSSL_NO_EC2M is working
> as expected for you, and that the failures you see are unrelated to
> this. Perhaps there is some other limitation in the OpenSSL version
> shipped with RHEL/CentOS that prevents them from working? No idea what
> that might be though...
>
> --Per
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Per Hedeland
On 2019-01-05 16:03, Nicholas Lundgaard wrote:
> "Well, I'm not really an expert on this stuff"
>
> That makes two of us, at least... :)

I was very impressed by your VerifyCurve function though.:-)

> You're exactly right, when I compile OTP 21 on CentOS with or without OPENSSL_NO_EC2M, in either case, the built OTP correctly leaves ec_gf2m out of the public keys and filters out the GF2m named EC curves that aren't supported in the CentOS/RHEL OpenSSL.
>
> The remaining problem on RHEL/CentOS systems is that (for whatever reason) these systems lack support for a bunch of non-GF2m curves that Erlang/OTP's crypto/ssl modules claim to support, but emit runtime exceptions when you try to use them. It seems that is because they are explicitly hard-coded into the C headers in the OTP applications, when that information could be extracted or extrapolated from the linked SSL library itself (either dynamically at runtime or during compilation).

Traditionally the build of the crypto.c NIF module has been based on
the #defines in the *OpenSSL* headers, in particular
openssl/opensslconf.h, which is supposed to describe how the OpenSSL
libraries were built - this is where both OPENSSL_NO_EC and
OPENSSL_NO_EC2M originates (i.e. from using the 'no-ec' and 'no-ec2m'
options, respectively, in the OpenSSL configure/build).

I don't think there are any more specific #defines for the individual
ECC curves though - and in fact there doesn't seem to be any options
for that in the OpenSSL build either. But in any case, using only the
OpenSSL headers at build time, while linking dynamically with
libcrypto, means that the libcrypto found at run time may not match
the build, and runtime checks are motivated. And I believe both OTP
crypto and OTP ssl do some such checks, but maybe they aren't 100%.

> For clarity, I think this situation with these missing EC curves on RHEL/CentOS has been like this for many years with almost no change, so upgrading to a newer version of RHEL/CentOS/Amazon Linux isn't going to help. Here is the output from  'openssl ecparam -list_curves' on the latest (2018.03) Amazon Linux AMI running "OpenSSL 1.0.2k-fips  26 Jan 2017":
>
>   openssl ecparam -list_curves
>    secp256k1 : SECG curve over a 256 bit prime field
>    secp384r1 : NIST/SECG curve over a 384 bit prime field
>    secp521r1 : NIST/SECG curve over a 521 bit prime field
>    prime256v1: X9.62/SECG curve over a 256 bit prime field
>
> And here is the output from  'openssl ecparam -list_curves' on a CentOS 6.9 box running "OpenSSL 1.0.1e-fips 11 Feb 2013".  The older OpenSSL library omits the secp256k1 curve, but again, pretty similar output:
>
> openssl ecparam -list_curves
>    secp384r1 : NIST/SECG curve over a 384 bit prime field
>    secp521r1 : NIST/SECG curve over a 521 bit prime field
>    prime256v1: X9.62/SECG curve over a 256 bit prime field

I also tried the 'ecparam -list_curves' on various systems, and was
pretty surprised by the result... As you can see, the list you get on
CentOS is way shorter than the list of successful invocations of your
VerifyCurve funcion - and with a "normal" OpenSSL-1.0.1 build, I get
this:

   secp112r1 : SECG/WTLS curve over a 112 bit prime field
   secp112r2 : SECG curve over a 112 bit prime field
   secp128r1 : SECG curve over a 128 bit prime field
   secp128r2 : SECG curve over a 128 bit prime field
   secp160k1 : SECG curve over a 160 bit prime field
   secp160r1 : SECG curve over a 160 bit prime field
   secp160r2 : SECG/WTLS curve over a 160 bit prime field
   secp192k1 : SECG curve over a 192 bit prime field
   secp224k1 : SECG curve over a 224 bit prime field
   secp224r1 : NIST/SECG curve over a 224 bit prime field
   secp256k1 : SECG curve over a 256 bit prime field
   secp384r1 : NIST/SECG curve over a 384 bit prime field
   secp521r1 : NIST/SECG curve over a 521 bit prime field
   prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
   prime192v2: X9.62 curve over a 192 bit prime field
   prime192v3: X9.62 curve over a 192 bit prime field
   prime239v1: X9.62 curve over a 239 bit prime field
   prime239v2: X9.62 curve over a 239 bit prime field
   prime239v3: X9.62 curve over a 239 bit prime field
   prime256v1: X9.62/SECG curve over a 256 bit prime field
   sect113r1 : SECG curve over a 113 bit binary field
   sect113r2 : SECG curve over a 113 bit binary field
   sect131r1 : SECG/WTLS curve over a 131 bit binary field
   sect131r2 : SECG curve over a 131 bit binary field
   sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
   sect163r1 : SECG curve over a 163 bit binary field
   sect163r2 : NIST/SECG curve over a 163 bit binary field
   sect193r1 : SECG curve over a 193 bit binary field
   sect193r2 : SECG curve over a 193 bit binary field
   sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
   sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
   sect239k1 : SECG curve over a 239 bit binary field
   sect283k1 : NIST/SECG curve over a 283 bit binary field
   sect283r1 : NIST/SECG curve over a 283 bit binary field
   sect409k1 : NIST/SECG curve over a 409 bit binary field
   sect409r1 : NIST/SECG curve over a 409 bit binary field
   sect571k1 : NIST/SECG curve over a 571 bit binary field
   sect571r1 : NIST/SECG curve over a 571 bit binary field
   c2pnb163v1: X9.62 curve over a 163 bit binary field
   c2pnb163v2: X9.62 curve over a 163 bit binary field
   c2pnb163v3: X9.62 curve over a 163 bit binary field
   c2pnb176v1: X9.62 curve over a 176 bit binary field
   c2tnb191v1: X9.62 curve over a 191 bit binary field
   c2tnb191v2: X9.62 curve over a 191 bit binary field
   c2tnb191v3: X9.62 curve over a 191 bit binary field
   c2pnb208w1: X9.62 curve over a 208 bit binary field
   c2tnb239v1: X9.62 curve over a 239 bit binary field
   c2tnb239v2: X9.62 curve over a 239 bit binary field
   c2tnb239v3: X9.62 curve over a 239 bit binary field
   c2pnb272w1: X9.62 curve over a 272 bit binary field
   c2pnb304w1: X9.62 curve over a 304 bit binary field
   c2tnb359v1: X9.62 curve over a 359 bit binary field
   c2pnb368w1: X9.62 curve over a 368 bit binary field
   c2tnb431r1: X9.62 curve over a 431 bit binary field
   wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
   wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
   wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
   wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
   wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
   wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
   wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
   wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
   wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
   wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
   wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
   Oakley-EC2N-3:
         IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
         Not suitable for ECDSA.
         Questionable extension field!
   Oakley-EC2N-4:
         IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
         Not suitable for ECDSA.
         Questionable extension field!

I haven't done a strict comparison of this output with the results of
running your VerifyCurve function on the same system, but my
impression is that all curves that were successful in the latter are
also included in the former.

I really wonder how the CentOS libcrypto was built. The "-fips" in the
version might be a clue, but I believe this only means that it was
built in such a way that "FIPS mode" is *available*, and thus it
shouldn't affect something like the set of "supported" ECC curves.
(If "FIPS mode" was *enforced*, it wouldn't work at all before OTP 20
I believe, and this is definitely not the case.)

Anyway, 'ecparam -list_curves' uses the OpenSSL function
EC_get_builtin_curves(), which is documented in the OpenSSL man page
with, among other info:
       
     Whilst the library can be used to create any curve using the functions
     described above, there are also a number of predefined curves that are
     available. In order to obtain a list of all of the predefined curves,
     call the function EC_get_builtin_curves.

So I guess this isn't really the set of *supported* curves, and the
OpenSSL ecparam(1) man page does say

    -list_curves
        If this options is specified ecparam will print out a list of all
        currently implemented EC parameters names and exit.
                  ^^^^^^^^^^^

- and there may already be some magic going on in the OTP 'crypto' app
to create additional curves "on demand". But by now I'm way out of
whatever expertise I may have...

--Per
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Hans Nilsson R (AL/EAB)
In reply to this post by Nicholas Lundgaard
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?

/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
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ERL-823: SSL cipher_suites too limited when compiling with OPENSSL_NO_EC=1

Per Hedeland
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
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: 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
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12