Issue metadata
Sign in to add a comment
|
WebSocket with TLS not working (tested with websocketstest.com)
Reported by
kishanpa...@gmail.com,
Dec 14 2016
|
||||||||||||||||||||
Issue descriptionTHIS TEMPLATE IS FOR FILING BUGS ON THE ANDROID SYSTEM WEBVIEW. GENERAL WEB BUGS SHOULD BE FILED USING A DIFFERENT TEMPLATE! Device name: Nexus 6 Android version: 7.0 WebView version (from system settings -> Apps -> Android System WebView): 56.0.2924.23 Application: Chrome Beta Application version: 56.0.2924.23 URLs (if applicable): https://websocketstest.com/ Steps to reproduce: (1)Go to the URL above (2)Let the test run to test your Browser (3)See the resutls Expected result: The test should pass as it does for WebView 54. See screenshot. Actual result: The test fails for WebView 56. See screenshot Let me know if you need any more details.
,
Dec 14 2016
,
Dec 15 2016
The problem is not specific to Android WebView, the results were the same for WebView client and a stand-alone Chrome app. Removing component Mobile>WebView.
,
Dec 15 2016
,
Dec 15 2016
Did bisection between r423768 and r438775 because it works with 55.0.2883.75 (whose branch base r423768), but got bad for all bisection points. Maybe some merge has been made for the release branch to get it fixed? Did bisection again in the range between r414607 (picked from revisions for M54) and r423768, and saw that wss got broken on BoringSSL roll on r416038. I have no idea why it's still broken on ToT. Another independent breakage happened? Adding SSL label.
,
Dec 15 2016
,
Dec 15 2016
,
Dec 15 2016
,
Dec 15 2016
Looks like wss.websocketstest.com is broken. Specifically, it is intolerant to unknown signature algorithms in TLS. The reason you're seeing a confusing range is because we backed RSA-PSS out of M55, but it will be shipping in M56. These kinds of broken servers are toxic to the ecosystem and *must* be fixed whenever the breakage impact is low enough for this to be remotely feasible. Otherwise we can't deploy anything. (Imagine if there were an HTTP server that broke on unknown headers. We could never deploy a new HTTP header ever again. That's exactly what this server is doing for TLS.) In particular, this server is running an old version of Erlang's TLS stack that's missing these fixes: https://github.com/erlang/otp/commit/ae7347bfdcab2486bb55dfe54918a0c994d8b7c7 https://github.com/erlang/otp/commit/0b19d46eaa4e4cf40be51acca9760c8f969638f2 Do we have contacts with whoever runs that site? It should be as simple as updating the server software; going by the dates of those bugfixes, it's been more than a year since they last updated.
,
Dec 15 2016
(Er, removing Needs-Feedback. Started asking for net-internals and then figured out the problem without it.)
,
Dec 15 2016
At the bottom of the site it says the test was created by Mikhail Platov//support@godvillegame.com
,
Dec 15 2016
Thanks! I'll send them an email. (For reference so I don't have to look it up next time: the Erlang versions with the fix are Erlang OTP 17.5.6.5 or later. 17.5.6.5 was released in December 2015.)
,
Dec 15 2016
The site's now been fixed, so we don't need to do anything. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Dec 14 2016