3 ms·

If you are using secure web sockets (wss), this shouldn't be an issue as the traffic goes over port 443 and the proxy won't be able to tell if it's HTTP or anot

If you are using secure web sockets (wss), this shouldn't be an issue as the traffic goes over port 443 and the proxy won't be able to tell if it's HTTP or another type of traffic.

stesch 10y ago
https://www.howtoforge.com/filtering-https-traffic-with-squid https://www.howtoforge.com/filtering-https-traffic-with-squi...
mikeash 10y ago
Don't many companies install their own certificate on company-owned machines so they can MITM secure traffic too?
- roblabla 10y ago
  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 :|.
  - pfg 10y ago
    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.
- danielrhodes 10y ago
  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.
  - matthewaveryusa 10y ago
    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-websocket-frame-masking-protect-against-cache-poisoning http://security.stackexchange.com/questions/36930/how-does-w...
  - stesch 10y ago
    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.).

If you are using secure web sockets (wss), this shouldn't be an issue as the traffic goes over port 443 and the proxy won't be able to tell if it's HTTP or another type of traffic.

stesch 10y ago

https://www.howtoforge.com/filtering-https-traffic-with-squid https://www.howtoforge.com/filtering-https-traffic-with-squi...

mikeash 10y ago

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

roblabla 10y ago
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 :|.
- pfg 10y ago
  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.
danielrhodes 10y ago
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.
- matthewaveryusa 10y ago
  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-websocket-frame-masking-protect-against-cache-poisoning http://security.stackexchange.com/questions/36930/how-does-w...
- stesch 10y ago
  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.).