【问题标题】:HTTPS error "data length too long" in s3_pkt.c from Socket.io来自 Socket.io 的 s3_pkt.c 中的 HTTPS 错误“数据长度太长”
【发布时间】:2012-10-02 01:08:27
【问题描述】:

我们正在尝试让 Socket.io 闪存套接字通过 HTTPS/WSS 在 Internet Explorer 9 中工作。 flashsockets 通过 HTTP 工作,但是 HTTPS 给我们带来了问题。我们使用的是 socket.io 0.8.7 版和 socket.io-client 0.9.1-1 版。

我们正在通过 SSL 在端口 443 上运行我们的 websocket 服务器。我们已经在正确的位置指定了 WebsocketMainInsecure.swf 文件(这些是跨域 ws 请求)的位置,并且我们正在将文件加载到通过 HTTPS 嵌入的 swfobject。

我们在安全组中为 EC2 实例打开了端口 843,并且跨源策略文件已成功通过 HTTP 呈现。它似乎没有通过 HTTPS 呈现(Chrome 引发 SSL 连接错误)。

我们尝试了两个版本的 WebsocketMainInsecure.swf 文件。第一个是 Socket.io 提供的文件,它是由 WebsocketMainInsecure.as 构建的,不包含该行

Security.allowInsecureDomain("*");

这会在WebSocket.__flash.setCallerUrl(location.href) 行引发错误SCRIPT16389: Unspecified error.

我们认为这是因为 SWF 文件不允许 HTTPS 请求,因此我们将 WebSocketMainInsecure.swf 文件替换为在此 repo 中找到的文件:https://github.com/gimite/web-socket-js,因为它包含

Security.allowInsecureDomain("*");

actionscript 代码中的行。当我们使用它时,我们看到 flashsocket 连接在无限循环中不断断开和重新连接。我们在 Transport 原型的 onSocketError 函数中将错误跟踪到 socket.io 库中的 transport.js 文件。它抛出错误:

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

我们甚至尝试将 socket.io 和 socket.io-client 都更新到 0.9.6 版本,但仍然出现 Access is denied 错误。

这个错误一直很难调试,现在我们不知道如何让 flashsockets 工作。我们想知道这是否与使用旧版本的 socket.io 有关,或者我们的策略文件服务器不接受 HTTPS 请求,或者甚至可能是来自网络的 WebSocketMainInsecure.swf 文件的方式- socket-js github repo 是相对于 socket.io-client 的期望构建的。

【问题讨论】:

  • 这个问题最好在不同的论坛上问。 . . ServerFault 可能是一个不错的选择。这是a question from there about a similar error,这可能会给你一些线索。
  • @iND 看到了这个问题,但不确定它是否对我有帮助,你怎么看?
  • 我在调试服务器交互方面的知识非常有限,这可能不是该领域专家最多的论坛。在更集中的论坛中,您可能会得到更好的回应。但是,这意味着这可能不是 Flash 问题。错误消息是相同的,并且行号与您的错误行仅相差一个,所以我认为解决方案 - 如果您忽略 LDAP 相关信息 - 可能在这里有一些影响。
  • 另外,我想我会首先确保您尝试 web-socket-js troubleshooting guide 中的所有内容。
  • 您可以尝试从同一个域托管 WebSocketMain.swf 和您的 html / 还是您已经这样做了?似乎无论如何都不推荐不安全的替代方案,这可能是网站安全问题。

标签: node.js ssl https socket.io ssl-certificate


【解决方案1】:

我不确定它是否有效。但这是我的想法/建议:

  1. 想法: 我假设您(可能)试图访问一个太长的 URL。如果数据经常通过 GET-Parameters 传输,就会发生这种情况。 URL 的官方限制低于 512 字节。

详细信息:HTTP 规范规定一个协议行最多为 512 字节。如果更长,服务器可能会拒绝请求或可能无法处理请求。 HTTP 中带有 GET-requet 的第一行类似于“GET /path/to?param1=data1&param2=data2&... HTTP/1.1”,它需要容纳 512 个字节。对于 POST 请求,没有这样的限制..

但是,您的错误似乎源于某些 SSL 实现(openSSL?):在第 503 行引用 s3_pkt.c(我在这里找到了这样的文件:http://www.opensource.apple.com/source/OpenSSL/OpenSSL-7.1/openssl/ssl/s3_pkt.c)但似乎有所不同;我不知道细节,只是推测:我可以认为 openSSL 实现对长 GET-Requests 的支持有限(因为它们不符合 HTTP)并且只是以这种方式拒绝它们......

我现在看到了这些可能性: 1. 解决方案:使用 POST 而不是 GET-Requests 来传输更长的数据集。看看这是否有效... 2.尝试在使用的服务器上替换您的openssl-installation或libopenssl;它可能损坏或过时? 3.尝试向openssl开发者寻求帮助...

希望对您有所帮助...

【讨论】:

    【解决方案2】:

    尝试使用 SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER 构建 OpenSSL(感谢来自 OpenSSL 邮件列表的 Steven Henson 和 Jaaron Anderson)。

    【讨论】:

    • 谢谢!我是否需要使用该选项构建 OpenSSL,或者我可以在运行 s_client 时指定 -bugs 选项来设置选项?
    • 如果我重建它,我该如何指定这个选项?
    猜你喜欢
    • 2012-02-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-01-03
    • 1970-01-01
    • 1970-01-01
    • 2012-10-11
    • 1970-01-01
    相关资源
    最近更新 更多