I'm currently building a website for our business, where the website is expected to work perfectly, even back to the earlier IEs down to 7.
URL - https://secure.marietta.at
The page does not load any insecure content in Chrome, but I can see in IE that there is a GET param sent to http://marietta.at, which in turn redirects to http://en.marietta.at
I have no idea where I've specified this. I tried deleting scripts, checking the css, debugging with IE's own debugging tool and in HttpWatch Studio. I can't find the offending piece of code.
Are there any particular gotchas in IE that might trigger this warning?
Your HTML source contains the line
<script type="text/javascript" src="js/jquery.min.js"></script>
which makes the browser try to fetch the URL https://secure.marietta.at/js/jquery.min.js. However, this URL doesn't actually return any JavaScript code like you'd expect it to, but instead redirects to http://marietta.at/.
The fact that you later load another, working copy of jQuery from another URL hides this problem.
I would suggest either of the following solutions:
Remove the broken jQuery URL from the page.
Put an actual copy of jQuery at that URL so that it works (and remove the other, now redundant copy from the page).
I'd also suggest configuring your webserver so that it doesn't redirect from HTTPS to HTTP URLs, as that may violate the user's security expectations in general.
Load your page in IE and view the source code. There are quite a few hard coded references to http://en.marietta.at. Seems like some of your jQuery calls might be loading that "insecure" content
Ok, I've figured it out - never load JQuery twice (esp. from with an invalid URI). I've mistakenly left it in the <head> and just above the <body> tag which resulted in the SSL error. Deleted one, which got rid of the error.
Related
I'm developing a chrome extension that renders and sidebar iframe in Gmail.
A while back, we ran into a Content Security Policy issue that broke our extension and ran into a well-known error that shows up in your console as
Refused to frame '[OUR DOMAIN]' because it violates the following Content Security Policy directive: ...
To fix it, we had to rewrite the CSP header as explained in this blog post.
However, recently, we've been getting the same error, even after having implemented the fix suggested in the blog post.
As you can see, even though we added the chrome.webRequest.onHeadersReceived listener to overwrite the CSP header, our domain doesn't seem to be working. As a result, our sidebar does not load.
Notes and attempts:
Note that upon refreshing the entire page, the sidebar will sometimes load successfully %50 of the times, which leads me to believe that we're not adding the above event listener fast enough. To solve this, I pulled the event listener out of our background class and placed it at the top of the background js script. However, this issue seems to still persist.
We've tried to remove and re-add the extension but that didn't yield any permanent results.
Throughout testing, I also noticed that adding another extension that implements a similar override on the CSP header will cause our extension to break. Removing and re-adding our extension brings us back to the 50-50 issue in the first note.
[Update]
It seems that being able to reproduce it %50 of the times has to do with the version of chrome. After upgrading it to 72, I'm now able to reproduce the issue. However, doing a hard refresh on the page will sometimes allow the page to load.
More details on our setup: What we do is basically have a background.html which contains html templates and we have one template that contains an iframe tag. To get the template with the iframe, we do a sendMessage, grab the response, which is the template in string, convert it to DOM element via jquery, append it to body, and change the iframe's src attribute. What happens is the iframe loads fine initially, but when you click on any link in the iframe that would redirect to another page, the same error above shows up.
I can provide snippets and more info if needed.
When using JS/CSS from unsecured CDN in https page,
A. Some pages block loading js/css, and cause runtime error by short of js code.
B. Some pages do not block loading js/css, pages are shown as entirely insecure contents.
What is the difference of these behaviors?
Even if using same browser (I'm using Chrome 51.0.2704.103 (64-bit) in Mac OS X) and seeing same page, behavior changes sometimes...
May some response headers of index.html or so control this behavior?
Anyone know about this?
Example:
My friend create page https://cfn-iot-heatmap.herokuapp.com/, in before, this page's behavior was like A, contents are totally white out.
In this case, insecure CDN contents are:
https://cdn.leafletjs.com/leaflet-0.6.4/leaflet.js
https://cdn.leafletjs.com/leaflet-0.6.4/leaflet.css
I got source codes of this page and deployed to my heroku repository https://kinkyujitai.herokuapp.com/, it is shown like B.
But curious, after I deployed my repository, friend's repository also works like B, showing security warning but shown.
It is very curious, so I want to know the reason of this phenomena...
From a secure (https) origin, you should always include secure elements.
If you don't, browser can block insecure request and/or remove the visual indication of the security.
I've added a SSL certificate to an existing site, and now in IE I get a mixed content warning. Problem is, I don't know what's the non-secure content IE is warning me about. It's a simple html page, with a few Flash, a few images, a loaded CSS and JS.
How can I find out what's the non-secured content..?
Edit:
I found the culprit: it's the JS AC_RunActiveContent.js used to display Flash movie. So anyone has an idea on how to prevent SSL mixed content when using AC_RunActiveContent.js.?
This means that something is requesting content using the http protocol specifically, or you have an absolute path to an image or other content that begins with http instead of https.
A few tips: Use relative paths everywhere you can. If you must use an absolute path, and it's to a server you own, use https. If you're loading stuff from off your site, you're probably stuck with the mixed-content warning.
This also goes for your scripts, check out the JS, and the CSS template and make sure they're not the guilty parties - if they are change them to use relative paths, or to request items via https instead of http (assuming you're positive that the server they're referencing supports https, if it doesn't you're stuck).
There are a few other details, this might be helpful.
Ok, so here is the solution for my particular problem. It was the codebase value in my code that needed to be https as well (I didn't think it would trigger the warning, as my Flash were displaying correctly, oh well)...
AC_FL_RunContent( 'codebase','https://download.macromedia.com/pub/shoc...
Link to Adobe info on this: Security Information error in Internet Explorer
I use the Firefox console -- it reports the http resources it blocks from fetching on a mixed content page.
Search your source for http: only. Another great tool to help you out is Fiddler with which you can see what's getting downloaded upon requesting your page.
I've just got a site running nicely with the whole site running through SSL, but Google Chrome is throwing a "This page contains some insecure elements" message, which isn't good in terms of end user trust-ability. All other browsers work fine, and give the golden padlock.
The site is a Drupal 6 e-commerce site, running on apache2, and the error appears in the front end as well as the admin area.
Does anyone know of any methods to find out exactly which elements are being considered insecure?
Edit: I've used Fiddler to check the traffic, and it really is all HTTPS. It even complains on the site holding page, which is very light and has no javascript etc on it...
It could be a browser issue? Have you tried restarting, or clearing all of your cache?
In Chrome, this is trivial. Hit ctrl+shift+j to open the developer tools, and it will plainly list the URL of the insecure content.
Try it on https://www.fiddler2.com/test/securepageinsecureimage.htm, for instance.
I just had a similar problem. Turns out it was a hardcoded background image URL in a CSS file.
You should particularly check any 3rd party stylesheets you are using, as they may hotlink to an image on another server.
Easy solution? Save those images to your server and change the URLs to relative paths in the CSS file.
Hope this helps!
Search the source for http:? Something like <Ctrl-U> <Ctrl-F> http: in firefox should do.
The insecure element is something loaded over insecure — non-https — connection, e.g. image, stylesheet, etc. you obviously need fully qualified URL to load insecure element/
Use Firebug plugin of Firefox. In the NET tab all file locations are shown clearly. Try to find any files that are obtained from http protocol.
It's probably related to this bug:
http://code.google.com/p/chromium/issues/detail?id=24152
Which is why a restart fixed it.
When I go to our web site through HTTPS mode, Chome is reporting an error saying that the page contains secure and not secure items. However, I used Firebug, Fiddler, and HttpDebuggerPro, all which are telling me that everything is going through HTTPS. Is this a bug in Chrome?
Sorry but I'm unable to give out the actual URL.
A bit late to the party here but I've been having issues recently and once I had found a http resource and changed it was still getting the red padlock symbol. When I closed the tab and opened a new one it changed to a green padlock so I guess Chrome caches this information for the lifetime of the tab
Current versions of Chrome will show the mixed content's URL in the error console. Hit CTRL+Shift+J and you'll see text like:
"The page at https://www.fiddler2.com/test/securepageinsecureimage.htm contains insecure content from http://www.fiddler2.com/Eric/images/me.jpg."
I was having the same issue: Chromium showing the non-secure static files, but when everything was http://.
Just closing the current tab and re-opening the page in another new tab worked, so I think this is a Chromium/Chrome bug.
Cheers,
Diogo
Using Chrome, if you open up the Developer Tools (View > Developer > Developer Tools) and bring up the Console and choose to filter to warnings, you'll see a list of offending URLs.
You'll see something like the following if you do have insecure content
The page at https://mysite/ displayed insecure content from http://insecureurl.
For the best experience in finding the culprit, you'll want to start your investigation in a new tab.
It is possible that a non-secure URL is referenced but not accessed (e.g. the codebase for a Flash <object>).
I ran into this problem when Jquery was being executing a a few seconds after page load which added a class containing a non-secure image background. Chrome must continually to check for any non-secure resources to be loaded.
See the code example below. If you had code like this, the green padlock is shown in Chrome for about 5 seconds until the deferred class is applied to the div.
setTimeout(function() {
$("#some-div").addClass("deferred")
}, 5000);
.deferred
{
background: url(http://not-secure.com/not-secure.jpg"
}
Check the source of the page for any external objects (scripts, stylesheets, images, objects) linked using http://... rather than https://... or a relative path. Change the links to use relative paths, or absolute paths without protocol, i.e. href="/path/to/file".
If all that if fine, it could be something included from Javascript. For example, the Google Analytics code uses document.write to add a new script to the page, but it has code to check for HTTPS in case the calling page is secure:
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
On the release of Chrome version 53 on Windows, Google has changed the trust indications to initiate the circle-i. Afterward, Google has announced a new warning message will be issued when a website is not using HTTPS.
From 2017 January Start, Popular web browser Chrome will begin
labeling HTTP sites as “Not Secure” [Which transmit passwords / ask
for credit card details]
If all your resources are indeed secure, then it is a bug. http://code.google.com/p/chromium/issues/detail?id=72015 . Luckily it was fixed.