On 9/22/18 1:34 AM, Chet Ramey wrote:
> On 9/21/18 4:13 PM, dirk+b...@testssl.sh wrote:
>>
>> Hello there,
>>
>> we discovered a strange phenomenon in the project testssl.sh:
>>
>> After opening a TCP socket with a fd (here: 5), when writing to it,
>> it seems that
>>
>> printf -- "$data" >&5 2>/dev/null
>>
>> does not do what it is intended. "$data" is a ClientHello like
>>
>> '\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...'
>>
>> Each \x0a like the last one causes a new TCP fragment to begin which can be
>> easily
>> spotted when using wireshark while running e.g.
>
> Newline? It's probably that stdout is line-buffered and the newline causes
> a flush, which results in a write(2).
Anything one can do on the level of bash or non-syscall land? What about
ulimit -b ?
>> If there's a workaround, please let me know. (tried to add "%b" with no
>> effect). Otherwise I believe it's a bug.
>
> How? Does the emitted output not correspond to what's passed to printf
> in some way?
"\x0a" is a legitimate byte which is send from time to time over the
socket. It happens if the record layer is e.g. 522 bytes (\x02\x0a), if
a standard cipher is included in the handshake like (\xc0\x0a) or DES-CBC3-SHA
(\x00\x0a) ECDHE-ECDSA-AES256-SHA or at any other occasion.
Everything works as expected and like a charm for years now -- the only thing
isthe
underlying TCP fragmentation which is caused as a side effect by sending
\x0a.
As indicated a few servers under certain condition can't cope with it asif the
TCP
first segment is too small they don't treat this as ClientHello
and just drop the packet, see thread @
https://github.com/drwetter/testssl.sh/pull/1113, specifically the hint wrt
https://support.f5.com/csp/article/K53322151 .
My stance is simply if I use in the internal feature of bash for TCP socket
programming I didn't expect to have side effects like this.
Thx, Dirk
