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

[Ingela Andin]

Hi!

Thank you for the pull requests we are working on including them, probably
with some own additions to 340. More info will come on the pull requests
later.


2014-04-20 1:52 GMT+02:00 Danil Zagoskin <z@REDACTED>:

> Hello again!
>
> function_clause in tls_connection:handle_tls_handshake is fixed in this
> PR: https://github.com/erlang/otp/pull/339
>
> One more crash (badarg in crypto:sign) is fixed in that PR:
> https://github.com/erlang/otp/pull/340
>
> For other ssl users: these two patches with two Ingela's patches:
>  -
> https://github.com/IngelaAndin/otp/commit/7f0e683bc483b70f05fa806539bd5c540943dfd0
>  -
> https://github.com/IngelaAndin/otp/commit/26082cdd64823ecf92c47188f5a161e5ff2f8660
> seem to fix most of ssl server crashes in OTP 17.0.
>
>
>>
[...]


>
>>> Could that client work with other server implementation?
>>> tls_handshake_buffer seems like a garbage (but I'm not sure), so maybe
>>> here's no valid client lost.
>>>
>>> Should server tolerate such conditions? Should an alert be thrown
>>> when tls_handshake:get_tls_handshake returns {[], _}?
>>>
>>>

In general we do program for the correct case, but yes we want to make the
server fault tolerant and we do use "try" and  sometimes "catch all
clauses" to stop gracefully and send
alerts.

 [...]

Another question about crashes:
>>> Maybe tls_connection is a good place for format_status/2? It may be a
>>> good idea to hide secrets when printing state (otherwise a person which has
>>> access to error logs seems to be able to restore the private key or
>>> decipher dumped traffic).
>>>
>>>

Point taken I will create a ticket for this.
[...]


>>>>>>
>>>>>>
>>>>>> My interpretation:
>>>>>>   - Given pool size X, the first of each X requests fails.
>>>>>>   - First of failing requests catches timeout as expected, other ones
>>>>>> just stall.
>>>>>>   - Failing requests have emulated options [{mode, list}, {active,
>>>>>> true}] while working ones have the opposite [{mode, binary}, {active,
>>>>>> false}].
>>>>>>
>>>>>> After couple of further experiments I discovered that only every (X*N
>>>>>> + 1)th acceptor inherits listening socket options, other ones always have
>>>>>> [{mode, binary}, {active, false}].
>>>>>>
>>>>>>

Humm .... this has to do with inheritance of socket options from listen
socket to accept socket and the fact that some socket options need to be
emulated, and how its is implemented. The current implementation will not
work for a pool of listen sockets.  I have not had time solve this problem
yet but it is on the todo list.


Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140423/c19a9a0d/attachment.htm>