29

A Web Socket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure Web Sockets over SSL can leverage the same HTTP CONNECT technique. [1]

OK, sounds useful! But, in the client implementations I've seen thus far (Go [2], Java [3]) I do not see anything related to proxy detection.

Am I missing something or are these implementations just young? I know WebSockets is extremely new and client implementations may be equally young and immature. I just want to know if I'm missing something about proxy detection and handling.

[1] http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

[2] http://golang.org/src/pkg/websocket/client.go

[3] http://github.com/adamac/Java-WebSocket-client/raw/master/src/com/sixfire/websocket/WebSocket.java

z8000
  • 3,715
  • 3
  • 29
  • 37
  • 3
    They don't? Aaargghh! and I kept wondering why my code didn't worked! Wasted a whole morning but now it seems to work because I removed the proxy. Thank you for asking this question! – Tieme Sep 27 '12 at 15:07
  • 1
    @Tieme proof that questions are just as important as answers –  May 25 '13 at 04:55

6 Answers6

46

Let me try to explain the different success rates you may have encountered. While the HTML5 Web Socket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a Web Sockets gateway or server.

The Web Socket protocol defines a ws:// and wss:// prefix to indicate a WebSocket and a WebSocket Secure connection, respectively. Both schemes use an HTTP upgrade mechanism to upgrade to the Web Socket protocol. Some proxy servers are harmless and work fine with Web Sockets; others will prevent Web Sockets from working correctly, causing the connection to fail. In some cases additional proxy server configuration may be required, and certain proxy servers may need to be upgraded to support Web Sockets.

If unencrypted WebSocket traffic flows through an explicit or a transparent proxy server on its way the WebSocket server, then, whether or not the proxy server behaves as it should, the connection is almost certainly bound to fail today (in the future, proxy servers may become Web Socket aware). Therefore, unencrypted WebSocket connections should be used only in the simplest topologies.

If encrypted WebSocket connection is used, then the use of Transport Layer Security (TLS) in the Web Sockets Secure connection ensures that an HTTP CONNECT command is issued when the browser is configured to use an explicit proxy server. This sets up a tunnel, which provides low-level end-to-end TCP communication through the HTTP proxy, between the Web Sockets Secure client and the WebSocket server. In the case of transparent proxy servers, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. However, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if Web Sockets Secure is used. Using encryption, of course, is not free, but often provides the highest success rate.

One way to see it in action is to download and install the Kaazing WebSocket Gateway--a highly optimized, proxy-aware WebSocket gateway, which provides native WebSocket support as well as a full emulation of the standard for older browsers.

Emile Cormier
  • 28,391
  • 15
  • 94
  • 122
Peter Lubbers
  • 959
  • 5
  • 8
  • Peter, thanks for your comment. But it kind of skirts around the question. You sort of answer it: browsers with explicit proxy configurations will issue the HTTP CONNECT. The question is about WS clients in general not just browsers. The few clients I've sampled do not have any explicit proxy support. I can infer from your answer that it is up to such clients to have such support (like a browser would) and that they are simply just not implemented (yet?). – z8000 Feb 18 '10 at 19:34
  • 2
    Sorry I misunderstood your question--you're right, those clients do not support proxies. – Peter Lubbers Feb 19 '10 at 01:33
  • 1
    75% of your post is copy-pasted from the Wikipedia article. Please learn how to use block quotes and cite your sources. – Emile Cormier Aug 23 '13 at 18:29
  • 22
    OOPS! I looked at the version history of the Wikipedia article and saw that you're the one who contributed those paragraphs. I'm so embarrassed. My apologies. :-( I'm rolling back my edit. (Here I am, flogging you for not citing your own work, lol) – Emile Cormier Aug 23 '13 at 18:36
  • 1
    @PeterLubbers, Re "others will prevent Web Sockets from working correctly, causing the connection to fail"; but **why?** – Pacerier Oct 25 '17 at 12:14
  • 1
    @PeterLubbers, Re "bound to fail today", but why would it fail? – Pacerier Oct 25 '17 at 12:15
2

The answer is that these clients simply do not support proxies. -Occam

z8000
  • 3,715
  • 3
  • 29
  • 37
  • 1
    Well the answer is that a HTTP CONNECT is instructed. A HTTP CONNECT instructed connection looks like a basic TCP connection to the client so he sends the Websocket handshake AFTERWARDS. He sends two HTTP requests for one Websocket handshake. One for the proxy, one for the websocket server. – sinni800 Jan 18 '12 at 11:13
1

The communication channel is already established by the time the WebSocket protocol enters the scene. The WebSocket is built on top of TCP and HTTP so you don't have to care about the things already done by these protocols, including proxies.

When a WebSocket connection is established it always starts with a HTTP/TCP connection which is later "upgraded" during the "handshake" phase of WebSocket. At this time the tunnel is established so the proxies are transparent, there's no need to care about them.

Tihauan
  • 2,780
  • 2
  • 26
  • 29
  • So what does the http connect then? – z8000 Feb 05 '10 at 07:53
  • 2
    @z8000 The HTTP CONNECT establishes a HTTP connection. It is a normal GET request which, if the server supports the WebSochet protocol, is upgraded later. The WebSocket protocol uses HTTP to negotiate the connection and, as you suggested, to bypass proxies. – Tihauan Feb 05 '10 at 10:13
  • 1
    _WHAT_ does the HTTP CONNECT? Not what _IS_ a HTTP CONNECT? According to Wikipedia: "Another HTTP-based tunneling method uses the HTTP CONNECT method/command. A client issues the HTTP CONNECT command to an HTTP proxy. The proxy then makes a TCP connection to a particular server:port, and relays data between that server:port and the client connection." I see nothing in the WebSocket clients that talk to a proxy via HTTP CONNECT. Consider CURLOPT_PROXY in libcurl's API for instance. – z8000 Feb 05 '10 at 18:43
0

Regarding websocket clients and transparent proxies, I think websocket client connections will fail most of the time for the following reasons (not tested):

  • If the connection is in clear, since the client does not know it is communicating with a http proxy server, it won't send the "CONNECT TO" instruction that turns the http proxy into a tcp proxy (needed for the client after the websocket handshake). It could work if the proxy supports natively websocket and handles the URL with the ws scheme differently than http.

  • If the connection is in SSL, the transparent proxy cannot know to which server it should connect to since it has decrypt the host name in the https request. It could by either generating a self-signed certificate on the fly (like for SSLStrip) or providing its own static certificate and decrypt the communication but if the client validates the server certificate it will fail (see https://serverfault.com/questions/369829/setting-up-a-transparent-ssl-proxy).

Community
  • 1
  • 1
user23724
  • 73
  • 1
  • 5
0

You mentioned Java proxies, and to respond to that I wanted to mention that Java-Websocket now supports proxies.

You can see the information about that here: http://github.com/TooTallNate/Java-WebSocket/issues/88

netdragon
  • 1
0

websocket-client, a Python package, supports proxies, at the very least over secure scheme wss:// as in that case proxy need no be aware of the traffic it forwards.

https://github.com/liris/websocket-client/commit/9f4cdb9ec982bfedb9270e883adab2e028bbd8e9

Dima Tisnek
  • 11,241
  • 4
  • 68
  • 120