[erlang-questions] ssl impas

Ingela Andin ingela.andin@REDACTED
Tue Oct 28 12:18:54 CET 2014


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/ac35f834/attachment.htm>


More information about the erlang-questions mailing list