Error: ../deps/openssl/openssl/ssl/s3_pkt.c:1293:SSL alert number 48

[jeremykentbgross]

To get the title error message:

Reproduction Steps:

1. create a secure websocket from https server with pem generated certificates and no crt
2. connect with chrome, when you see "The site's security certificate is not trusted!" click "Proceed anyway"
3. connect with firefox, note that as soon as firefox displays the "This Connection is Untrusted", chrome instance(s) websockets is/are instantly disconnected
4. myWebSocket.on('error', ...); shows nothing, but myWebSocket._socket.on('error', ...); displays the following error message:

Error: 140579907696448:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:../deps/openssl/openssl/ssl/s3_pkt.c:1293:SSL alert number 48

Note this does not happen the other way around (ie with chrome booting firefox instances from the server). Most likely something about firefox client certificates when the server has no crt on https are causing openssl to choke. This does not happen with http and insecure websockets.

Final notes:

1. I suspect this is likely a bug in node, not ws, but I figure only your team is qualified to pass this bug on to the node team after verifying this isn't a problem in ws.js.

2. It was also an annoyance that initially no error message was generated from wsjs when the websockets were inexplicably disconnected. In was only listening to the base socket in the websocket that displayed this error. While most low level errors are perhaps more than your library should pass through to the user, perhaps lower level errors that cause disconnects should be passed through.

3. Node Version:

console.log("All System Versions:\n" + JSON.stringify(process.versions, null, '\t') + "\n");
{
"http_parser": "2.3",
"node": "0.12.0",
"v8": "3.28.73",
"uv": "1.0.2",
"zlib": "1.2.8",
"modules": "14",
"openssl": "1.0.1l"
}

4. Related package.json versions:
   "ws" : "0.7.1"
   "pem": "1.7.2"

5. OS version:

cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"
NAME="Ubuntu"
VERSION="12.04.4 LTS, Precise Pangolin"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu precise (12.04.4 LTS)"
VERSION_ID="12.04"

6. OpenSSL version:

dpkg -s openSSL
Package: openssl
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 901
Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com
Architecture: amd64
Version: 1.0.1-4ubuntu5.12
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.1)
Suggests: ca-certificates
Conffiles:
/etc/ssl/openssl.cnf ce31ab5015842bf7c2939514a634e0e4
Description: Secure Socket Layer (SSL) binary and related cryptographic tools
This package contains the openssl binary and related tools.
.
It is part of the OpenSSL implementation of SSL.
.
You need it to perform certain cryptographic actions like:

• Creation of RSA, DH and DSA key parameters;
• Creation of X.509 certificates, CSRs and CRLs;
• Calculation of message digests;
• Encryption and decryption with ciphers;
• SSL/TLS client and server tests;
• Handling of S/MIME signed or encrypted mail.
  Original-Maintainer: Debian OpenSSL Team pkg-openssl-devel@lists.alioth.debian.org

[jeremykentbgross]

One addition I forgot to mention, the disconnect code from the websocket when this happens is: 1000 (ie CLOSE_NORMAL). However as the report indicates, this is certainly not a normal close.

[jeremykentbgross]

Call stack for reference:

ERROR:[2015-03-28T10:27:28.988Z]: [Error: 140351293540160:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:../deps/openssl/openssl/ssl/s3_pkt.c:1289:SSL alert number 48
]
at TLSSocket._onError (/home/jeremy/Projects/EmpathicCivGameEngine/engine/private/scripts/NetworkServer.js:223:13)
at TLSSocket.emit (events.js:129:20)
at TLSSocket._tlsError (_tls_wrap.js:428:10)
at TLSWrap.ssl.onerror (_tls_wrap.js:337:12)

[calzoneman]

I can confirm that I was able to reproduce the issue on Arch Linux with node v0.12.2. Well, indirectly. I had a user of my socket.io-powered software complain about this error message, investigated and was able to use a similar setup to what you described to reproduce it. The real kicker here is that it seems to reset the entire HTTPS server, kicking any clients that were connected before. Actually, it appears to just kill a random other socket.

I'm also inclined to believe this is an issue with node-- I was able to reproduce it even when forcing socket.io to use long polling rather than websockets, and I was NOT able to reproduce it with node v0.10.35. I was trying to come up with a minimal test case but had trouble coming up with an example using ws.

[3rd-Eden]

This looks more like a bug in node core than a bug in ws as none of the stack traces point or originate from ws. Also, it's is known that there issues when using self signed certificates in combination with websockets, safari also has it's fair share of issues with it. And it makes sense for the browsers to kill the connection from a security point of view.

[calzoneman]

I agree it makes sense for Firefox to abort the connection. What does not make sense is killing the connection of a random other client on the server.

It's worth noting this does not only happen with self signed certificates; when the problem was reported to me it was caused by someone who for some reason didn't have a particular CA in their Firefox trust store.

These things said, I think it is likely an issue with node core and we should bring the discussion over to that project.

Calvin

On Apr 13, 2015, at 02:20, Arnout Kazemier notifications@github.com wrote:

This looks more like a bug in node core than a bug in ws as none of the stack traces point or originate from ws. Also, it's is known that there issues when using self signed certificates in combination with websockets, safari also has it's fair share of issues with it. And it makes sense for the browsers to kill the connection from a security point of view.

—
Reply to this email directly or view it on GitHub.

[calzoneman]

nodejs/node-v0.x-archive#14818

[gopat]

There seems to be more movement on this in nodejs/node/issues/1642.

iojs is (as most of you will probably know) a fork of nodejs, and some changes/fixes are ported from one to another.