[erlang-bugs] R16B03-1: ssl application crashes when a server emits an unrecognized_name(112) alert

[Masatake Daimon]

Hello,

I found the ssl application in R16B03-1 crashes when a server emits an
unrecognized_name(112) alert. If the alert is fatal,
ssl_alert:description_txt/1 crashes. And if it's a warning,
tls_connection:handle_alert/3 crashes:

> % erl
> Erlang R16B03-1 (erts-5.10.4) [source] [64-bit] [smp:2:2] [async-threads:10] [hipe] [kernel-poll:false]
>
> Eshell V5.10.4  (abort with ^G)
> 1> inets:start(). ssl:start(). inets:start(httpc, [{profile, test}]).
> ok
> 2> ssl:start(). inets:start(httpc, [{profile, test}]).
> ok
> 3> inets:start(httpc, [{profile, test}]).
> {ok,<0.61.0>}
> 4> httpc:request("https://localhost/", test).
>
> =ERROR REPORT==== 14-Mar-2014::18:23:56 ===
> ** State machine <0.67.0> terminating
> ** Last message in was {tcp,#Port<0.2726>,
>                             <<21,3,3,0,2,1,112,22,3,3,0,53,2,0,0,49,3,3,83,34,
> ...
> ** Reason for termination =
> ** {function_clause,
>        [{tls_connection,handle_alert,
>             [{alert,1,112,{"tls_connection.erl",375}},
>              hello,
>              {state,client,
>                  {#Ref<0.0.0.69>,<0.63.0>},
>                  gen_tcp,tls_connection,tcp,tcp_closed,tcp_error,"localhost",
>                  443,#Port<0.2726>,
>                  {ssl_options,undefined,
> ...

The alert in question is unrecognized_name(112) at warning(1)
level. RFC 6066 [*1] is indeed saying that a server is NOT RECOMMENDED
to send a warning-level unrecognized_name(112) alert, because the
client's behavior in response to warning-level alerts is
unpredictable. But tls_connection:handle_alert/3 should not crash
nonetheless.

Should SNI be enabled by default? Maybe. Then what should happen if a
server emits unrecognized_name? I think the following scheme is the
most appropriate:

   1. If the alert is fatal, the connection must be immediately closed
      according to RFC 5246 [*2]. And this is the current behavior of
      tls_connection:handle_alert/3 (while ssl_alert:description_txt/1
      crashes with function_clause due to an unmatched pattern).

   2. If it is a warning, we should only log it
      (tls_connection:log_alert/3) and proceed the handshake. In this
      case the requested host name and the server certification will be
      likely to disagree so the connection will be aborted if {verify,
      verify_peer} is given.


*1: http://tools.ietf.org/html/rfc6066#section-3
*2: http://tools.ietf.org/html/rfc5246#section-7.2.2


Thanks,
-- 
大門 正岳 <daimon@REDACTED>