[erlang-bugs] stray message sent by remote closure of passive ssl sockets

[Matthias Radestock]

There is a bug in the handling of remote connection closure of 
{active,false} ssl sockets. It is present in at least R15B01 and R15B.

Eshell V5.9.1  (abort with ^G)
1> ssl:start().
ok
2> {ok, S} = ssl:connect("www.google.com", 443, [{active,false}]).
{ok,{sslsocket,new_ssl,<0.48.0>}}
3> ssl:send(S, <<"BANG\n\n">>).
ok
4> ssl:recv(S, 0).
{ok,"HTTP/1.0 400 Bad Request\r\nContent-Type: text/html;
charset=UTF-8\r\nContent-Length: 925\r\nDate: Mon, 11 Jun 2012 19:19:52
GMT\r\nServer: GFE/2.0\r\n\r\n"}
5> ssl:recv(S, 0).
{ok,[60,33,68,79,67,84,89,80,69,32,104,116,109,108,62,10,60,
      104,116,109,108,32,108,97,110,103,61|...]}
6> ssl:recv(S, 0).
{error,closed}
7> flush().
Shell got {#Ref<0.0.0.51>,{error,closed}}
ok

The shell process should not have received that last message.

Poking around ssl_connection.erl and doing some tracing, I reckon what 
is happening is that handle_normal_shutdown pays no attention to 
#state.recv_from and instead calls alert_user with the value of 
#state.from, which is the gen_fsm reply destination from the handshake 
phase of ssl_connection:connect. So the ssl_connection sends a gen_fsm 
reply to the process that invoked ssl:connect, even though that process 
has long since moved past that point. That explains the stray message 
above. But why did the last ssl:recv still return {error,closed}? 
Because the ssl_connection process terminates normally, which is caught 
in sync_send_all_state_event and converted into {error,closed}.


Regards,

Matthias.