Low security sites, what to do about them?

— Posted inMiscellaneous — 10 min read

I've recently posted1,2 about sites that are not using as strong encryption as they should. The sites may use weak encryption or mix secure and
unsecure content.

In many cases these sites expose their customers to the risk of their data being leaked, and several kinds of unsecure website practices may actually train the users in trusting unsecure sites, thus helping phishers.

What can we browser vendors do about such sites? Let's take a look at some of the possibilities, some realistic, some less so.

40/56 bit encryption and SSL v2

These encryption methods are now too weak to be trusted with anything. Yet some sites are still using them, in particular the 40/56 bit encryption. Opera 8 display a warning about these sites, and uses a level 1 padlock, and Opera 9, by default, does not support these encryption methods, and the same applies to IE7 for Vista. Effectively, newer browsers will not support these sites.

One option for us browser vendors is to remove the padlock for such sites, indicating that the site is not secure.

Weak certificate keys

Some sites, for some reason, chooses to create RSA keys that are just 512 bits long. These keys no longer provide any effective protection of the site, since (my estimate) they can be broken in two weeks, after which the encryption and integrity security of the site is completely broken, and attacker can do anything with the data without being detected.

Since Opera 8 we warned about such certificates. Before that we indicated their presence with a Level 1 padlock, and still do. In Opera 9 we also display a grey security toolbar, not a yellow one.

Another thing that can be done about these sites is, as above, to remove the padlock.

A more radical possibility could be to refuse access to sites with such weak keys. Perhaps TLS error code 71, "insufficient_security", could be used for this? Admittedly, it's description specifies it as a serverside error code, but I see no problem with a client using it.

Secure pages with unsecure content

Some sites use content from unsecure sites in their secure pages. Usually this is relatively benign; the content is "just" some advertisement or website tracker. Sometimes, however, the mixing becomes far more unsafe, as the unsecure content contains data revealing what you are doing or looking at, e.g. the unsecure images contain sensitive information, and in more serious cases the use of unsecure content actually *breaks* the security of the page. When the unsecure content is actually CSS or external Javascript files that modified by an attacker these files can be used to manipulate or even listen in on the website activity!

Opera has long been displaying an open padlock for these pages, perhaps what should be done is to remove the padlock altogether?

Other browsers display a prompt about such pages, but it can be disabled, and these browsers do not, at present, remove the padlock for such pages.

IE7 was supposed to actually block such unsecure content, but I was recently told that Microsoft had encountered [too many] sites that could not handle being blocked in that fashion, and had gone back to the IE6 modal dialog prompt. In my opinion, Microsoft should reconsider and stick with the blocking policy, even though it will break some sites, until they are fixed (if possible). Personally, I would like to change our policy to block such mixing.

Unsecure pages with secure content

Then you have the opposite secure/unsecure mixing, embedding secure content inside an unsecure page. In may cases this combination is also relatively benign, the secure components are just small images.

In other cases the combination is more problematic because the content may be a frame used to submit sensitive data, like credit card information. How does the user know that the data is transmitted securely? They don't unless they analyze the entire page.

No browser will display a padlock for these pages, since the main document is a HTTP page, not a HTTPS page, meaning that none of the usual "this is secure" indications are displayed.

In many cases the website "helps" the user determine that the site is "secure" by displaying padlock symbols and "this is a secure page" logos from the Certificate Authority. The problem with these symbols is that they are in the page, and the webmaster can put anything he or she wants in a page, including fake padlocks.

Why do sites do this? I think in many cases the webmaster either wants to save a few dollars on server capacity, because "everybody knows" secure connections cost a bit of computational resources (Bob Lord from the Mozilla team debunked this a while ago). In other cases it may just be that they do not think through the consequences, and in yet other cases the credit card transaction is performed by a third-party site, with another domain name, and they think the user should still see their domain name, not the payment site's domain name.

The consequence of this is that these sites acclimatize users to submitting sensitive data from unsecure pages. When people stop looking for the combination of the "https" and the padlock and instead just look for the website's logo (which can be, and of course often is, faked), they become incredibly vulnerable to phishing attacks.

Sites causing certificate warnings to be displayed

Certificate warnings can be displayed for a number of reasons:

  • Unknown issuer: In this case the browser does not know how to verify the certificate because it does not have all the certificates needed to link it to a certificate stored in its own repository of trusted root certificates. This means that we do not know if the certificate is actually a fake. It's like somebody saying they are a police officer, but not having the badge to prove it (Exercise for the student: How do you tell that the badge is real?).
  • Server name mismatch: Here the certificate can actually be verified, but it turns out to have been issued for another server, not the one to which the client is connecting. In most cases this is caused by a server administrator hosting several secure servers on the same server without buying a certificate naming each server. However, it can just as easily be a spoof website relying on you to accept the assurances that there is no problem and you can "just click accept". This is like a police officer with a real badge, and you are able to confirm that, but the badge is issued by another country. How do you know that this officer is authorized to act as a police officer in your country?
  • Expired certificates: In this case the certificate verifies OK, but the it is past it's "use before date". Like milk, driver's licences and passports, certificates can only be used within a certain period of time. For certificates this period is in part determined by how well the private key associated with the certificate can be protected by the owner, not just from external attacks, but internal ones as well. A server certificate is usually valid for a year or two, intermediate certificates usually less than 10 years, while root certificates, whose private keys are usually locked up so that several people are needed to access them, are usually valid for decades.

