4 ms·

> 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

> 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.

aidenn0 10y ago
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.
- yokohummer7 10y ago
  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.
  - aidenn0 10y ago
    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.
- fulafel 10y ago
  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-perform-a-server-to-server-ftp-transfer-by-using-iis https://support.microsoft.com/en-us/help/247132/how-to-perfo...
Matthias247 10y ago
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.
- kuschku 10y ago
  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.
  - Matthias247 10y ago
    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.
- yokohummer7 10y ago
  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?

aidenn0 10y ago

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.

yokohummer7 10y ago
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.
- aidenn0 10y ago
  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.
fulafel 10y ago
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-perform-a-server-to-server-ftp-transfer-by-using-iis https://support.microsoft.com/en-us/help/247132/how-to-perfo...

Matthias247 10y ago

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.

kuschku 10y ago
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.
- Matthias247 10y ago
  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.
yokohummer7 10y ago
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?