<div dir="ltr">Hi, Ingela.<div><br></div><div>I finally had some time for investigating this problem.</div><div><br></div><div>I didn't see badarg in erlang:size again, but it definitely appeared in 17.0 with simple accept method described as minimal example at <a href="http://www.erlang.org/doc/apps/ssl/using_ssl.html">http://www.erlang.org/doc/apps/ssl/using_ssl.html</a> (the difference was transport_accept and ssl_accept were run in separate process)</div>
<div><br></div><div><br></div><div>Today I met some new crash:</div><div><div>** {{badmatch,{alert,2,20,{"ssl_cipher.erl",215}}},</div><div> [{tls_record,decode_cipher_text,2,[{file,"tls_record.erl"},{line,157}]},</div>
<div> {tls_connection,next_record,1,[{file,"tls_connection.erl"},{line,503}]},</div><div> {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,475}]},</div><div> {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,503}]},</div>
<div> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}</div></div><div><br></div><div>That's because ssl_record:decipher/3 may return #alert{}, but tls_record:decode_cipher_text/2 isn't expecting that.</div>
<div><br></div><div><br></div><div><br></div><div>As for {case_clause,{4}} in ssl_v3:mac_hash/3 I found that precondition for crash is easily reproducible: <a href="https://gist.github.com/stolen/10780653">https://gist.github.com/stolen/10780653</a></div>
<div>Ordinary servers negotiate with sha hash or close socket while ssl in 17.0 negotiates with sha256 hash.</div><div>I don't know the protocol good enough to perform further states, but I hope this helps.</div><div>
<br></div><div>Unfortunately, I don't understand how this code should be tested — most of functions require #state{} or #connection_states{} which require #ssl_options{} and other stuff, and at I have found no exported function creating #ssl_options{} without side-effects.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-15 16:52 GMT+04:00 Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello again!<br><div><div class=""><div class="gmail_extra"> <div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
sometimes badarg in erlang:size([22,3,1,0,158,1,0,0,154,3,1,83,74|...]) at tls_record.erl:122.<br></div></blockquote></div><br></div></div><div class="gmail_extra">Same symptom was recently reported on erlang-bugs and it turned out to be due to upgrading a gen_tcp socket in active mode. When upgrading a gen_tcp socket to an ssl socket it must be put in passive mode ({active, false}) before the client<br>
</div><div class="gmail_extra">is allowed to start the handshake. Normaly if the upgrade is negotiated this is not a problem for the server to set the option<br></div><div class="gmail_extra">before signaling to the client to go ahead with the handshake. If the upgrade is only performed on the server side instead of calling the ssl API ( some people may do that due to the previously lack of possibility to specify ssl options when calling
ssl:ssl_accept with an "sslsocket", this is no longer the case in 17.0) the listen socket needs to be put in passive mode (listen options are inherited by the acceptsocket) to make sure that the it will work, otherwhise it will work sometimes and sometime result in the error above.
</div><div class=""><div class="gmail_extra"><br></div><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB<br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div><font face="'courier new', monospace">Danil Zagoskin | <a href="mailto:z@gosk.in" target="_blank">z@gosk.in</a></font></div></div>
</div>