Support for whitelisting domains that are allowed certificate errors

[dteirney]

• Electron version: latest
• Operating system: Windows

Hello. We have an Electron based web application that needs to connect to both our backend RESTful APIs over the open internet using HTTPS, e.g. https://example.com/path/to/api, AND to RESTful APIs running on the Windows desktop on localhost, e.g. http://localhost:12345/path/to/api. The localhost RESTful APIs are currently not using HTTPS (if someone malicious has managed to compromise localhost then we assume it's game over anyway).

This type of access to HTTP APIs from an HTTPS web page isn't possible due to the Mixed Content protection that Chromium provides out of the box (the base text/html pages calling the APIs using fetch are served via HTTPS from our backend accessed over the open internet).

To workaround this we have tried using HTTPS on localhost with a self-signed certificate as it's not possible to get a proper SSL certificate for localhost signed by a root CA. To get this to work we've turned off certificate errors using --ignore-certificate-errors. However, we can't ship like this as we'd then be vulnerable to a man-in-the-middle attack for the HTTPS content being accessed over the open internet.

We tried allowing access to http://localhost with a Content-Security-Policy but it seems that isn't possible.

One thing that might be useful for this scenario would be the ability to whitelist domains where a certificate error is allowed, rather than a simple on/off switch for certificate errors. Is this something that might be feasible to add to Electron? We found discussion about this at https://discuss.atom.io/t/trusting-a-self-signed-certificate/12332 but there wasn't any resolution noted.

Are there any other options that might be straight forward for us to implement to resolve this problem? If we could add a certificate to the certificate trust store used by Electron / Chromium we could probably get something to work using that.

Thanks!
David

[MarshallOfSound]

I discusses this in another issue somewhere RE a self signed certificate on a WebSocket, my idea (although unimplemented) was to use a custom protocol when communicating with the localhost API and respond to it with this.

https://github.com/electron/electron/blob/master/docs/api/protocol.md#protocolregisterstringprotocolscheme-handler-completion

So you would request localapi://localhost/rest/do/something and handle it with

const fs = require('fs');
const request = require('request');

protocol.registerStringProtocol('localapi', (req, callback) => {
    request({
        url: req.url,
        method: req.method,
        agentOptions: {
            ca: fs.readFileSync("certs/ca.cert.pem")
        }
    }, (err, resp, body) => {
        callback(body);
    });
})

This allows you to basically proxy the localhost API calls but the request module allows you to specify a certificate to allow in the HTTPS agent.

Note: Unimplemented 😆 and I hope electron implements whitelisting as well 👍

[MarshallOfSound]

Also there is this older issue regarding this #1956

Which indicates the API https://github.com/electron/electron/blob/master/docs/api/app.md#appimportcertificateoptions-callback-linux would do the job but it appears to be linux only currently

[dteirney]

Would exposing the Chromium --allow-insecure-localhost flag through Electron help resolve our problem with accessing localhost over HTTPS with an untrusted SSL certificate?

https://cs.chromium.org/chromium/src/chrome/common/chrome_switches.cc?q=kAllowInsecureLocalhost&sq=package:chromium&type=cs&l=39

[MarshallOfSound]

@dteirney Lot's of chromium flags can be modified in the launch phase with this API

https://github.com/electron/electron/blob/master/docs/api/app.md#appcommandlineappendswitchswitch-value

import { app } from 'electron';

app.commandLine.appendSwitch('allow-insecure-localhost');

It might be worth seeing if appending that switch works

[MarshallOfSound]

Oh, here's a neat solution based on this API

https://github.com/electron/electron/blob/master/docs/api/app.md#event-certificate-error

app.on('certificate-error', (event, webContents, url, error, certificate, callback) => {
  if (/https:\/\/localhost/g.test(url)) {
    // Verification logic.
    event.preventDefault();
    callback(true);
  } else {
    callback(false);
  }
});

[tmpfs]

For the record the suggestion from @MarshallOfSound works nicely. I just implemented it today for https:// and wss:// using a self-signed certificate.

[zcbenz]

I'm closing this since certificate-error is designed for this purpose. Thanks @MarshallOfSound for providing all the solutions.