1176176 - websocket sends corrupted inflated data

Status: RESOLVED INVALID

(Core :: Networking: WebSockets, defect)

Description

[daef]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150618004006

Steps to reproduce:

I open a websocket and send a few bytes, on the receiving end, after deflating, the data is sometimes (but somehow determinisically) corrupted.

e.g.
first send "WRITEFILE"
then send "test.txt"
then send "testyucrap"

I wrote a little test-page that reproduces the problem: http://mnml.is/wsfail/

tested with current stable (38.0.5) and aurora (40.0a2 (2015-06-18))

the data survives if I set network.websocket.extensions.permessage-deflate to false.

when i substitute the third string with some variations there seems no obvious pattern to me..:

what i send -> what i receive (after deflating)

test        ->              \0\0\0\0
tes test       ->           \0\0\0 \0\0\0\0
te tes test     ->          te \0\0\0 \0\0\0t
tte tes test      ->        tte \0\0\0 \0\0\0t
this is another test!  ->   this is another \0\0\0\0!
t te tes test   ->          t te tes test
tes tes te       ->         \0\0\0 \0\0\0 \0\0
testyucrap      ->          \0\0\0\0yucrap


Actual results:

the first two strings survive, but the third strings first 4 bytes are substituted with null-bytes.

e.g.
received (after deflating)
"WRITEFILE"
"test.txt"
"\0\0\0\0yucrap"


Expected results:

the strings should resemble the original data.

Comment 1

[daef]

just tried against ws://echo.websocket.org ... they do not set
Sec-WebSocket-Extensions: permessage-deflate so everything works as expected...

Comment 2

[daef]

Attachment: fiddler captured bytes deflated with .net reveal corrupted data

Comment 3

[daef]

current chrome (43.0.2357.124 m) seems to behave exactly the same way as firefox on this one.

Comment 4

[daef]

Attachment: captured websocket frames

Comment 5

[Patrick McManus [:mcmanus]]

I appreciate the test case.. hopefully Michal can have a look and see if what you're sending meets with our interpretation of the spec or not..

Comment 6

[Michal Novotny [:michal]]

The deflated messages are correct. Let's take a zlib header (0x78 0x9C) then append all messages from the pcap file (with added 0x00 0x00 0xFF 0xFF) and pipe it e.g. to "openssl zlib -d". It returns "WRITEFILEtest.txttestyucrap".

The server is buggy. It is obvious from what's missing in the third decoded message that the server doesn't keep LZ77 sliding window between messages but it doesn't announce it by sending client_no_context_takeover parameter in the handshake.

Also, although it isn't required by the specification, I would expect that the server fails the connection when it receives a compressed message that fails to inflate correctly.

Comment 7

[daef]

Okay, than I guess the .Net DeflateStream is broken :)

Comment 8

[Michal Novotny [:michal]]

(In reply to daef from comment #7)
> Okay, than I guess the .Net DeflateStream is broken :)

No, it's just how it is used. In your screenshot (attachment 8624649 [details]), new DeflateStream object is created for every message, so no sliding window is maintained. Just use a single DeflateStream object for all messages and you should get a correct result.

I'm not sure what's wrong with websocket-sharp server. It does the same but it's intentional and client_no_context_takeover should be added to the handshake response in processSecWebSocketExtensionsHeader method. But the parameter isn't present in the response in the pcap file.