You asked: "Is there some way to determine what exactly is being blocked?", and the answer is yes.
Definitely, the most effective way to check what is going wrong within your browser is... to ask directly to the browser :-)
Recent version of modern browsers (like Firefox and Chromium/Chrome) includes a "Developer tool" which, among lots of other things, can
report exactly which HTTP request the browser is sending over the network and, for each of them, which response got back (if any...) from the remote webserver.
In Chrome/Chromium world, the developer tools can be accessed with CTRL-SHIFT-I or, if you prefer menu path, "Tools"=>"Developer Tools"
In firefox (at least in mine, v. 33) the sequence is the same.
Once you have "Developer Tools" activated, you can select the "Network" tab. Afterwards, if you point the browser to your original URL, than the browser will reports all the details.
Also, I suggest also to check the "console" (select proper "tab" within the "developer tools" area) as it may contains lots of useful information, at least when you're experiencing some problems :-)
P.S.: as for the message reported by the browser (Some unencrypted elements on this website have been blocked), I bet the browser is complaining because you're accessing an SSL-protected URL and the HTML that is coming back from such URL does contain some reference to other resources (CSS, images, scripts, etc.) accessible with standard HTTP, without SSL protection. So, the browser, instead of sending clear context over the network, decides to "block" them.
You can't disable the mixed security check at site level. If browser would allow it, this behavior will provide a false sense of security and defeat the trust on the use of HTTPS.
Some browsers allow the setting to be disabled on per-installation basis. For example, you can disable the check in Firefox by changing the setting
security.mixed_content.block_active_content
in about:config
.
Chrome doesn't allow it explicitly, and the only way is to click on load anyway. It is also worth to mention that newer versions of Chrome no longer display a crossed padlock, instead Chrome will essentially downgrade the security of the page to HTTP if you load any HTTP content.
Best Answer
HSTS doesn't try to handle mixed content at all: it just controls whether the browser should perform an internal
307
redirect to HTTPS whenever it tries to load HTTP URLs, or not. The mixed content warning is a feature of the browser, and all the current browsers do it (Mozilla Firefox 23+, Google Chrome 21+, Internet Explorer 10+, Edge from the beginning...). The mixed content warning blocks e.g.<script>
and<iframe>
, but not<img>
.The mixed content warning on all the browsers mentioned is checked before loading any content at all, i.e. before HSTS redirects, too. This seems only natural, and is also easy to test. By default, all external images are loaded even using plain HTTP, and a mixed content warning is given only for scripts and iframes.
HSTS only changes the situation where an image from an HSTS enabled domain is loaded using plain HTTP, and
307 Internal Redirect
is performed. Worth noting: this is a situation with no mixed content warnings involved.Therefore, HSTS does not work as a quick fix for the mixed content problem:
http://
URLs on your site even for the domain itself.