Websockets blocked ports

[matzipan]

I am wondering, why wouldn't the browsers just launch a warning and
ask for permission when a script tries to access a blocked websocket
port? I mean like, websockets is a great feature of html5, why just
restrict it? It blocks the development of web apps in the real sense.

[Fumitoshi Ukai (鵜飼文敏)]

I think it just blocks other well-known port to prevent cross protocol attacks.

  http://trac.webkit.org/browser/trunk/Source/WebCore/websockets/WebSocket.cpp#L143

  http://trac.webkit.org/browser/trunk/Source/WebCore/platform/KURLGoogle.cpp#L819

Why do you think it blocks the development?

-- 

ukai

--
You received this message because you are subscribed to the Google Groups "Chromium HTML5" group.
To post to this group, send email to chromiu...@chromium.org.
To unsubscribe from this group, send email to chromium-html...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-html5/?hl=en.

[Zisu Andrei]

Wouldn't it be more in the sense of real Web apps if the sockets wouldn't be restricted, at least regarding IMAP/POP3/SMTP/FTP/IRC even SSH/SFTP/LDAP? I am suggesting not blocking the ports, but asking for permission, in a fashion similar to facebook or the web notifications implementation.

What I understood from http://www.kb.cert.org/vuls/id/476267, was that the reason of the restriction is that users can actually access those services? It's a similar logic to : oh well native apps access services, why not restrict them ?

2011/1/19 Fumitoshi Ukai (鵜飼文敏) <uk...@chromium.org>

[Fumitoshi Ukai (鵜飼文敏)]

On Wed, Jan 19, 2011 at 17:47, Zisu Andrei <matz...@gmail.com> wrote:

Wouldn't it be more in the sense of real Web apps if the sockets wouldn't be restricted, at least regarding IMAP/POP3/SMTP/FTP/IRC even SSH/SFTP/LDAP? I am suggesting not blocking the ports, but asking for permission, in a fashion similar to facebook or the web notifications implementation.

WebSocket is not designed to be used for such services.   Note that WebSocket is not raw socket and, even if not blocking port, basically not possible to talk such protocol.

If these protocol is really useful for Web apps, browser should provide native API for such protocol, I think.

 

What I understood from http://www.kb.cert.org/vuls/id/476267, was that the reason of the restriction is that users can actually access those services? It's a similar logic to : oh well native apps access services, why not restrict them ?

Yes. 

Because we have higher standards for browsers?

-- 

ukai

[Zisu Andrei]

Oh, so Websockets are just used for some kind of a more efficient RPC?

[Zisu Andrei]

Indeed, thanks guys for the helpful answers.

In my case (a FTP socket), proxying the connection can't be the solution.

I am considering contributing to chromium

Best regards

On 20 January 2011 06:39, Takeshi Yoshino <tyos...@google.com> wrote:

A kind of. WebSocket is basically designed as a new more efficient bi-directional channel between browser and web server. It's intended to provide straightforward way for JavaScript in web apps to a) exchange short message with web server instead of using HTTP with big overhead of HTTP header for each message and b) receive notification from web server without using long-polling HTTP request.

It could be something like you say, i.e. raw socket API with UI for asking user for permission, but WebSocket did take a different approach.

WebSocket has its own framing. Data from script is encapsulated into WebSocket frames with some header, and then they are sent over TCP.

WebSocket clients can talk only with WebSocket capable servers. Not to allow malicious JavaScript to establish connections to arbitrary hosts (including cross-protocol attack), WebSocket has handshaking. In handshaking process of WebSocket, a client validates that the server is really WebSocket capable server (using a sort of challenge/response) and the server can validate that the client is running script the server knows (using Origin data in handshake).

If one want to make browser able to access IMAP/POP/... service, one should put code to bridge WebSocket with them in the front-end server.

Takeshi