39

We’re trying to get Socket.io flashsockets to work in Internet Explorer 9 over HTTPS/WSS. The flashsockets work over HTTP, but HTTPS is giving us problems. We’re using socket.io version 0.8.7 and socket.io-client version 0.9.1-1.

We’re running our websocket server via SSL on port 443. We’ve specified the location of our WebsocketMainInsecure.swf file (these are cross-domain ws requests) in the correct location, and we’re loading the file in the swfobject embed over HTTPS.

We opened up port 843 in our security group for our EC2 instance and the cross origin policy file is successfully being rendered over HTTP. It does not seem to render over HTTPS (Chrome throws an SSL connection error).

We’ve tried two versions of the WebsocketMainInsecure.swf file. The first is the file provided by Socket.io, which is built off of WebsocketMainInsecure.as that does not include the line

Security.allowInsecureDomain("*");

This throws the error SCRIPT16389: Unspecified error. at the WebSocket.__flash.setCallerUrl(location.href) line.

We figured it was because the SWF file was not permitting HTTPS requests, so we replaced the WebSocketMainInsecure.swf file with the one found at this repo: https://github.com/gimite/web-socket-js because it includes the

Security.allowInsecureDomain("*");

line in the actionscript code. When we used this, we saw that the flashsocket connection kept disconnecting and reconnecting in an infinite loop. We tracked the error down to the transport.js file in the socket.io library in the onSocketError function on the Transport prototype. It throws the error:

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

We even tried updating both socket.io and socket.io-client to version 0.9.6 and we still got the Access is denied error.

This error has been very difficult to debug, and now we’re at a loss as to how to get flashsockets to work. We’re wondering if it might have to do with using an older version of socket.io, or maybe that our policy file server doesn’t accept HTTPS requests, or maybe even the way in which the WebSocketMainInsecure.swf file from the web-socket-js github repo was built relative to what socket.io-client expects.

user730569
  • 3,940
  • 9
  • 42
  • 68
  • 1
    This may be better asked in a different forum . . . ServerFault might be a good bet. Here is [a question from there about a similar error](http://serverfault.com/questions/402152/error-in-openssl-s-client-data-length-is-too-long), and that might give you some clues. – iND Jul 20 '12 at 03:55
  • 1
    @iND Saw that question but not sure if it helps me, what do you think? – user730569 Jul 20 '12 at 07:37
  • 1
    I have very limited knowledge of debugging server interaction, and this may not be the forum with the most experts in that area. You may get better responses in the more focused forums. However, it implies that this may not be a Flash problem. The error msg is the same, and the line number is only one away from your error line, so I would think that the solutions -- if you ignore the LDAP related info -- might have some bearing here. – iND Jul 20 '12 at 12:49
  • 1
    Also, I guess I would start by making sure you try everything in the [web-socket-js troubleshooting guide](https://github.com/gimite/web-socket-js#troubleshooting). – iND Jul 20 '12 at 12:59
  • 1
    @iND I agree but I'm unsure what that would be. Also, I tried everything in that troubleshooting guide... no luck. Also, we're using a wildcard subdomain ssl certificate... maybe that is conflicting with something else. – user730569 Jul 20 '12 at 16:08
  • 1
    `HTTPS error “data length too long”` it's common error when some node at https protocol skip ssl metadata. (Client gets packets stream without ability to recognize end of packet). Are you using some proxy on server/client/NAT side? – rogal111 Jul 27 '12 at 09:57
  • 1
    @rogal111 we're not using any proxy – user730569 Jul 27 '12 at 14:15
  • 2
    Can you try hosting WebSocketMain.swf and your html from the same domain / or did you do that already? It seems the insecure alternative is not recommended anyway and might be a site security concern. – Roger Johnson Jul 28 '12 at 11:41
  • 1
    Also, you might want to check this post on Amazon https://forums.aws.amazon.com/thread.jspa?messageID=290778 It references SSL port problems behind the EC2 load balancers. Not sure if this applies to you though. – Roger Johnson Jul 28 '12 at 11:43
  • 1
    @RogerJohnson We're not using a load balancer or proxy. I didn't try same domain requests because we need them to be cross domain requests. – user730569 Jul 28 '12 at 17:38
  • 1
    The question should contain "node.js". Then it will get more attention from relevant users. – ramazan polat Aug 06 '12 at 06:17
  • 1
    I would start by installing Wireshark, and tracing the SSL handshaking in detail. Can you do this, and post a trace of the flow? – Greycon Aug 07 '12 at 11:47
  • 1
    I agree with @RogerJohnson. This setup is just way to complex to grok. Start by removing unneeded steps until the problem goes away and then report back. – h4ck3rm1k3 Aug 07 '12 at 16:32
  • 1
    @Greycon good idea but I've moved onto jsonp polling. No time to really set up flash sockets again and inspect it in further detail... – user730569 Aug 07 '12 at 16:35

2 Answers2

1

I'm unsure weather it works. But here's my idea/suggestion:

  1. Idea: I assume that you (possibly) tried to access a URL which is too long. This happens if data often is tansmitted via GET-Parameters. The official limit for a URL is below 512 Bytes.

Details: The HTTP specification says that a protocol line may be at most 512 Bytes. If longer the server may reject the request or may be unable to handle the request. The first line in HTTP with a GET-requet is like "GET /path/to?param1=data1&param2=data2&... HTTP/1.1" which would need to fit in 512 bytes. For POST requests theres no such limitation..

However your error seems to origin from some SSL implementation (openSSL?): refering to s3_pkt.c at line 503 (I found a file like this here: http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c) but seems to be different; I don't know the details, and am just speculating: I could think of that the openSSL implementation has some limited support for long GET-Requests (as they are not HTTP conform) and just rejects them this way...

I see these possibities now: 1. Solution: Use POST instead of GET-Requests to transmit longer datasets. See if this works... 2. Try to replace you openssl-installation or libopenssl at the server used; it's possibly broken or outdated? 3. Try to request some help from the openssl developers...

Hope that helps...

SDwarfs
  • 3,189
  • 5
  • 31
  • 53
1

Try building OpenSSL with SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER (credit to Steven Henson and Jaaron Anderson from OpenSSL mailing list).

jww
  • 97,681
  • 90
  • 411
  • 885