¿Por qué las implementaciones de clientes de WebSocket actuales no admiten proxies?

Question

Un socket web detecta la presencia de un servidor proxy y configura automáticamente un túnel para pasar a través del proxy. El túnel se establece emitiendo una instrucción HTTP Connect al servidor proxy, que solicita que el servidor proxy abra una conexión TCP/IP a un host y puerto específicos. Una vez que el túnel está configurado, la comunicación puede fluir sin obstáculos a través del proxy. Dado que HTTP/S funciona de manera similar, los enchufes web seguros a través de SSL pueden aprovechar la misma técnica de conexión HTTP. [1

Ok, suena útil! Pero, en las implementaciones del cliente que he visto hasta ahora (Go [2], Java [3]), no veo nada relacionado con la detección de proxy.

¿Me estoy perdiendo algo o estas implementaciones son jóvenes? Sé que WebSockets es extremadamente nuevo y las implementaciones de los clientes pueden ser igualmente jóvenes e inmaduras. Solo quiero saber si me falta algo sobre la detección y el manejo de poder.

[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

Answer 1

La respuesta es que estos clientes simplemente no admiten proxies. -Occam

Answer 2

Permítanme tratar de explicar las diferentes tasas de éxito que puede haber encontrado. Si bien el protocolo de socket web HTML5 en sí no es consciente de los servidores y firewalls proxy, presenta un apretón de manos compatible con HTTP para que los servidores HTTP puedan compartir sus puertos HTTP y HTTPS predeterminados (80 y 443) con una puerta de enlace o servidor de enchufes web.

El protocolo de socket web define un ws: // y wss: // prefijo para indicar un WebSocket y una conexión segura de WebSocket, respectivamente. Ambos esquemas utilizan un mecanismo de actualización HTTP para actualizar al protocolo de socket web. Algunos servidores proxy son inofensivos y funcionan bien con los enchufes web; Otros evitarán que los sockets web funcionen correctamente, lo que hace que la conexión falle. En algunos casos, se puede requerir una configuración adicional del servidor proxy, y es posible que se deben actualizar ciertos servidores proxy para admitir los sockets web.

Si el tráfico de WebSocket no entrelazado fluye a través de un servidor proxy explícito o transparente en su camino el servidor WebSocket, entonces, ya sea que el servidor proxy se comporte como debería, la conexión es casi seguro que fallará hoy (en el futuro, los servidores proxy pueden Conviértete en el socket web). Por lo tanto, las conexiones WebSocket sin cifrar solo deben usarse en las topologías más simples.

Si se usa la conexión WebSocket cifrada, entonces el uso de la seguridad de la capa de transporte (TLS) en los sockets web Secure Connection asegura que se emite un comando HTTP Connect cuando el navegador está configurado para usar un servidor proxy explícito. Esto establece un túnel, que proporciona una comunicación TCP de extremo a extremo de bajo nivel a través del proxy HTTP, entre los sockets web Secure Client y el servidor WebSocket. En el caso de los servidores proxy transparentes, el navegador desconoce el servidor proxy, por lo que no se envía HTTP Connect. Sin embargo, dado que el tráfico de cables está encriptado, los servidores proxy transparentes intermedios pueden simplemente permitir el tráfico encriptado, por lo que existe una posibilidad mucho mejor de que la conexión WebSocket tenga éxito si se usan los enchufes web seguros. El uso del cifrado, por supuesto, no es gratuito, pero a menudo proporciona la tasa de éxito más alta.

Una forma de verlo en acción es descargar e instalar la puerta de enlace de Kaazing WebSocket, una puerta de enlace WebSocket altamente optimizada y consciente de proxy, que proporciona soporte de WebSocket nativo, así como una emulación completa del estándar para los navegadores más antiguos.

Answer 3

El canal de comunicación ya está establecido cuando el protocolo WebSocket ingresa a la escena. El WebSocket está construido sobre TCP y HTTP para que no tenga que preocuparse por las cosas ya realizadas por estos protocolos, incluidos los proxies.

Cuando se establece una conexión WebSocket, siempre comienza con una conexión HTTP/TCP que luego se "actualiza" durante la fase de "apretón de manos" de WebSocket. En este momento se establece el túnel para que los proxies sean transparentes, no hay necesidad de preocuparse por ellos.

Answer 4

Con respecto a los clientes de WebSocket y los proxies transparentes, creo que las conexiones del cliente WebSocket fallarán la mayor parte del tiempo por las siguientes razones (no probadas):

• Si la conexión está en claro, dado que el cliente no sabe que se comunica con un servidor proxy HTTP, no enviará la instrucción "Conectar a" que convierte el proxy HTTP en un proxy TCP (necesario para el cliente después del WebSocket apretón de manos). Podría funcionar si el proxy admite nativamente WebSocket y maneja la URL con el esquema WS de manera diferente a HTTP.

• Si la conexión está en SSL, el proxy transparente no puede saber a qué servidor debe conectarse, ya que ha descifrado el nombre de host en la solicitud HTTPS. Podría generando un certificado autofirmado en la marcha (como para SSLStrip) o proporcionando su propio certificado estático y descifrar la comunicación, pero si el cliente valida el certificado del servidor fallará (consulte https://serverfault.com/questions/369829/settingup-a-transparent-ssl-proxy).

Answer 5

Usted mencionó los proxies de Java y, para responder a eso, quería mencionar que Java-Websocket ahora admite proxies.

Puede ver la información sobre eso aquí: http://github.com/tootallnate/java-websocket/issues/88

Answer 6

websocket-client, un paquete Python, admite proxies, al menos sobre un esquema seguro wss:// Como en ese caso, el proxy no necesita tener en cuenta el tráfico que reenvía.

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