[erlang-bugs] SSL handshake crash

Fri Dec 25 12:54:58 CET 2015

Hi!

>From ssl users guide

 "Ensure active is set to false before trying to upgrade a connection to an SSL connection, otherwise SSL handshake messages can be delivered to the wrong process."

Regards Ingela Erlang/OTP team - Ericsson AB

________________________________
Från: erlang-bugs-bounces@REDACTED [erlang-bugs-bounces@REDACTED] för Danil Zagoskin [z@REDACTED]
Skickat: den 24 december 2015 10:22
Till: Ulf Wiger
Kopia: erlang-bugs@REDACTED
Ämne: Re: [erlang-bugs] SSL handshake crash

Hi!

I have the same issue, but not so often.
It seems to appear only when upgrading plain socket to TLS (XMPP starttls in my case).

Possibly it's some kind of race condition when client sends TLS hello before server does ssl_accept(). Maybe some active/passive socket mode issue.

If you control the client code, could you add some sleep before starttls and check if that fixes the issue?

On Wed, Dec 23, 2015 at 8:38 PM, Ulf Wiger <ulf@REDACTED<mailto:ulf@REDACTED>> wrote:
Hmm… I send this to erlang-bugs, but it didn’t seem to get through.

When connecting some Android software to an Erlang node using TLS, we sometimes (about 1 in 3 or 4 times) get the following errors:

2015-12-22 15:31:00.772 [error] <0.210.0> gen_fsm <0.210.0> in state hello terminated with reason: no function clause matching ssl_handshake:update_handshake_history(undefined, <<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,...>>) line 450

15:31:00.783<dlink_tls_conn/327>dlink_tls_conn:terminate(): Reason: {{function_clause,[{ssl_handshake,update_handshake_history,[undefined,<<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,109,210,170,150,204,23,32,228,0,0,70,0,4,0,5,0,47,0,53,192,2,192,4,192,5,192,12,192,14,192,15,192,7,192,9,192,10,192,17,192,19,192,20,0,51,0,57,0,50,0,56,0,10,192,3,192,13,192,8,192,18,0,22,0,19,0,9,0,21,0,18,0,3,0,8,0,20,0,17,0,255,1,0,0,64,0,11,0,4,3,0,1,2,0,10,0,52,0,50,0,14,0,13,0,25,0,11,0,12,0,24,0,9,0,10,0,22,0,23,0,8,0,6,0,7,0,20,0,21,0,4,0,5,0,18,0,19,0,1,0,2,0,3,0,15,0,16,0,17>>],[{file,"ssl_handshake.erl"},{line,450}]},{tls_connection,'-next_state/4-fun-0-',3,[{file,"tls_connection.erl"},{line,458}]},{tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,467}]},{gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,518}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,240}]}]},{gen_fsm,sync_send_all_state_event,[<0.210.0>,{start,infinity},infinity]}}

2015-12-22 15:31:00.784 [error] <0.210.0> CRASH REPORT Process <0.210.0> with 0 neighbours exited with reason: no function clause matching ssl_handshake:update_handshake_history(undefined, <<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,...>>) line 450 in gen_fsm:terminate/7 line 626

2015-12-22 15:31:00.785 [error] <0.209.0> gen_server <0.209.0> terminated with reason: {{function_clause,[{ssl_handshake,update_handshake_history,[undefined,<<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,109,210,170,150,204,23,32,228,0,0,70,0,4,0,5,0,47,0,53,192,2,192,4,192,5,192,12,192,14,192,15,192,7,192,9,192,10,192,17,192,19,192,20,0,51,0,57,0,50,0,56,0,10,192,3,192,13,192,8,192,18,0,22,0,19,0,9,0,21,0,18,0,3,0,8,0,20,0,17,0,255,1,0,0,64,0,11,0,4,3,0,1,2,0,10,0,52,0,50,0,14,0,13,0,25,0,11,0,12,0,24,0,9,0,10,0,22,0,23,0,8,0,...>>],...},...]},...} in gen_fsm:sync_send_all_state_event/3 line 257

2015-12-22 15:31:00.786 [error] <0.209.0> CRASH REPORT Process <0.209.0> with 0 neighbours exited with reason: {{function_clause,[{ssl_handshake,update_handshake_history,[undefined,<<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,109,210,170,150,204,23,32,228,0,0,70,0,4,0,5,0,47,0,53,192,2,192,4,192,5,192,12,192,14,192,15,192,7,192,9,192,10,192,17,192,19,192,20,0,51,0,57,0,50,0,56,0,10,192,3,192,13,192,8,192,18,0,22,0,19,0,9,0,21,0,18,0,3,0,8,0,20,0,17,0,255,1,0,0,64,0,11,0,4,3,0,1,2,0,10,0,52,0,50,0,14,0,13,0,25,0,11,0,12,0,24,0,9,0,10,0,22,0,23,0,8,0,...>>],...},...]},...} in gen_server:terminate/7 line 826

2015-12-22 15:31:00.787 [error] <0.109.0> Supervisor tls_connection_sup had child undefined started with {tls_connection,start_link,undefined} at <0.210.0> exit with reason no function clause matching ssl_handshake:update_handshake_history(undefined, <<1,0,0,175,3,1,86,121,221,42,209,19,198,53,3,42,92,9,16,158,197,5,169,29,247,96,14,32,123,176,...>>) line 450 in context child_terminated

We run OTP Erlang/OTP 18 [erts-7.2] with ssl-7.2, and the erlang side has the following options:

[{verify,verify_peer},
{certfile,"/home/.../device_cert.crt”},
{keyfile,"/home/.../device_key.pem”},
{cacertfile,"/home/.../root_cert.crt”},
{verify_fun,{#Fun<dlink_tls_conn.65.24728257>,{'RSAPublicKey’,...}}},
{partial_chain,#Fun<dlink_tls_conn.64.24728257>}]

Basically, the verify_fun validates a self-signed cert
https://github.com/PDXostc/rvi_core/blob/develop/components/dlink_tls/src/dlink_tls_conn.erl#L393

and the partial_chain fun most likely does much less than it should
https://github.com/PDXostc/rvi_core/blob/develop/components/dlink_tls/src/dlink_tls_conn.erl#L421

On the Android side, we’re using Android 4.4.2 (API 19).

It feels like a timing-related problem on the erlang side.

Let me know if you need more information.

BR,
Ulf W

_______________________________________________
erlang-bugs mailing list
erlang-bugs@REDACTED<mailto:erlang-bugs@REDACTED>
http://erlang.org/mailman/listinfo/erlang-bugs

--
Danil Zagoskin | z@REDACTED<mailto:z@REDACTED>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20151225/b74c8242/attachment.htm>