I just installed an SSL Certificate on my domain. and then I noticed that Social buttons (Facebook, Google+, Twitter etc) are no more there.
When I uninstalled the SLL, those buttons were there.
Anybody knows how to fix this issue?
most likely your code for the buttons refers to a non-SSL (http:// instead of https://) URL and most browsers nowadays reject content that is not "secure".
To elaborate on cfrick's answer, which sounds spot on:
It isn't that they reject the content that isn't secure, it is that they reject mixed content. So you can't show secure and non-secure stuff on the same page.
The solution is that for any fully qualified URLs with a protocol prefix (http or https), simply leave that off and modern browsers will use the same protocol as the page was loaded with. So instead of including content with http://example.com/stuff.js you can use //example.com/stuff.js.
Related
after upgrading to Safari 9 I'm getting this error in the browser:
[Warning] [blocked] The page at https://localhost:8443/login was not allowed to run insecure content from http://localhost:8080/assets/static/script.js.
Anyone knows how to enable the running of insecure content on the new Safari?
According to the Apple support forums Safari does not allow you to disable the block on mixed content.
Though this is frustrating for usability in legitimate cases like yours, it seems to be part of their effort to force secure content serving / content serving best practices.
As a solution for you you can either upgrade the HTTP connection to HTTPS (which it seems you have done) or proxy your content through an HTTPS connection with an HTTPS-enabled service (or, in your case, port).
You can fix the HTTPS problem by using HTTPS locally with a self signed SSL certificate. Heroku has a great how-to article about generating one.
After setting up SSL on all of your development servers, you will still get an error loading the resource in Safari since an untrusted certificate is being used(self signed SSL certificates are not trusted by browsers by default because they cannot be verified with a trusted authority). To fix this, you can load the problematic URL in a new tab in Safari and the browser will prompt you to allow access. If you click "Show Certificate" in the prompt, there will be a checkbox in the certificate details view to "Always allow content from localhost". Checking this before allowing access will store the setting in Safari for the future. After allowing access just reload the page originally exhibiting a problem and you should be good to go.
This is a valid use case as a developer but please make sure you fully understand the security implications and risks you are adding to your system by making this change!
If like me you have
frontend on port1
backend on port2b
want to load script http://localhost:port1/app.js from http://localhost:port2/backendPage
I have found an easy workaround: simply redirect with http response all http://localhost:port2/localFrontend/*path to http://localhost:port1/*path from your backend server configuration.
Then you could load your script directly from http://localhost:port2/localFrontend/app.js instead of direct frontend url. (or you could configure a base url for all your resources)
This way, Safari will be able to load content from another domain/port without needing any https setup.
For me disabling the Website tracking i.e. uncheck the Prevent cross-site tracking worked.
I installed my SSL certificate yesterday. However I get the SSL warning (triangle) icon. The excuse for that is that "the page includes other resources which are not secure".
I am not sure what that means but my assumption is that it has something to do with some text inputs which are not secure.
Any information or resources to make me understand more and figure out how to secure everything will be helpful. I don't like the warning there (especially on the signup page) and need to figure out what's the issue. Thanks.
You need to make sure not to embed any resources via http:// - use only https://.
If you embed external resources which are available via both HTTP and HTTPS, you can use protocol-relative URLs such as //domain.tld/whatever - they'll be loaded over the protocol that's currently used.
The Question
Is there a way to detect wether a visitor trusts the SSL connection/certificate? I really could not find anything on the web or on stackoverflow. I think it's a pretty uncommon question.
A Use-Case
I'm using a certificate from StartSSL. It works fine for most common and modern browsers. But on my Windows Phone using IE I get a warning. That's because the root certificate is not known to IE on Windows Phone by default.
The solution is easy: just download the certificate - two clicks/taps. I would like to provide a tiny guide to the common visitor on how to do this. However, only visitors with problems should get the message.
Visitors who connect to your site via HTTPS simply won't get to your site if they don't trust your certificate. Once an exception has been added, there's no way for you to determine whether or not it's generally trusted or an exception.
Perhaps you could try to build a list of user-agents and make a guess as to what their default CAs should be, so as to be able to display an additional message in this case. It's not a perfect rule (since you can never full control what the client trusts, it's the user/admin's responsibility), and has the disadvantages of user-agent specific content; in particular, it's not necessarily reliable, you won't have a complete database, and users who've already added the exception or imported the certificate permanently would see this additional message (unless you use something like a cookie to remember).
If your initial page is over plain HTTP, you might be able to try an XHR request to your HTTPS site and report whether it worked at all. (You might need to take into account the Same Origin Policy.)
I am not sure whether there is a foolproof way to auto-detect this condition. You may have to rely on a workaround.
Detect whether the request is from a phone by inspecting user-agent in the header, check whether it's the first time they are accessing your site (absence of your site's cookie etc.) and if they are first time user, redirect response to (HTTP) page with instructions to install the certificate. You can provide a check box on that page for users to supress that redirect behavior in furture. If they want it to be supressed, set a cookie, or store their preference on server (if there is authentication).
I have a problem with my site after implementation of SSL that images do not appear. The scenario is that images come from images.domain.com (hosted on Amazon S3) and my certificate is for www.domain.com.
This problem only seems to happen in IE and not in any other browsers.
The issue is related to "mixed content" - HTTPS pages which have HTTP resources (images, scripts, etc) embedded.
The point of using HTTPS is to ensure that only the originating server and the client have access to the secured page. However, in theory it might be possible for this security to be compromised if HTTP resources are embedded - a server might intercept an unsecured javascript file and inject some code to alter the secured page onload.
Most browsers will indicate that a secure page has mixed content by altering the "secure lock" icon, either by showing the lock as open or broken, or by making the icon red (Chrome displayed a skull and crossbones for a short time, but they realised that this was a bit serious for the potential threat level).
Internet Explorer (depending on the version) will display a message either asking whether the insecure content should be shown (IE<=7), or whether only the secure content should be shown (IE>=8). It sounds like you have somehow disabled this message to always hide the insecure content, however that's not the default behaviour.
I think the best solution for you is to replace your S3 links with HTTPS versions.
I am not a web developer, but someone who often deals with the crap experience that is IE. I am not sure what version you are using, but you do not have a wildcard SSL cert (i.e. *.domain.com), so does it have something to do with an old-school limitation in 3rd party images?
See here for what I allude to above and a very good explanation of how IE caches cross-domain HTTPS content, specifically images. I am not sure what the solution is, but I was curious so I researched a little myself and this might help.
I have a login screen which I'm serving over SSL. The user fills in their login/password, this gets POSTed to the server. At this point I want to jump out of SSL, so I redirect them back to the same page with no SSL.
This causes the browser to show a warning dialog "You are about to be redirected to a connection that is not secure". How can I avoid this? I've been plenty of sites like yahoo mail, and gmail that give you an SSL page for login, then send you to a non-SSL page after this.
Secondary question: what's the purpose of this dialog? It's trying to warn me about some nefarous purpose - but what's so bad about redirecting someone to a non-SSL page? I don't get a warning when I'm on an SSL page and click a non-SSL link. What's different about redirecting someone?
I'm doing this in ASP.NET 2.0 - but I figure this is a generic web-dev question.
UPDATE SUMMARY: It seems the popular answer is "DON'T AVOID IT". I can understand that a user should get a message when security it being removed. But I don't get a dialog when I follow a link and security is removed, so at the very least I'd say this is inconsistent.
The dialog / browser versions. I actually don't see the dialog in IE7/FF3 (maybe I've clicked a checkbox preventing it). More importantly the client DOES see it in IE6 - with no checkbox to remove it (yes, I know IE6 is old and crap).
Firefox2: FF2 http://img521.imageshack.us/img521/8455/sslwarning.jpg
IE6:
The alternative: make the entire site SSL, never redirect the user out of SSL. I could handle that. But I've got a semi-technical client who has some fairly good points:
"SSL is going to cause an increase in traffic / processing power". I don't really buy this, and I don't think his site is every going to require more than one box to serve it.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
I'm going to try sway the client over to an entirely SSL site. I'll argue Yahoo's approach made sense in 1996, or for a site that is MUCH more popular. Some official links explaining why this dialog happens would help (i.e Jakob Nielsen level of authenticity).
I've hit this same problem a while back. So I had a look inside fiddler to see how yahoo mail does it. Here's the step I saw (and used on my site):
User fills in SSL encrypted form, and POSTs to the server. Server authenticates, and spits out some script to redirect the client
<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>
I figure the client side code is there to avoid this dialog.
"How can I avoid this?"
You shouldn't!
Although you could try that with JavaScript. This might work on some browsers and fail on others.
"What's the purpose of this dialog?"
It warns because switching between SSL and non-SSL on websites is usually unexpected by the user. A warning about the "non-SSL to SSL" is not emitted since it increases security and privacy. However, when security is suddenly decreased, the user should notice that quickly, in order to avoid a false feeling of security. In fact, redirecting to a non-SSL site is sometimes used in XSS/MITM attacks.
"SSL is going to cause an increase in traffic / processing power"
This is nonsense. It might be true for sites full of big, static content. However, for normal dynamic web applications, encryption is very cheap compared to business logic, database access, etc.
There is an urban legend saying that SSL-content is not chached by browsers. See "Will web browsers cache content over https" for more information.
"Yahoo does it. Yahoo is a big technical company. Are you smarter than Yahoo?"
Some rhetoric counter-questions:
Are you a big technical company like Yahoo?
Did being a big technical company prevent Microsoft from producing crappy software?
Do you have to support crappy old (SSL-broken) browsers, as Yahoo has to?
The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.
As for the purpose: It's to make you aware that your connection won't be SSL encrypted anymore. You may have seen before that the connection is encrypted and may think that it still is, so this warning says "Just to be clear, whatever data you send from here on will be plaintext".
As for how to suppress it: AFAIK you can't, it's a browser thing, what would be the point of the message otherwise? Even though there are workarounds like client-side redirects, I don't think you should try to work around client "problems" like this. If the browser chooses to be verbose, let it. There's a "Don't show this again" checkbox on the dialog after all If the user wishes to suppress this message he can easily do so, and maybe he actually likes to see it.
Also, IMHO, if the browser was worth its salt it would still pop up this warning, even if you employed client-side redirect tricks.
Use SSL for the whole page in the first place!
There's nothing wrong with SSL. You should provide user privacy everywhere, not only on login. It makes sense an the whole site. So simply redirect all non-SSL pages to SSL pages and keep everything SSL.
Just point your client to the latest attacks against mixed mode content (lookup CookieMonster on fscked.org) and proxy attacks (against sites available both in http and https, lookup Pretty-Bad-Proxy). He might reconsider.
It is much easier to get security right if you only deal with one protocol without mixing the two. SSL adds a bit of overhead, but it is nothing compared to the cost of a breach.
Gmail, yahoo, etc. use SSL for an encrypted iframe, which authenticates, but there's none of the in-page redirection you're talking about. The whole page isn't encrypted for these login systems.
read:
http://support.microsoft.com/kb/883740
which says that this is fixed in a hotfix or with a changed registry setting. However, not all the IE6 cpu's we use have this problem, nor do their registry settings correspond to what this article says they should. Also some that give the msg are XPsp3 and IE6 sp3.
We have an https log in screen that uses code to log into 15 other (http) domains and some of our IE6 users have to click 'Yes' 15 times. This is inacceptable to them.
No, we cannot control what browser all our users use. Some are not compatible with upgrade to IE7.
We are looking for some config attribute for each user to adjust that will suppress this msg. We've identically configed a 'bad' browser with settings that match one that does not give the msg. Internet and Intranet Security and Advanced settings and Proxies (none).Also Network connections. No joy so far.
Any ideas?