-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hixie 76 handshake chop bug #101
Comments
Hi ! I have some news about this issue :) 2012-04-11T16:24:31 [16] Full Key3 not found in first chop I hope this information is useful. P.S. -77: const std::string &key3 = request.header("Sec-WebSocket-Key3"); and 64: char key_final[16]; because valgrind destroy my brain by those huge warnings |
It turned out that there were two bugs. One was fixed (key3 with 0x00 bytes getting truncated by md5), the other was split out into this issue. What is happening here is that the key3 in Hixie 76 is included after the HTTP headers. WS++ as originally written reads until the packet that contains the header delimiter. If the packet that contains the header delimiter also contains the 8 byte key3 afterwards then everything works. If the key3 after the delimiter is split across two packets then only the part in the first packet is read and the partial key is not sufficient to complete the handshake. The first issue was an easy fix and is done. This one is more complicated as it requires fairly significant changes to how handshakes are initially read, something I was planning on doing anyways to improve security in certain hostile handshake cases, but not something I was planning on needing to fix this soon. =) I hope get to this in the next week or two now that it is clear that it breaks for some popular clients. The "[16] Full Key3 not found in first chop" log error is my new specific error message for "this known bug happened" |
Thanks for comprehensive explanation |
Hello Peter, |
For what it is worth, WebKit nightly fully supports RFC6455, so I expect the next major release of iOS and desktop Safari will have that. Unfortunately there will be quite a set of legacy hardware potentially stuck on this protocol that never should have been shipped. |
the latest commit has two fixes. The first is activated by default, if you two could test this (with log::elevel::RERROR set if possible) and let me know if the first fix works that would be great. I haven't been able to induce a 76 handshake failure yet. |
After new version pulling error log contain only one message: And valgrind print this warning:
|
Using my iPod I get the same error log message. |
Hi! After connecting error log contain this line "Error reading HTTP request. code: asio.misc:2" and valgrind trace is still the same:
|
the fix above is probably not related to the core issue here, but there was another bug that caused certain types of valid Hybi00 frames to fail the utf8 validation tests resulting in immediate disconnects. Let me know if this helps with the more recent "iOS devices can't exchange of any data with WS++ server." issue. I've done some basic testing and my iOS devices seem to work again now. |
Thanks a lot! Now old behaviour is reproduced (5-10 reconnects). |
Closing issues related to 0.2.x branch that wont be fixed. |
WS++ will fail with a 500/internal server error if the Hixie 76 handshake does not include all 8 bytes in the ASIO read that includes the \r\n\r\n ending the headers. Fixing this requires a switch to a more complicated incremental handshake reader.
The text was updated successfully, but these errors were encountered: