4 ms·

I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, a

I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, and a websocket connection could be started with an untrusted server? Anyone familiar with security and websockets? edit: I'm using websockets in a few projects (gracefully degrading to flash or XHR), and I'd like to know whether I should reevaluate webSockets. edit2: according to this mailing list, it's an issue with how proxies handle the HTTP Upgrade header. Awesome. http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html http://www.ietf.org/mail-archive/web/hybi/current/msg04744.h...

FooBarWidget 16y ago
Details are linked right there from the article.
nitrogen 16y ago
After reading eight or so e-mails from the thread you linked, it sounds like the vulnerability is in various proxies, not in WebSockets itself.
oofo 16y ago
Exactly the other way around, some man in the middle attacks get confused in the presence of websockets: "The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies" It's pretty weird that they consider this a problem with websockets.
- tptacek 16y ago
  It's not an issue of "attributable fault". It's an issue of a reasonable protocol that doesn't work reliably on deployed infrastructure. Unlike, say, HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that tickles a bug in a widely deployed proxy can be catastrophic. Let's all be clear that the "fault" lies in crappy HTTP code deployed in middleboxes (and that includes mine), but pragmatic in understanding that that doesn't matter; browsers can't become roving exploits for proxy bugs just because a standard says so.

4 ms·

I'm really curious what Mozilla's motivation is for disabling websockets over security concerns. Is it that they are susceptible to man in the middle attacks, a

by tjarratt 16y ago

FooBarWidget 16y ago
Details are linked right there from the article.
nitrogen 16y ago
After reading eight or so e-mails from the thread you linked, it sounds like the vulnerability is in various proxies, not in WebSockets itself.
oofo 16y ago
Exactly the other way around, some man in the middle attacks get confused in the presence of websockets: "The Upgrade-based handshake is vulnerable to attack in network configurations involving transparent (or intercepting) proxies" It's pretty weird that they consider this a problem with websockets.
- tptacek 16y ago
  It's not an issue of "attributable fault". It's an issue of a reasonable protocol that doesn't work reliably on deployed infrastructure. Unlike, say, HTML5 Canvas, where failures still degrade somewhat gracefully, a failure that tickles a bug in a widely deployed proxy can be catastrophic. Let's all be clear that the "fault" lies in crappy HTTP code deployed in middleboxes (and that includes mine), but pragmatic in understanding that that doesn't matter; browsers can't become roving exploits for proxy bugs just because a standard says so.