Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everybody gets WebSockets

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Everybody gets WebSockets

#31

Post by matthewaveryusa »

danielrhodes wrote: post #25
mikeash wrote: post #15

Earlier quoted context omitted.

Don't many companies install their own certificate on company-owned machines so they can MITM secure traffic too?

I can't speak to that vulnerability, but from what I have read websockets are more likely to not break on firewalls because they are using a well known port (either 80 or 443). Websockets also start out looking like a standard HTTP request. Compared to say MQTT or another protocol which uses its own port, websockets don't require any special setup. However, that really only applies to encrypted websockets; unencrypte…

Furthermore websockets mask the payload so that naive proxies that do deep packet inspection to find HTTP requests don't fall to the poisoned cache trap.

http://security.stackexchange.com/questions/36930/how-does-w...

Re: Everybody gets WebSockets

#32

Post by jkarneges »

dabeeeenster wrote: post #21

I don't really see what the benefit is here for the developer? With HTTP CloudFlare can do caching etc to take load off the origin, but the origin server has to deal with each websocket (right?)

If you're interested in CDN-like support for WebSockets that reduces burden on the origin server, check out https://fanout.io/ (disclaimer: founder). We translate incoming WebSocket messages into HTTP requests sent to the origin server, and you can send messages to multiple client connections at once using the API.

Re: Everybody gets WebSockets

#33

Post by sametmax »

markbnj wrote: post #29

I get that the overhead of an individual message over an individual connection is lower, but for that efficiency you give up layer 7 routing capability, make load balancing difficult, have more long-lived connections to your servers. Does HN generally feel like these are worthwhile tradeoffs?

There is more to this trade off, because push enables many neat things:

- you can halves the number of DB requests by 2 because refreshing is done by message passing half of the time instead of making a new requets trigerring DB calls. - cache invalidation is pro-active, and linked to events instead of just time. - you can have much more live stuff: settings, routing, configuration in general. You only need to load it once from your store, after that, any update is propagated. A CMS becomes cheap. - making clients talk to each others is easy. - websocket don't have CORS issues. You client code can query your live site, or a local backend, and synchronize both. - you can use the same canal of communication between your user clients and internal (micro-services) clients. The architecture becomes simpler. - if you have a heavy authentication process and complex sessions data, they can now be store with the persistent connection instead of being queried for every request.

Of course, not all that is enabled by default. You need to use some framework such as crossbar.io or meteorjs to get those benefits for free. Yet, it's very sweet.

Re: Everybody gets WebSockets

#34

Post by chinathrow »

izak30 wrote: post #30
mmaunder wrote: post #26

Earlier quoted context omitted.

http://viewdns.info/iphistory/

Pretty trivial to get a new IP address these days.

IP enumaration is also pretty trivial. I guess that what attackers might be using to "unhide" domains. Scan the net and request the required domain name?

Re: Everybody gets WebSockets

#35

Post by slrz »

jephir wrote: post #27
dabeeeenster wrote: post #21

I don't really see what the benefit is here for the developer? With HTTP CloudFlare can do caching etc to take load off the origin, but the origin server has to deal with each websocket (right?)

The biggest thing for me is that you can use secure WebSockets (wss://) without having to setup TLS on your origin server. This greatly improves the ability to establish WebSocket connections across proxies.

So what you want to do is fooling clients into believing there is transport encryption while actually there is none and the communication with the origin server happens in the clear?

Re: Everybody gets WebSockets

#37

Post by stesch »

danielrhodes wrote: post #25
mikeash wrote: post #15

Earlier quoted context omitted.

Don't many companies install their own certificate on company-owned machines so they can MITM secure traffic too?

I can't speak to that vulnerability, but from what I have read websockets are more likely to not break on firewalls because they are using a well known port (either 80 or 443). Websockets also start out looking like a standard HTTP request. Compared to say MQTT or another protocol which uses its own port, websockets don't require any special setup. However, that really only applies to encrypted websockets; unencrypte…

A firewall is more than a port filter.

Websockets don't use standard HTTP requests other than using standard ports. The header lines not mentioned in RFC 2616 get removed by a lot of corporate firewalls (that includes filtering proxies etc.).

Re: Everybody gets WebSockets

#38

Post by mark242 »

markbnj wrote: post #29

I get that the overhead of an individual message over an individual connection is lower, but for that efficiency you give up layer 7 routing capability, make load balancing difficult, have more long-lived connections to your servers. Does HN generally feel like these are worthwhile tradeoffs?

Absolutely yes.

Connections are very very cheap to maintain, and very very expensive to build up and break down. Even in environments with load balancers, stateful firewalls, etc., it is much easier to keep a socket open than it is to create a new one.

If you're doing any kind of realtime data, websockets are the way to go. It is way, way easier to do stream processing and deal with backpressure than it is to have a gigantic number of clients doing http polling.

When Cloudflare mentions that websockets haven't had a gigantic uptake, I don't wonder if it's because Amazon's ELB doesn't support them and people don't want to roll their own haproxy solution.

Re: Everybody gets WebSockets

#39

Post by [deleted] »

sametmax wrote: post #33
markbnj wrote: post #29

I get that the overhead of an individual message over an individual connection is lower, but for that efficiency you give up layer 7 routing capability, make load balancing difficult, have more long-lived connections to your servers. Does HN generally feel like these are worthwhile tradeoffs?

There is more to this trade off, because push enables many neat things: - you can halves the number of DB requests by 2 because refreshing is done by message passing half of the time instead of making a new requets trigerring DB calls. - cache invalidation is pro-active, and linked to events instead of just time. - you can have much more live stuff: settings, routing, configuration in general. You only need to load i…

[deleted]
Post reply on HN