There is a WP Core Trac ticket for enforcing HTTPS everywhere: https://core.trac.wordpress.org/ticket/28521

There is already a degree of this HTTPS-enforcement as part of the whitelist sanitizer which would be more robust than what is possible in core, since core doesn't have access to the DOMDocument response. We could implement some of the ideas from the core ticket while waiting for it to land in core, and add additional enforcement at the sanitizer layer.

Something else to consider is to add an HTTPS proxy as part of the plugin as a fallback in case HTTPS is truly not available. This could be incorporated from the HTTPS Resource Proxy in the Customize Widgets Plus plugin:

When FORCE_SSL_ADMIN is enabled (such as on WordPress.com), the Customizer will load the site into the preview iframe using HTTPS as well. If, however, external resources are being referenced which are not HTTPS, they will fail to load due to the browser's security model raise mixed content warnings. This functionality will attempt to rewrite any HTTP URLs to be HTTPS ones via a WordPress-based proxy.

See https://github.com/xwp/wp-customize-widgets-plus/blob/master/php/class-https-resource-proxy.php

See also issue regarding media in #130, as this may supersede it.