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; unencrypted has been known to cause issues with older proxies.

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

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

I've never seen that. Also, this would break many websites that are part of the HPKP preload list I would think (need to double check), which include most popular websites.

However, I've often seen port 443 being blocked :|.

It's quite common in corporate networks. Locally installed CA certificates (i.e. anything that's not in the original root CA list) are exempt from HPKP rules for this particular reason.