Safari disallows websocket communication when using self-signed certificates

[marpaia]

As reported in osquery slack, when running a distributed query in Safari, the timer stays at 0 and the query never runs.

[mikestone14]

I've looked around and it seems it could be related to our certificate. Specifically, from this stack overflow post

setting OpenSSL to SSLv3 by default kills Safari, but letting it pick its own SSL version (all) works fine

Unfortunately, Safari doesn't output anything helpful in the console when the requests fail. This is the only console output: WebSocket network error: OSStatus Error -9807: d

Here are a couple resources I found:

reddit-archive/reddit-plugin-liveupdate#100

http://stackoverflow.com/questions/4014055/how-to-debug-safari-silently-failing-to-connect-to-a-secure-websocket

mrjoes/tornadio2#59

[groob]

I think you're right that it's TLS related, specifically self signed certs.
Safari seems to be working for me with a Let's Encrypt cert we use, but fails with self signed ones.

[mikestone14]

@groob should I assign you and @marpaia to this issue (and remove me and @kyleknighted)?

[groob]

Sounds good

[groob]

Ok, I've done a bit more testing and identified that safari will only establish a wss:// connection if the certificate is explicitly trusted.

Even after running something like

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" server.crt

imports the certificate with custom trust settings and the user must explicitly select "Always Trust" in Safari

This does not always cause a problem with Chrome, but it might in the future. Self signed certs are always a bad idea(difficult to manage) and we should find ways to discourage users from using them in their setups. One suggestion I have is to improve the documentation for obtaining Let's Encrypt certificates, which are free, easy to obtain and work great.

For now, I'm going to add a documentation comment about safari, and also echo a warning about using safari in the quickstart script.

@terracatta I think it's important you're aware of this quirk with Safari and self signed certs, especially if you end up doing a local demo for someone remotely.

[terracatta]

@zwass Can you repro this Safari situation and see if your SocksJS fallbacks kick in when Safari cannot establish a WS connection due to security reasons (and not network communication issues, which is the use case we are currently using it for) ?

[zwass]

It does look like Safari will fallback to XHR when websockets fail for this reason. An error is printed to the console, which would probably be hard to avoid.

[terracatta]

@zwass excellent we will add to your sockjs PR that this resolves this issue IMO.