+1  A: 

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.

vog
What about the case where the ssl domain is different from the app domain? Like a SSO type setup.
Joel Potter
Some might prefer to avoid SSL where possible because it consumes more bandwidth (encrypted data is generally larger than its cleartext equivalent), and incurs and extra CPU hit (for the actual encryption process).
Abignale
@Abignale: The cryptographic traffic overhead is AFAICS seldomly observed. In addition, cryptography is usually combined with compression, so if you haven't used compression (e.g. mod_deflate) before, the cryptography might even _decrease_ the traffic.
vog
@Joel Potter: If you don't have an SSL certificate for your own domain, then yes, you'll have a problem.
vog
+1  A: 

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.

deceze
There's not actually a "don't show this again" checkbox for that particular dialogue in firefox, at least.
Paul McMillan
Pfff, details... ;o)
deceze
+4  A: 

"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?
vog
As long as you can serve your static media from a non-SSL server it should be fine. serving static media over SSL means it won't get cached - making the experience quite a bit slower for no good reason
Jiaaro
@Jim Robert: This is an urban legend. See: http://stackoverflow.com/questions/174348/will-web-browsers-cache-content-over-https
vog
+5  A: 

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.

russau
+1: I was just about to suggest this.
Joel Potter
Just note that this depends on Javascript being active. I suppose you could use a meta redirect tag instead.
deceze
There'a a good reason for the browser to warn. You shouldn't circumvalent it without understanding why it's there in the first place. You should get down to the root of the trouble instead of fighting symptoms.
vog
"You shouldn't circumvalent it without understanding" - that's probably why I asked about it on Stackoverflow!
TesterTurnedDeveloper
@TesterTurnedDeveloper: I fully agree. So an answer should explain the good reasons for that warning *before* blindly suggesting ways to circumvalent it.
vog
This warning only shows up on IE6. There is no reason to support this warning. You have every reason to try to suppress it if you can.
Haluk
A: 

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.

Paul McMillan
But then you get messages about 'this page contains secure and insecure content'
Martin Beckett
I think that most modern browsers only show that if your root page is SSL. Since this is an unencrypted page with encrypted content, that doesn't show up.
Paul McMillan
+1  A: 

The attack this is preventing against is a man-in-the-middle SSL session strip. The message is there with good cause.

+1  A: 

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.

Nasko
A: 

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?