[erlang-questions] ssl impas

Bogdan Andu bog495@REDACTED
Tue Oct 28 14:53:47 CET 2014

Hi Ingela,

Thank you for reply,

The packet was in raw format - the socket option: {packet , 0} - and I
tried to send the  packet formatted as:

ssl:send(Sock, <<0:8/unit:1, HeaderLen:32/big, DataBin/binary>>)

in order to let the Erlang tcp stack to strip the first byte.

That was better, in the sense that the length of the packet was what the
client expected but only for the first packet sent to it
from server. For subsequent packets the decoding problem persisted.

However, I updated that client to the latest version, and it is working
with R14 and R17 without adding first byte. In other words, the code:
ssl:send(Sock, <<HeaderLen:32/big, DataBin/binary>>)

works the same with both R14 and R17 with new client.

That's because the new client has put the fread(socket, length) in a
'while(!feof(socket))' construct allowing it to read the 1st byte and then
the other 3 bytes, constructing thus the 'header' of the packet correctly
accumulating all 4 bytes.

So, after all was a client problem, and their update fixed by accident my
problem also.

I was stubborn to make Erlang speak with a bad client (which is already
distributed to our end clients), altough I knew the fact that the client is
badly written.

The info you gave me was like a revelation and helped me to understand what
really is going on.

Thank you so much,


On Tue, Oct 28, 2014 at 1:18 PM, Ingela Andin <ingela.andin@REDACTED>

> Hi!
> It could have to do with that with the fact that the length argument is
> only relevant for raw sockets,
> and that in R15 we implemented 1/n-1 splitting countermeasure to the Rizzo
> Duong BEAST attack, which
> will split all packets to the into the first byte and the following bytes.
> Regards Ingela Erlang/OTP team - Ericsson AB
> 2014-10-28 10:50 GMT+01:00 Bogdan Andu <bog495@REDACTED>:
>> Hi folks,
>> sorry for  my problem but I am stuck after
>> turning it on every facet.
>> I have an application server that processes xml structures
>> with the following listen parameters:
>> {ok, ListenSock} = ssl:listen(Port, [binary,
>>                                                        {packet, 0}, % app
>> specific packaging
>>                                                         {active, false},
>>                                                         {ip, IPv4},
>>                                                         {mode, binary},
>>                                                         {certfile,
>> Certfile},
>>                                                         {cacertfile,
>> CACertfile},
>>                                                         {keyfile,
>> Keyfile},
>>                                                         {verify,
>> verify_none},
>> {fail_if_no_peer_cert, false},
>>                                                         {ssl_imp, new}
>>                 ]),
>> I have the following piece of code:
>> %% receiving part:
>> recv_frame_ssl(S, N, SslRecvTimeout) ->
>>         {ok, Header} = ssl:recv(S, 4, SslRecvTimeout),
>>         <<Length:32/big>> = Header,
>>         {ok, Data} = ssl:recv(S, Length - 4, SslRecvTimeout),
>>         <<Data1/binary>> = Data,
>>         {ok, binary_to_list(Data1)}.
>> %%and sending part - the problematic piece of code:
>> send_frame_ssl(Sock, Data) ->
>>         DataBin = unicode:characters_to_binary(Data),
>>         HeaderLen = erlang:size(DataBin) + 4,
>>         ssl:send(Sock, <<HeaderLen:32/big>>),
>>         ssl:send(Sock, <<DataBin/binary>>).
>> In R14B04 variable HeaderLen is encoded in network byte order correctly
>> and the client is able to extract the header and to read the rest of packet
>> which has (HeaderLen - 4) length in bytes.
>> In R15, R16 and R17 variable HeaderLen is no more encoded correctlty,
>> apparently, as the client receives a large value and is unable to extract
>> the correct length of the packet and hence, is not able to read the rest of
>> the packet which is xml payload.
>> For example, instead of receiving a HeaderLen with value 390 the client
>> receives a HeaderLen with value 189756.
>> I really don't know how to approach this problem and I am sure I miss
>> something obvious.
>> I tried different combination of HeaderLen encoding with no success
>> whatsoever.
>> Please shed some light on this as I am puzzled and I do not know what to
>> do.
>> Thank you,
>> Bogdan
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141028/e5874400/attachment.htm>

More information about the erlang-questions mailing list