Asking users questions never increases security
Here is something that I've more or less written about before, but I want to reinforce by saying explicitly:
Asking users questions never increases security.
Never ever. Really.
(See SecurityChoiceProblem for a discussion of why.)
What this means is simple. Every time you design a system where part of the design is 'if something questionable happens, we will ask the user if they approve it', assume that at least half of your users will make the wrong choice. Ask yourself what this does to the security of your system, and then ask yourself if the question is actually doing any good or if the real design purpose is so that you can say with a straight face 'we tried to solve this problem, but the stupid users are screwing it up; it's their fault, not ours'.
Then delete the question and either make the system work anyways or give up, admit that you are not delivering perfect security, and figure out how to do the best you can despite this.
In reality, of course, it will not be just half of your users who answer the question wrong, because users do not answer mysterious questions by picking randomly. Instead they pick whichever choice it is that lets them do whatever they were in the process of doing. Users almost always want to do what they're trying to do, even when it is actually a mistake.
(Sometimes, if you are very lucky, you can catch the user's attention long enough to persuade them that they're making a mistake. But this is very difficult for good reasons.)
If you are firmly convinced that what the user is trying to do is a mistake, tell them so very strongly, and tell them why. I am almost tempted to say don't give them any way to overrule you, but that's too strong. What you shouldn't do is present them with a yes/no question or some other dialog that implies that the two options are equally likely, because you've already decided that they aren't. 'Go on anyways' should be tucked away in tiny print, not given equal billing with 'get me out of here'.
(If you can't be almost certain that the user is making a mistake, see above. Find some way to not ask the question at all.)
(I've written about this issue before in SecurityChoiceProblem, but there I was more focused on configuration and setup questions instead of questions that you want to ask the user on the fly during normal operation.)
Why https was a mistake, but an inevitable one
As I alluded to in a comment here, one reason that we can't expect people to understand that 'low quality encryption' is basically 'no encryption' is that browsers don't. In fact the issue shows why having a distinct and specially marked 'https' is ultimately a terrible mistake; it has trained programmers and users that https means security, when in fact it doesn't.
What would have been much better is if browsers hid the difference between the raw protocol being used and instead showed an indicator of the degree of security involved. This would have had two beneficial effects. First, it makes it much easier to deploy opportunistic encryption to foil passive eavesdroppers, since you are not telling people that the use of SSL means that they are secure (instead you are hiding that SSL is in use). Second, it lets browsers only mark things as secure if you are using SSL parameters and certificates that are actually secure, not just if you are using SSL at all.
Okay, it would also have a very important third effect: it would have at least tried to communicate to users the thing that is actually important, that being the security of your connection. Using SSL is merely a necessary prerequisite to actual security and so the current situation tells users about an implementation detail.
(Thus it is not a surprise to me that current browsers tend to de-emphasize the whole 'you are using SSL' business. Sadly this is too late in practice; people's expectations are too solidly set by now.)
Transparently attempting SSL without slowing things down has a number of technical issues, but there is a deeper reason why it wasn't really possible to do this back in the dawn of the web when SSL was being introduced. The simple summary is cryptography export controls. Back in the days, US companies were not allowed to export products with actual secure cryptography, only ones with aggressively weak keys. In a theoretical world where browser vendors are turning address bars yellow because of security instead of SSL, this presents the browser vendors with the serious issue of how to show this to users.
The honest approach is to not mark these weak ciphers as secure in any version of the browser. This is unpopular with the purchasers of SSL certificates, who are after all paying money in order to have people's address bars turn yellow; it is especially unpopular with non-US server operators, whose servers only did insecure key lengths and so would never get yellow address bars no matter what SSL certificates they bought.
The 'as secure as possible' approach is to mark these weak ciphers as secure only in the international version of the browser. Now you have a confusing user experience; the same website using the same SSL will be shown as insecure in one browser and secure in another. (This too is not so popular with non-US SSL server operators, who will never be shown as secure to US users.)
(Always marking these weak ciphers as secure even in domestic browsers makes a joke of your claim to be turning the address bar yellow only when the connection really is secure.)
Turning address bars yellow on SSL instead of security has the great advantage of avoiding all of this. You have a simple rule and your international and domestic browser versions behave the same on all SSL-supporting websites.
(PS: I'm sure that the technical issues alone were more than enough to sink the whole idea of transparent SSL back when it could have been introduced.)