Comment by yokohummer7 | Hacker News Reader

Comment by yokohummer7 | Hacker News Reader

Parent Full thread

> Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers.

> New security holes would be created as JavaScript running in web pages could craft malicious UDP packets to probe the internals of corporate networks and report back over HTTPS.

Is this the same reason that the "raw" TCP is not supported on the web? When I first learned WebSocket I was surprised that it is a message-based protocol. What I imagined was a protocol that utilizes HTTP only as a means of negotiation, and the actual transfer is done just as the raw TCP does. But it's not, so I had to create another layer to be interoperable with the existing (raw) TCP server. What was the exact reason?

Edit: Another reason I can think of is the encoding issue, cause TCP is byte-based. But the current WebSocket spec already assumes UTF-8 for textual data, and is also capable of sending bytes using `ArrayBuffer`. I don't see how this would matter in practice.

Just a remark: You can use the websocket spec to emulate TCP behavior, which means get a stream instead of messages: Send only one giant message (payload set the maximum) and use Continuation frames to stream new chunks of data to the other side. FIN will be only set once the stream has finished.

The downside: A lot of websocket APIs (and most especially the one in the browser) don't support this and will only send/receive complete messages. Which means if you want streaming support you better implement it as a layer on top of messages, since it works everywhere.

It's a little bit sad that the websocket spec is complicated through the continuation frame feature while in reality noone has a reason to use it.

And back to the question: The masking "feature" of websockets is also there to prevent browsers from speaking raw TCP. Without it Javascript could craft exact TCP payloads, which might in certain situations be used to directly talk and manipulate internal services. The masking guarantees that the remote on the TCP connection will get some random data after the websocket header.

That's interesting, I've always thought the WebSocket spec is too complicated with all those frame types and message fragmentation, and I completely ignored contunation frames when I had to implement the protocol myself. But it seems more versatile than I imagined. Though the workaround you mentioned sounds a bit hacky.

And yeah, I now remember that masking was also a problem at the time. So even if web browsers adopt a new API to send fragmented messages, it would still not be possible to directly plug in them to legacy servers. Sad.

Edit: It would also be possible to send a single giant message, which contains a single giant continuation frame sent for the lifetime of the session, which is followed by a FIN frame. Am I correct?

Yes, you could use the single giant message too. The drawback to the continuation frame approach is that you can't interleave it with ping frames (for connectivity checks) and that you won't be able to signal end of stream (FIN). If that's not required because your higher level protocol takes care of that things otherwise it would be fine.

The problem that's missing is being able to speak to existing services without requiring them to implement a websocket interface.

The entire websocket code should have never existed in the first place — just use standard TCP with standard TLS, like any other system, too.

Maybe require a browser permission for that, and that issue is solved, too.

I guess they didn't want browsers to annoy users with popups like: "Do you want to allow a TCP connection to host.com:234?" The average user would have no idea what this means and would just accept anything. Maybe they could have elided the check if the destination uses the same host than where the HTML/JS was delivered from, but that would still leave some questions unanswered.

Yes this is the reason, but the message-based part is irrelevant. They need to use an existing http connection where both sides agree on the upgrade to prevent lots of possible security holes.

If you aren't aware, the FTP protocol lets one specify a port and address to connect to; it was not that long ago that servers would not check if the address for the data connection was the same as the address for the control connection, and so one could send data to any port on the internet from an anonymous FTP server. This caused all sorts of headaches.

Yeah, but both parties can leverage the existing connection without resorting to a message-based protocol, can't they? They could just assume they're now sending and receiving bytes after the upgrade.

What I meant when I said "utilizing the legacy TCP sever" was creating some plugin that is attached to the server, effectively acting as a lightweight HTTP server that just does the upgrade process (within the same connection). In this way the remaining communication doesn't have to involve message encapsulation/decapsulation each time a message is transferred.

I think the message encapsulation was chose because it's more work to implement a message-passing system on top of a stream than to do the opposite.

This is still a supported feature of some FTP implementations. It enables the client to initiate a file transfer between 2 FTP servers.

See eg https://support.microsoft.com/en-us/help/247132/how-to-perfo...

Reply on news.ycombinator.com