Web sockets are temporarily canceled.
Exactly one year ago, on December 9, 2009, Google Chrome developers excited the public by announcing the introduction of support for web sockets in future versions of Chrome. About what is Web Sockets and what it gives, see almost yearling post on Habré .
Web sockets are really tasty.
From the point of view of web standards, Web Sockets is a separate specification that was removed from the HTML5 specification even in spring 2009 for further study within the web applications working group (WebApps WG). The document is currently in the Working Draft state.
')
An interesting feature of web sockets is that it is not just an API in the browser: the mechanism of web sockets is tied to the appropriate protocol - the WebSocket Protocol , developed as part of the IETF , and requires the appropriate support from the server. The current draft version is 03 (October 17), before that there were 76 more revisions. Since the last one at the beginning of the summer there was an unpleasant story when a new revision turned out to be incompatible with the old one .
Support for web sockets was announced in Chrome and Safari, and also, as I understand it, should have been available in preliminary versions of Opera 10.70-11 and Firefox 4b. (Ok, it’s obvious that IE9 isn’t on this list, however, in fairness: the developers have repeatedly stated that they are introducing stable and well-established things that will not lead to reverse incompatibilities in a few months.)
The protocol, as well as the standard, is still being finalized. And in fact, it’s good that it was taken out of HTML5, since it allows you to work out and stabilize independent chunks separately, rather than mix up markup and API for web applications in JavaScript.
In late November, Adam Barth published the results of a study on the reliability of the protocol used. It turned out that the protocol used is subject to serious vulnerabilities:
(In Russian, this means that in the case of using transparent (regular) proxy servers, it is possible to replace the cache of transmitted data so that users will receive a version of the data from the attacker instead of real data.)
Read more here http://www.adambarth.com/experimental/websocket.pdf
Obviously, the protocol will be finalized and now quite a heated discussion can be observed on the mailing list.
The revealed problem turned out to be quite serious so that the developers of Firefox and Opera announced that until the problems are fixed in future versions of their browsers, support for web sockets will be closed . In Firefox, support will be closed starting with version FF4b8. Comment from Opera, see here .
At the moment and until the problems with the protocol are fixed, this is the reverse incompatibility of new versions. That is, with the release of browser updates, current WebSocket solutions will simply stop working. The catch still lies in the fact that although the standard being developed and the corresponding protocol are only in draft form, from the point of view of implementation and support in browsers, it is not designated as experimental and is likely to change and at the same time is actively promoted.
However, I would like to hope that if you used web sockets, you did feature support checking (feature detection) and you had a branch in case there is no window.WebSocket property.
It is important to emphasize that this is not a problem for browsers, namely, the protocol used. And, by the way, vulnerabilities in it also affect Java and Flash, so we are waiting for the reaction from Oracle and Adobe.
ps On the topic of the day - a small movie on quotes from blogs Google and Firefox.
Web sockets are really tasty.
From the point of view of web standards, Web Sockets is a separate specification that was removed from the HTML5 specification even in spring 2009 for further study within the web applications working group (WebApps WG). The document is currently in the Working Draft state.
')
An interesting feature of web sockets is that it is not just an API in the browser: the mechanism of web sockets is tied to the appropriate protocol - the WebSocket Protocol , developed as part of the IETF , and requires the appropriate support from the server. The current draft version is 03 (October 17), before that there were 76 more revisions. Since the last one at the beginning of the summer there was an unpleasant story when a new revision turned out to be incompatible with the old one .
Support for web sockets was announced in Chrome and Safari, and also, as I understand it, should have been available in preliminary versions of Opera 10.70-11 and Firefox 4b. (Ok, it’s obvious that IE9 isn’t on this list, however, in fairness: the developers have repeatedly stated that they are introducing stable and well-established things that will not lead to reverse incompatibilities in a few months.)
The protocol, as well as the standard, is still being finalized. And in fact, it’s good that it was taken out of HTML5, since it allows you to work out and stabilize independent chunks separately, rather than mix up markup and API for web applications in JavaScript.
What happened?
In late November, Adam Barth published the results of a study on the reliability of the protocol used. It turned out that the protocol used is subject to serious vulnerabilities:
This is an upgrade-based handshake (or intercepting) proxies.
We found that for a $ 100, we’ve been able to use the upgrade-based handshake. When the attacker has been able to endorse with the consequences. For example, the attacker can check out for http://www.google-analytics.com/ga.js and inject JavaScript for approximately 57% of the top 10,000 web sites .
(In Russian, this means that in the case of using transparent (regular) proxy servers, it is possible to replace the cache of transmitted data so that users will receive a version of the data from the attacker instead of real data.)
Read more here http://www.adambarth.com/experimental/websocket.pdf
Obviously, the protocol will be finalized and now quite a heated discussion can be observed on the mailing list.
The revealed problem turned out to be quite serious so that the developers of Firefox and Opera announced that until the problems are fixed in future versions of their browsers, support for web sockets will be closed . In Firefox, support will be closed starting with version FF4b8. Comment from Opera, see here .
What does this mean for developers?
At the moment and until the problems with the protocol are fixed, this is the reverse incompatibility of new versions. That is, with the release of browser updates, current WebSocket solutions will simply stop working. The catch still lies in the fact that although the standard being developed and the corresponding protocol are only in draft form, from the point of view of implementation and support in browsers, it is not designated as experimental and is likely to change and at the same time is actively promoted.
However, I would like to hope that if you used web sockets, you did feature support checking (feature detection) and you had a branch in case there is no window.WebSocket property.
It is important to emphasize that this is not a problem for browsers, namely, the protocol used. And, by the way, vulnerabilities in it also affect Java and Flash, so we are waiting for the reaction from Oracle and Adobe.
ps On the topic of the day - a small movie on quotes from blogs Google and Firefox.
Source: https://habr.com/ru/post/109733/
All Articles