[erlang-bugs] Incomplete Elliptic Curve Cipher Suites in R16B01 and R16B02

[Ingela Anderton Andin]

Hi!

Thank you for your efforts on looking into this.

On 10/05/2013 12:57 AM, Andrew Thompson wrote:
> I think I've found the second issue. gnutls-cli and Erlang negotiate the
> cipher as
>
> {ecdhe_rsa,aes_128_cbc,sha,default_prf}
>
> Then erlang picks secp256k1 as the curve to use, despite the fact that
> GNUTLS only advertised it supported secp192r1, secp224r1, secp256r1,
> secp384r1 and secp521k1 in the client hello.

Hum,  the original ECC contribution always selected secp521k1, but
I thought I changed that! It however still has it as fallback and if the
code fails to input the correct data to select curve I suppose this could
still be the behavior! I will look in to that.

> However, erlang completely ignores the ECC curves the client advertises
> in the Client Hello. If you change the assignment of client_ecc:
>
> https://github.com/erlang/otp/blob/OTP_R16B02/lib/ssl/src/tls_connection.erl#L427
>
> To instead pull the eliptic curves out of the #client_hello.extensions,
> it'll actually work: I did something like this:
>
> hello(Hello = #client_hello{client_version = ClientVersion,
>                              extensions = #hello_extensions{hash_signs = HashSigns, elliptic_curves={elliptic_curves, ClientECC}}},
> ...
>                                          client_ecc = {ClientECC, EcPointFormats}});
>
> And that made it so gnutls-cli could connect. I realize this isn't
> perfect, but it certainly illustrates the problem, SSL is ignoring what
> the client asks for. I think it is also ignoring the EC point formats.
>

Seems the problem might be releted to this! I will look at what might be 
the "correct" solution.

Regards Ingela Erlang/OTP tema - Ericsson AB