The common factor for all these is that when a certificate warning is displayed you essentially do not know who you are talking to if you decide to accept the certificate despite the warnings. Serious websites should not trigger warning messages.

All browsers display warnings about certificates such as the above. Additionally, Opera displays a padlock of level 1 when the user has manually accepted a certificate, but it is definitely a question of whether or not the padlock should be displayed in such cases at all.

Some browsers allow the user to permanently accept such certificates. I am not sure I like that capability, but that just might be a little bit too much "paranoia". In any case, I think such a bypass feature should be timelimited, perhaps 6 to 12 weeks, and only for the condition it was originally accepted. Such sites should also be consider low security sites.

Submitting sensitive data from an unsecure page to a secure server

Some sites, in particular some banks, have put their login forms on their unsecure frontpage. As I have mentioned before, this is not a secure arrangement because the user has no way to determine that the form is actually secure, and only does what the bank originally intended, in particular since an attacker can modify the page with the form while it is in transit.

As I mentioned in my earlier article browser vendors have a few options about what to do about such sites, with varying degrees of inconvenience for the user, ranging from unobtrusive warning indications, via warning dialogs to refusing to submit the information.

As mentioned above, one possibility of handling low security websites is to remove the padlock. One problem with this approach is that users that are already told to look for the "https" in the URL in addition to the padlock, or perhaps instead of the padlock. And by removing the level 1 (halfopen) padlock we risk that less serious webmasters will say "as long as you see 'https' at the start of the URL you are secure".

This means that we may need a way of indicating that "https" does not mean it is always secure (there are methods in SSL/TLS that only promises encryption with an anonymous server, and other methods that verifies who you are talking to, but does not provide any encryption; but both those options will result in warnings from Opera and a level 1 padlock).

Several methods are available:

  • Do not show the URL at all. I don't like this option at all. It may be that full URLs are "geeky", and that they may be difficult to understand for the layperson, but they give a much better way of finding out where you are than almost anything else.
  • Put a big red "X" over the "https" when the connection is not really secure, just use a red background, like has been proposed about phishing sites.
  • Change the "https" to "http(s)", at least in how the URL is presented in the address bar.
  • Use some other form of graphical indication

Personally I like the "http(s)" option since it is, at least in Opera, relatively easy to do this kind of display modification, and I certainly hope it would make those who look at the address bar stop and think. The main problem may be that it could be too subtle.

Whether or not any of these possibilities get implemented, or are practical, is an open question. Some of the more radical options cannot be implemented unless all the browser vendors agree to implement it.

10 replies on “Low security sites, what to do about them?”

  1. You have to be aware that every presented warning increases the habituation of the user to dismiss it without thinking. Many self-signed webmail services or institutional sites do not bother to get a real cert and briefly instruct their users to accept/install the self-signed cert (or in my case server names are aliased without thinking of the consequences “mailhost.xxx” (valid) -> “webmail.xxx” (invalid)). If the warnings are displayed forcefully their alerting effect will diminish.The warnings have to be salient and low on verbosity to alert the user about serious risks like MITM spoofing attacks.

  2. Very informative article. Why doesn’t Opera do what IE does: have a message pop up asking us whether we want unsecured content and if not, then only secured items are shown and Opera can give it a secured rating with padlock closed. And have an option in Preferences to block them automatically without pop-up message.At it is now, both secured and unsecured items are shown. I would rather use IE for this as I can be sure unsecured items are blocked.I like Opera for its smooth speed although I use Maxthon as my default browser for its customizable features. Opera cannot be customised as well as Maxthon. For example, autohide the side panel, close tabs to left/right, etc.

  3. charlieccm: The problem with a warning dialog is what towolf in the comment above yours pointed out, that users start dismissing them without considering what the warning means.It’s almost certain that we have too many dialogs today, and we need to reduce the number. The question is how we should handle the situations that trigger the current dialogs without reducing security.As I mentioned in the article, MS tried blocking unsecure content within secure pages in IE7, but ran into too many problems as pointed out above, and reversed course (which I think they shouldn’t have done).

  4. Hi Mr Pettersen,I understand your concern about too many pop-ups which many novice users will just ignore.However, IE6 and IE7 does at present block unsecured content by two methods: first, a pop up asking whether you want to block and second, an option in the Internet Zone in Internet Options to “disable” mixed content. The second method automatically blocks unsecured content and allows only the secured content through.I suggest that since you don’t want pop-ups, to have an option similar to IE’s second method. And better still, to have a button similar to ‘Fit to Width’ which when clicked will reload the page minus the unsecured content, and then show the address bar with padlock locked and with a security number. As it is right now, Opera users must have both secured and unsecured content on some https sites and there is nothing they can do to block the unsecured content.

  6. Thanks for the link. The article was very informative.My point is that although it is difficult and there are obstacles, IE6 and IE7 still have option to block unsecured content. Opera doesn’t. But it’s not a big problem. I like Opera being light and fast. If I come across such mixed sites, I’ll use IE to block the unsecured content.

  8. What somebody could do, depending on placement and usage, in the chase case is to replace the Flash applet with another applet, and use it to harvest account data. A worrisome thing about this particular case is that the applet is apparently closely associated with the login procedure, and is hidden in a 0-by-0 iframe by the name “loginframe”. Worst case is that the credentials are actually passed through that applet, in which case an attacker can do whatever he wishes with the data. If the applet is just a datasource, then the data it generates can be compromised.

Comments are closed.