Error de HTTPS "data length too long" en s3_pkt.c de Socket.io

Estamos tratando de hacer que Socket.io flashsockets funcione en Internet Explorer 9 a través de HTTPS/WSS. Las tomas de corriente funcionan a través de HTTP, pero HTTPS nos está dando problemas. Estamos utilizando socket.io versión 0.8.7 y socket.io-client versión 0.9.1-1.Error de HTTPS "data length too long" en s3_pkt.c de Socket.io

Estamos ejecutando nuestro servidor websocket a través de SSL en el puerto 443. Hemos especificado la ubicación de nuestro archivo WebsocketMainInsecure.swf (estas son solicitudes ws entre dominios) en la ubicación correcta, y estamos cargando el archivo en el objeto swfobject incrustado sobre HTTPS.

Abrimos el puerto 843 en nuestro grupo de seguridad para nuestra instancia EC2 y el archivo de política de origen cruzado se está procesando con éxito a través de HTTP. No parece renderizar a través de HTTPS (Chrome arroja un error de conexión SSL).

Hemos probado dos versiones del archivo WebsocketMainInsecure.swf. El primero es el archivo proporcionado por Socket.io, que se construye fuera de WebsocketMainInsecure.as que no incluye la línea

Security.allowInsecureDomain("*");

Esto arroja el error en la línea de SCRIPT16389: Unspecified error.WebSocket.__flash.setCallerUrl(location.href).

pensamos que era debido a que el archivo SWF no estaba permitiendo solicitudes HTTPS, así que sustituyen el archivo WebSocketMainInsecure.swf con la que se encuentra en este repo: https://github.com/gimite/web-socket-js, ya que incluye la línea

Security.allowInsecureDomain("*");

en el actionscript código. Cuando usamos esto, vimos que la conexión de la toma de corriente se desconectaba y reconectaba en un bucle infinito. Rastreamos el error hasta el archivo transport.js en la biblioteca socket.io en la función onSocketError en el prototipo de Transporte. Se lanza el error:

[Error: 139662382290912:error:1408F092:SSL routines:SSL3_GET_RECORD:data length too long:s3_pkt.c:503:]

Incluso intentamos actualizar tanto Socket.IO y socket.io-cliente a la versión 0.9.6 y todavía tiene el error Access is denied.

Este error ha sido muy difícil de depurar, y ahora no sabemos cómo hacer que las tomas de corriente flash funcionen. Nos preguntamos si podría tener que ver con el uso de una versión anterior de socket.io, o tal vez con que nuestro servidor de archivos de políticas no acepte solicitudes HTTPS, o tal vez con la forma en que el archivo WebSocketMainInsecure.swf de la web- socket-js github repo se construyó en relación con lo que socket.io-client espera.

Fuente

2012-07-20 user730569

Esto se puede pedir mejor en un foro diferente. . . ServerFault podría ser una buena apuesta. Aquí hay [una pregunta a partir de ahí sobre un error similar] (http://serverfault.com/questions/402152/error-in-openssl-s-client-data-length-is-too-long), y eso podría dar algunas pistas. – iND

@iND Vi esa pregunta pero no estoy seguro si me ayuda, ¿qué opinas? – user730569

Tengo un conocimiento muy limitado de la interacción del servidor de depuración, y este puede no ser el foro con la mayoría de los expertos en esa área. Puede obtener mejores respuestas en los foros más enfocados. Sin embargo, implica que esto puede no ser un problema de destello. El mensaje de error es el mismo, y el número de línea está a solo uno de distancia de su línea de error, por lo que creo que las soluciones, si ignora la información relacionada con LDAP, podrían tener algo que ver aquí. – iND

No estoy seguro si funciona. Pero aquí está mi idea/sugerencia:

Idea: Asumo que (posiblemente) intentado acceder a una dirección URL que es demasiado largo. Esto sucede si los datos a menudo se transmiten a través de GET-Parameters. El límite oficial para una URL es inferior a 512 Bytes.

Detalles: La especificación HTTP dice que una línea de protocolo puede tener como máximo 512 Bytes. Si es más largo, el servidor puede rechazar la solicitud o no puede manejar la solicitud. La primera línea en HTTP con un GET-requet es como "GET/path/to? Param1 = data1 & param2 = data2 & ... HTTP/1.1" que necesitaría caber en 512 bytes. Para solicitudes POST no hay tal limitación ..

Sin embargo, su error parece ser el origen de alguna implementación SSL (¿openSSL?): Refiriéndose a s3_pkt.c en la línea 503 (encontré un archivo como este aquí: http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c) pero parece ser diferente; No conozco los detalles, y solo estoy especulando: podría pensar que la implementación de openSSL tiene un soporte limitado para solicitudes GET largas (ya que no son compatibles con HTTP) y simplemente las rechaza de esta manera ...

Veo estas posibilidades ahora: 1. Solución: Use POST en lugar de GET-Requests para transmitir datasets más largos. Vea si esto funciona ... 2. Intente reemplazar su openssl-installation o libopenssl en el servidor utilizado; posiblemente esté roto u obsoleto? 3. Trate de solicitar la ayuda de los desarrolladores de OpenSSL ...

Espero que ayude ...

Fuente

2012-08-14 16:58:56 SDwarfs

edificio Try OpenSSL con SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER (crédito a Steven Henson y Jaaron Anderson, de la lista de correo OpenSSL).

Fuente

2012-10-01 17:08:27 jww

gracias! ¿Necesito construir OpenSSL con esa opción, o puedo simplemente especificar la opción '-bugs' cuando ejecuto' s_client' para establecer la opción? – user730569

Y si lo reconstruyo, ¿cómo especifico esta opción? – user730569

Error de HTTPS "data length too long" en s3_pkt.c de Socket.io

Respuesta

Cuestiones relacionadas