[erlang-questions] SSL behavior!?

Ingela Andin <>
Thu Aug 16 09:04:32 CEST 2012


Hi!

This behaviour is a security counter measure, 1/n-1 splitting
countermeasure Rizzo/Duong-Beast, RC4 chiphers are not vulnerable to
this attack so if you use an RC4-cipher suite it will not happen but
for the other cipher suites you will have to live with it until
TLS-1.1 is supported.

Regards Ingela Erlang/OTP team - Ericsson AB

2012/8/16, dmitry kolesnikov <>:
> Hello,
>
> Yes for sure, you have to deal with IP fragmentation. But, like I said
> in my post fragmentation happens on SSL level, two distinguished "App
> Data" frames where generated and those frames were put into single
> packet.
>
> I would not raise an issue if I would observe a fragmentation on large
> dataset but for 16 byte packet looks suspicious for me, especially of
> first fragment is one byte... I've not seen that issue on R14, it pops
> up when I jumped to R15 and made slight adjustments my code.
>
>
> Best Regards,
> Dmitry >-|-|-*>
>
>
> On 15.8.2012, at 23.38, "Loïc Hoguin" <> wrote:
>
>> Hey,
>>
>> The same can happen for gen_tcp. You can't assume what you are sending
>> isn't going to be fragmented when you receive it, packets have a size
>> limit (MTU). You need to either know how much data you are waiting for,
>> or try to parse it to validate it got received fully before processing
>> it.
>>
>> On 08/15/2012 09:50 PM, Dmitry Kolesnikov wrote:
>>> Hello,
>>>
>>> I am experience very wired behavior with SSL in R15... So, I do have both
>>> client & server implemented on erlang, using ssl in active mode.
>>>
>>> The implementation is straight forward it
>>>
>>> Client-side:
>>> {ok, Tcp} = gen_tcp:connect(Host, Port, ?SOCK_OPTS, T),
>>> {ok, Ssl}  = ssl:connect(Tcp,  []),
>>>
>>> Server-side:
>>>    {ok, LSock} = ssl:listen(Port, [
>>>           {ip, IP},
>>>        {certfile, Cert},
>>>        {keyfile,  Key},
>>>        {reuseaddr, true} | ?SOCK_OPTS
>>>    ]),
>>>    ...
>>>    {ok, Sock} = ssl:transport_accept(LSock),
>>>    ok = ssl:ssl_accept(Sock),
>>>
>>>
>>> -define(SOCK_OPTS, [
>>>    {active, once},
>>>    {mode, binary},
>>>    {nodelay, true},  %% BTW, if I drop nodelay or put it to false, same
>>> issue
>>>    {recbuf, 16 * 1024},
>>>    {sndbuf, 16 * 1024}
>>> ]).
>>>
>>>
>>> My issue is that client send data, the data got fragmented into multiple
>>> "Application Data" messages. I've been validating it by sniffing the
>>> traffic. I cannot get idea why this happens...
>>>
>>> Client log:
>>> 22:34:54.948 [info] ssl connected {{127,0,0,1},8443}, local addr
>>> {{127,0,0,1},53804}, suite {tlsv1,{dhe_rsa,aes_256_cbc,sha}}
>>> 22:34:54.948 [debug] ssl send {{127,0,0,1},8443} <<"0123456789abcdef">>
>>>
>>> Server log:
>>> 22:34:54.948 [info] ssl accepted {{127,0,0,1},53804}, local addr
>>> {{127,0,0,1},8443}, suite {tlsv1,{dhe_rsa,aes_256_cbc,sha}}
>>> 22:34:54.949 [debug] ssl recv {{127,0,0,1},53804} <<"0">>
>>> 22:34:54.949 [debug] ssl recv {{127,0,0,1},53804} <<"123456789abcdef">>
>>>
>>> thanks in advanced,
>>> Best Regards, Dmitry
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>> --
>> Loïc Hoguin
>> Erlang Cowboy
>> Nine Nines
>> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list