[Bug] OpenSSL does not send short messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Yes you are correct. I'm doing things wrong - it seems to be Chrome and
Curl that report "no received data" because it actually does work in
Firefox. Well, thanks for taking the time.

2016-04-26 7:05 GMT+02:00 Alex Hultman <alexhultman at gmail.com>:

> Yes you are correct. I'm doing things wrong - it seems to be Chrome and
> Curl that report "no received data" because it actually does work in
> Firefox. Well, thanks for taking the time.
>
> 2016-04-26 6:55 GMT+02:00 Viktor Dukhovni <openssl-users at dukhovni.org>:
>
>> [ This question belongs on openssl-users, not openssl-dev.  Please
>>   reply only to openssl-users. ]
>>
>> On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote:
>>
>> > SSL_write followed by SSL_shutdown does not actually send the data
>> passed
>> > to SSL_write if the total data size sent is less than (on my system) 7-8
>> > bytes.
>>
>> This does not happen in "openssl s_client".  You're likely doing
>> something wrong.
>>
>> In one window I start an openssl server:
>>
>>     $ cipher=ADH-DES-CBC3-SHA
>>     $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or
>> later
>>     $ openssl s_server -quiet -cipher "$cipher$seclev" -nocert -accept
>> 12345
>>
>> I another window I start a client:
>>
>>     $ cipher=ADH-DES-CBC3-SHA
>>     $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or
>> later
>>     echo XXX | openssl s_client -debug -no_ign_eof -cipher
>> "$cipher$seclev" -connect localhost:12345
>>
>> On the server side I see the expected output:
>>
>>     XXX
>>
>> On the client side after lots of handshake messages:
>>
>>     >>> ??? [length 0005]
>>         17 03 03 00 24
>>     write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
>>     0000 - 17 03 03 00 24 c2 19 ea-c6 f1 a8 c7 74 31 50 3d
>>  ....$.......t1P=
>>     0010 - a1 2f fb f0 d5 4d 2e 85-e0 6a 18 86 27 6a 09 1d
>>  ./...M...j..'j..
>>     0020 - de 98 4e 69 05 57 0f 4c-93                        ..Ni.W.L.
>>     DONE
>>     >>> ??? [length 0005]
>>         15 03 03 00 24
>>     write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
>>     0000 - 15 03 03 00 24 d2 94 f8-11 dd 69 81 f7 ab cc 8c
>>  ....$.....i.....
>>     0010 - c4 13 4c 80 24 d7 50 10-b9 62 74 d7 21 86 16 78
>>  ..L.$.P..bt.!..x
>>     0020 - b4 83 87 da 5e 2f d9 5d-34                        ....^/.]4
>>     >>> TLS 1.2Alert [length 0002], warning close_notify
>>         01 00
>>
>> The first of these is the "XXX" encrypted to 16 bytes, and padded
>> with a 20-byte SHA1 MAC (the server and client negotiated TLS 1.2
>> with Encrypt-then-Mac).  The second is the encrypted shutdown alert.
>>
>> > Is this known behavior?
>>
>> No.
>>
>> --
>>         Viktor.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/5f883619/attachment-0001.html>


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux