[erlang-questions] Erlang/OTP 21.0-rc1 (Release Candidate)
Ingela Andin
ingela.andin@REDACTED
Fri May 4 12:36:29 CEST 2018
Hi!
I traced my problem to sslv2_hello compatibility. I will give you something
to try later today!
Regards Ingela Erlang/OTP team
2018-05-04 10:05 GMT+02:00 Heinz N. Gies <heinz@REDACTED>:
> I’m having quite some trouble on the SSL front too. I’m giving it a try to
> move the riak_core code to R21 and the ssl test [1] fails.
>
> If I use the original keys (in the repo under test/site1/2-…) I get a
> handshake failure.
>
> Using those keys I get an handshake failure too:
>
> openssl req -x509 -newkey rsa:4096 -keyout test/site1-key.pem -out
> test/site1-cert.pem -days 3650 -nodes -subj '/CN=US'
> openssl req -x509 -newkey rsa:4096 -keyout test/site2-key.pem -out
> test/site2-cert.pem -days 3650 -nodes -subj '/CN=US’
>
> DSA keys
>
> openssl dsaparam -out dsaparams-site1.pem 1024
> openssl dsaparam -out dsaparams-site2.pem 1024
> openssl req -x509 -newkey dsa:dsaparams-site1.pem -keyout
> test/site1-key.pem -out test/site1-cert.pem -days 3650 -nodes -subj '/CN=US'
> openssl req -x509 -newkey dsa:dsaparams-site2.pem -keyout
> test/site2-key.pem -out test/site2-cert.pem -days 3650 -nodes -subj '/CN=US’
>
> Fail with:
>
> {badmatch,
> {error,
> {options,
> {keyfile,"test/site1-key.pem",
> {error,
> {asn1,
> {{wrong_tag,
> {{expected,16},
> {got,2,
> {2,
> <<74,130,213,43,78,73,39,24,
> 206,62,159,
> 168,30,65,230,24,14,31,209,
> 192>>}}}},
> [{'OTP-PUB-KEY',match_tags,2,
> [{file,"OTP-PUB-KEY.erl"},{line,20535}]},
> {'OTP-PUB-KEY',dec_DSAPrivateKey,2,
> [{file,"OTP-PUB-KEY.erl"},{line,1789}]},
> {'OTP-PUB-KEY',decode,2,
> [{file,"OTP-PUB-KEY.erl"},{line,1103}]},
> {public_key,der_decode,2,
> [{file,"public_key.erl"},{line,248}]},
> {ssl_config,init_private_key,5,
> [{file,"ssl_config.erl"},{line,114}]},
> {ssl_config,init,2,
> [{file,"ssl_config.erl"},{line,38}]},
> {ssl_connection,ssl_config,4,
> [{file,"ssl_connection.erl"},{line,571}]},
> {tls_connection,init,1,
> [{file,"tls_connection.erl"},
> {line,116}]}]}}}}}}}
>
>
> EC keys fail with a handshake failure too
>
> openssl ecparam -out ecparams-site1.pem -name prime256v1
> openssl ecparam -out ecparams-site2.pem -name prime256v1
> openssl req -x509 -newkey ec:ecparams-site1.pem -keyout test/site1-key.pem
> -out test/site1-cert.pem -days 3650 -nodes -subj '/CN=US'
> openssl req -x509 -newkey ec:ecparams-site2.pem -keyout test/site2-key.pem
> -out test/site2-cert.pem -days 3650 -nodes -subj '/CN=US'
>
>
> https://github.com/Kyorai/riak_core/blob/develop/src/
> riak_core_tcp_mon.erl#L450
>
>
>
>
> On 4. May 2018, at 09:32, Ingela Andin <ingela.andin@REDACTED> wrote:
>
> Hi!
>
>
> 2018-05-03 18:08 GMT+02:00 Loïc Hoguin <essen@REDACTED>:
>
>> Hello,
>>
>> On 05/03/2018 01:54 PM, Loïc Hoguin wrote:
>>
>>> * SSL is broken. See [1] for example. I can see the same thing happening
>>> on 5 different Linux distributions (with different OpenSSL versions) and on
>>> OSX. A quick try in the shell is not much better:
>>>
>>
>>
> Thank you for shouting, that is what the release candidate is for. So we
> can catch the problems early!
>
>
>
>
>> OK it's just a very misleading error message I think.
>>
>
>
> Well that depends, this is not really an error message that you should get
> unless you have a buggy or malicious client. But of course now we might be
> getting it due to a bug and then
> it could be misleading!
>
>
>
>>
>> Switching my server's test keys from RSA to DSA fixes it so I think this
>> issue is caused by:
>>
>> OTP-14769 Application(s): ssl
>>
>> For security reasons RSA-key exchange cipher suites are
>> no longer supported by default
>>
>
>
> I do not really suspect this change. RSA-certificates are still supported.
> Just cipher suites using RSA encryption/decryption in the key exchange
> process are not supported.
> When you switched to a DSA-certificate an other cipher suite was picked
> that did not expose the problem. If there had been no common cipher suites
> you would have got another error.
>
>
>
>>
>> Still, it probably should provide a more helpful error message than this:
>>
>> *** System report during acceptor_SUITE:ssl_echo/1 in ssl 2018-05-03
>> 11:13:04.343 ***
>> =INFO REPORT==== 3-May-2018::11:13:04.342940 ===
>> TLS server: In state hello at tls_handshake.erl:130 generated SERVER
>> ALERT: Fatal - Handshake Failure - malformed_handshake_data
>>
>> *** System report during acceptor_SUITE:ssl_echo/1 in ssl 2018-05-03
>> 11:13:04.348 ***
>> =INFO REPORT==== 3-May-2018::11:13:04.348265 ===
>> TLS client: In state hello received SERVER ALERT: Fatal - Handshake
>> Failure
>>
>> "malformed_handshake_data" sounds like the client would have sent a
>> malformed handshake, ie bad data, when the actual issue seems to be that
>> the certificate configured is no longer supported. The server generating an
>> alert about its own certificate doesn't sound quite right either.
>>
>> That being said I do not really know the intent so I'm guessing a bit.
>> All I know for sure is that it's confusing.
>>
>>
>
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!
>
> Regards Ingela Erlang/OTP Team
>
>
>
>
>
>
>> Cheers,
>>
>>
>> --
>> Loïc Hoguin
>> https://ninenines.eu
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180504/efc5c742/attachment.htm>
More information about the erlang-questions
mailing list