[erlang-questions] ssl timing issue in R15B?

Ingela Andin ingela@REDACTED
Mon Mar 26 15:16:29 CEST 2012


The problem is that your server and client needs to agree to upgrade
to SSL/TLS and your client may not start the handshake until the
server is ready to receive it. If you have a erlang-server this will
be when you have set your tcp-socket in passive mode.
When your server has set its socket in passive mode, you can ack to
the client that it is ready to start and then call ssl:ssl_accept with
the socket.
Otherwhise a quick clients  handshake may arrive to the inet driver
and be processed with socket options that the ssl-application has no
controll over. This may, depending on timing, result in that the
ssl-connection process recives data on an unexpected format. It could
also lead to that the some other process receives the handshake data
and if you are lucky it may work as expected ;)

Regards Ingela Erlang/OTP team - Ericsson AB

2012/3/26 Lukas P <lukasp.p017@REDACTED>:
> Dne 23. března 2012 18:16 Attila Rajmund Nohl
> <attila.r.nohl@REDACTED> napsal(a):
>> 2012/3/23 Lukas P <lukasp.p017@REDACTED>:
>>> Hello.
>>> I think that I have been hit by a SSL timing issue in R15B. My
>>> functional test (= SSL/TCP client) crahes my server unless the test
>>> contains a sleep.
>>> The tested server implements a TCP based, line oriented protocol.
>>> Switch to SSL can be started with a "STARTTLS\r\n" command.
>>> The functional test starts a TCP connection and upgrades it to SSL:
>>> upgrade_connection_to_ssl(Socket) ->
>>>    SendResult = gen_tcp:send(Socket, "STARTTLS\r\n"),
>>>    %timer:sleep(10), % workaround for a SSL timing bug
>>>    SslConnectResult = case SendResult of
>>>        ok ->
>>>            ssl:connect(Socket, [{active, false}, {packet, line}, list], 2000);
>>>        {error, Reason1} ->
>>>            {error, Reason1}
>>>    end,
>>>    ...
>>> After the server receives "STARTTLS\r\n", it performs ssl:ssl_accept
>>> on the socket:
>>>    inet:setopts(Socket, [{active, false}]),
>> Don't you need a {reuseaddr, true} option here? The default is false.
> Unfortunately not, the tcp socket is already connected.
> When you look at the walkback, you can see that there is definitely a
> bug in ssl_record:get_tls_records_aux/2 (erlang:size/1 must not be
> used on a list).
> Lukas
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list