Allow mixed-content or self-signed SSL certificate for WebSocket connection to localhost?

There's been similar requests a few years back with references to internal rdar urls and without clear resolution, so here we go again:


My company has developed a hybrid web/native application that currently uses WKScriptMessages to pass data between a WKWebView and the native part of the application. However for performance reasons the idea to switch to WebSockets to save some significant overhead was tabled.


The main issue lies in the fact that, while the native part of the application can provide a WebSocket server listening to connections on localhost, there seems to be no way to have the client connect to the local server if the web part is loaded via "https://" (which is a requirement). Normal unsecured connections (ws://) get blocked for mixed-content reasons and any attempt to provide a self-signed SSL-certificate for this specific server instance result in an invalid certificate chain (OSError -9807) when attempting to connect from the WKWebView.

It seems possible to hook into the WKWebView's SSL validation to get regular https:// requests to load with a self-signed certificate but the same is not possible with the connection validation for WebSockets.
Likewise the validations can be softened / partially disabled by adding the required ATS exceptions but these too are ignored by WebSocktes.


Is there any way to work around this?

Why does the WebSocket implementation in WKWebView use a completely separate handling of all these validations?

Replies

Is there any way to work around this?

The best way to do web-to-native messaging is with

WKScriptMessages
. This avoids this problem, and other problems as well (for example, where per-app VPN blocks your localhost communication).

Why does the WebSocket implementation in WKWebView use a completely separate handling of all these validations?

That is an accident of history. I filed a bug about this a while ago (r. 25491679) but it wouldn’t hurt for you to file your own bug explaining your use case. Fixing this is a lot easier given that we’re in the process of adding WebSocket APIs to the OS (see WWDC 2019 Session 712 Advances in Networking, Part 1).

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"