4

I have clients who use HTML on their pages, that I provide. That HTML links to files on my server (JS, CSS, images, etc).

Example of what I give them:
<link type="text/css" rel="stylesheet" href="http://www.example.org/this.css" />

I just got an SSL, so my site is now https. However the HTML on their server, that I gave them, is still http when requesting files from my server.

Because of this, they are getting mixed content warnings and the content is blocked. Like this:

Mixed Content: The page at 'https://www.example.org/' was loaded over HTTPS, but requested an insecure stylesheet 'http://www.example.org/file.css'. This request has been blocked; the content must be served over HTTPS.

I can't have all of my clients change all of their links on all of their pages to "https" so that warning/blockage is prevented. That would be a nightmare.

My host is GoDaddy. My server is a Windows server, IIS: 7.0, ASP.Net Runtime Version: 4.0/4.5.

How can I resolve this on my end through web.config? My current rules are:

<configuration>
<system.webServer>
    <rewrite>
        <rules>
            <rule name="HTTP to HTTPS redirect" stopProcessing="true">
                <match url="(.*)" />
                <conditions>
                    <add input="{HTTPS}" pattern="off" ignoreCase="true" />
                </conditions>
                <action type="Redirect" redirectType="Permanent" url="https://{HTTP_HOST}/{R:1}" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

What I want to happen is have all outside http requests to my https server, to be allowed.

Thanks!

chris
  • 577
  • 1
  • 9
  • 23

1 Answers1

8

You can serve the site with a Content-Security-Policy: upgrade-insecure-requests header.

The upgrade-insecure-requests CSP directive can also be specified using a meta element:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

The HTTP Content-Security-Policy (CSP) upgrade-insecure-requests directive instructs user agents to treat all of a site's insecure URLs (those served over HTTP) as though they have been replaced with secure URLs (those served over HTTPS). This directive is intended for web sites with large numbers of insecure legacy URLs that need to be rewritten.

The upgrade-insecure-requests directive is supported in all current browsers.

Incidentally, the “The page at 'https://www.example.org/' was loaded over HTTPS, but requested an insecure stylesheet 'http://www.example.org/file.css'” message is not one that anybody would get by just having a <link…href="http://www.example.org/this.css" /> element in the HTML for their own site. The only way they would get that message is if they navigated directly to https://www.example.org/.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • Thank you for the articles. Is there literature explaining how to implement the CSP? Is it a file placed on the root? Is it added to web.config? I don't have access to client pages, so everything I do, has to be done on my end. – chris May 23 '17 at 21:54
  • See the updated answer. I don’t understand what error your clients are actually getting. They would only get the error about mixed content at your site `https://www.example.org/` in the case where they navigated directly to your site. They will not get that error if their site `https://www.their.site/` just contains a link element that references `http://www.example.org/file.css` from your site. So you may want to use https://stackoverflow.com/posts/44144435/edit to edit/update your question to indicate what error your clients are seeing and under what conditions. – sideshowbarker May 23 '17 at 22:00
  • As far as literature explaining how to implement CSP, it’s just a response header so yeah you can change your `web.config` to add it to all responses from your own site. That’ll eliminate the error message cited in the question. But as far as any error caused by your clients having HTML that includes , that’d be a different problem but not a problem that would cause browsers to show the error message cited in the question. So again I’m wondering what error your clients might actually be seeing in that case. – sideshowbarker May 23 '17 at 22:05
  • Some of their sites are http, some are https - both calling an http file from my https server. – chris May 23 '17 at 23:39
  • So you are saying that regardless of whether or not the client's site is http or https, they will not get a mixed content warning or blockage when using an http link to my https server? – chris May 23 '17 at 23:40
  • Maybe I was concerned about nothing. I opened the HTML on my server with the http link instead of https to replicated what they would see...but from what I gather from you, is that I'm only getting the warning because I'm on my https domain trying to pull an http link. They would not because they are not on my domain. Correct? – chris May 23 '17 at 23:42
  • @chris Correct. You’re seeing the warning because you’re on your own https domain trying to pull an http link. And your clients will not get a mixed-content warning/blockage for and http link element to your server if the client’s site is http. However if the client’s site is https they will get a mixed-content warning/blockage, but they would have already been getting that anyway before you enabled https for your site. – sideshowbarker May 23 '17 at 23:53
  • Perfect. Thank you! Should I delete this question? I mean, you answered my question, but I don't want to muddy up SO with a non-issue... – chris May 24 '17 at 00:08
  • No, please don’t delete the question. You’re not muddying up SO with a non-issue. Mixed-content behavior is not super intuitive and not well documented in existing questions and answers here at SO, so others here are likely to wonder about pretty much the same thing you did, and likely to come to SO later looking for related questions and can find this. So I think you’ve helped others by taking time to ask here. – sideshowbarker May 24 '17 at 00:13