WebSocket under the HTTP proxy is yes, but a little awkward place for people caused inconvenience

from the specification, WebSocket is undoubtedly accessible through the HTTP proxy server proxy, whether it is a non-encrypted ws://, or encrypted wss://, should be able to. Of course there is a common premise: HTTP Proxy server provides a socket-level non-filtering transfer, which is called the Connect command (not just the forwarding and filtering of HTTP overall request responses). Reality because if you do not provide support for this connect command, then the HTTPS Web site will not be used (the reason a word is not sure, of course, through the forgery of SSL certificates and other means is also possible, just need to browser machine This side of the match). In short, the HTTP proxy Server from the principle point of view, once supported the Connect command, then he later on the connection occurred in the encrypted content is basically dry stare, can not distinguish between the end is not https, in a sense, this is the HTTP Proxy A vulnerability in the design of the server.

In fact, I have been using websocket for a while, and HTTP proxy mates are OK, both WSS (encrypted) and WS (unencrypted) protocols are OK ,

but one day in an HTTP proxy environment has a problem!

after a paranoid investigation, it was finally determined that the automatic configuration script did not provide the proxy server IP and port for the WSS type, but only answered a direct (that is, not directly connected to the proxy server), so it failed.

the countermeasure is simple, modify the PAC or configure the ip,port of a fixed proxy.

Memo The investigation passes:

Tools used:Socat

in firefox/chrome/ie, using the crypto-websocket:new WebSocket (' wss://x.y.z/test '), the error is said to be timeout, not the encrypted new WebSocket (' ws:// X.y.z/test ') also error.

Proxy Configuration:

Automatic: Http://proxyserver/config.pac

Investigation begins:

first figure out what this config.pac, in fact, is a URL, host to answer what the proxy server, and is a JavaScript. For example:

function FindProxyForURL (URL, host) {
if (url.substring (0, 5) = = "http:") {
Return "PROXY proxy:80";
} else if (url.substring (0, 6) = = "https:") {
Return "PROXY secproxy:8080";
} else {
return "DIRECT";
}
}

that looked a bit is with secproxy:8080, ah, https are normal access, why WSS trouble?

at that time around a bend, want to see what happened inside the HTTP proxy, so take the socat tool to do a relay to analyze, this is an artifact, later in writing some live usage.

run:

socat-v tcp-listen:8080,reuseaddr,fork tcp-connect:secproxy:8080

is used to make a fake proxy server, local. The actions are transferred to the real proxy server,
Then set the browser through the fake proxy server access, so you can see the traffic data,

The content is omitted. To toss a bit also forgot to crawl the screen, forget how to do, it seems that the server to WebSocket handshake request to answer, browser did not continue to request, anyway realize self-signed certificate will cause problems: WebSocket server over there server SSL certificate is self-signed, then may not admit this side, well, indeed some people say yes, well, I put the certificate as a [trustworthy top certificate hairstyle] to add to the system, OH, HTTPS access to the site when the cross number disappears.

It's true that WSS can do it.

But back to the real environment, found or not, finally with Sysinternal ' s Process monitor tool Tracking network calls, found that browser incredibly not through proxy directly out, so error.

Remove the automatic configuration option and change it to a fixed proxy ip,port.


Finally, I think websocket in the choice of proxy server method to do a bit silly? Incredibly directly silly ask Wss://somesite what proxy server, instead of clever ask Https://somesite what website.

Turn from your own http://osexp2003.blogspot.jp/.

WebSocket under the HTTP proxy is yes, but a little awkward place for people caused inconvenience