[erlang-questions] Errors in SSL handshake (weird client)

[Danil Zagoskin]

Hi, Ingela.

I finally had some time for investigating this problem.

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
http://www.erlang.org/doc/apps/ssl/using_ssl.html (the difference was
transport_accept and ssl_accept were run in separate process)


Today I met some new crash:
** {{badmatch,{alert,2,20,{"ssl_cipher.erl",215}}},
    [{tls_record,decode_cipher_text,2,[{file,"tls_record.erl"},{line,157}]},

 {tls_connection,next_record,1,[{file,"tls_connection.erl"},{line,503}]},
     {tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,475}]},
     {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,503}]},
     {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]}

That's because ssl_record:decipher/3 may return #alert{}, but
tls_record:decode_cipher_text/2 isn't expecting that.



As for {case_clause,{4}} in ssl_v3:mac_hash/3 I found that precondition for
crash is easily reproducible: https://gist.github.com/stolen/10780653
Ordinary servers negotiate with sha hash or close socket while ssl in 17.0
negotiates with sha256 hash.
I don't know the protocol good enough to perform further states, but I hope
this helps.

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.



2014-04-15 16:52 GMT+04:00 Ingela Andin <ingela.andin@REDACTED>:

> Hello again!
>
>
>>  sometimes badarg in erlang:size([22,3,1,0,158,1,0,0,154,3,1,83,74|...])
>> at tls_record.erl:122.
>>
>
> 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
> is allowed to start the handshake.  Normaly if the upgrade is negotiated
> this is not a problem for the server to set the option
> 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.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>



-- 
Danil Zagoskin | z@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140416/7059cf03/attachment.htm>