Implementer's notes

Over the past few years browser vendors have been steadily raising the bar for what can be called secure connections and documents. SSL v2 has been phased out, as has 40- and 56-bit encryption. Extended Validation (EV) has been introduced to provide better identity assurance, and the W3C is about to release the Web Security Context UI specification to make the security indicators more consistent.

There is, however, (at least) one area where this development has not come as far as I think it should have: Unsecured content is still allowed in secure documents. Some clients do give the user a warning (MSIE for example, Opera and FF do not), but as far as I know none show a padlock for such pages.

Some may wonder why such mixing is a problem, so here is a short description of some issues:

• Unsecured content can be read by anyone listening in the connection (Not very polite of them)
• Even worse, somebody listening in is almost always in a position to change the content (But, that's ... criminal, right?)
• Some content, like images, can tell the eavesdropper what you are doing.
• Other content, like JavaScript and CSS, can directly change the content or appearance of the webpage. If modified by an attacker, the page could be made do things you neither you nor the designer would like, like send your password and credit card details off to the attacker.

Therefore, using unsecured content in an otherwise secure document can, in some cases, leak information, while in others it can compromise the security of the *entire* site.

A very "popular" excuse for using mixed security in a site is that it reduces load on the server, because of the cost of SSL connections. This excuse was debunked by Bob Lord (formerly of Mozilla) a few years ago. The most costly operation for a secure secure server is the private key decryption step of the initial SSL handshake, and on a well-configured server that is an operation done no more than once a day per client. The remainder of the extra work is the encryption, and modern encryption methods like AES have been designed to be as efficient as possible. Both of these operations can be performed using hardware accelerators, which should reduce your total hardware cost if you do have heavy traffic to your site.

By ensuring that your server is serving HTTP 1.1 content, that it properly support and specify cache directives, persistent connections and pipelining, that you can maximize your server's efficiency. If you still think your site is under too heavy a load, perhaps you can reduce the complexity of the documents, simplify images and scripting, and rely on CSS to place the content correctly?

In most cases where we see mixed-security content used these days, the reason is not cost reductions, it is due to copying code, for example an analytics JavaScript tag, without examination of the code, forgetting to change the URL to https, and during testing not noticing the security warnings some browsers do show (unless the testing is not done on a secure site, but an unsecure one, which might explain some of the curious aspects of this).

In my opinion such mixing is long past its use-by date. It may have been (or seemed) necessary in 1998, but not in 2010, especially with the much more hostile environment that now exists, such as phishing, malware, and the possibility of compromised WiFi networks.

During beta testing of IE7 Microsoft tried to block mixed-security content by default, but apparently found that "too many" sites broke, and backed down.

I wish Microsoft had not backed down. The "problem" with secure sites not working "properly" when blocking unsecured content will not disappear, and will have to be handled if/when blocking is reactivated. In my opinion, any such problems with broken sites will be short-lived, and the sites will probably be fixed within weeks of a policy shift.

One might hope that fewer sites are doing using mixed-security content when browsers start to block that type of problem, but I would not hold my breath.

However, I continue to see hotel booking sites, bank sites, and other important sites loading unsecured content as part of their secure pages, and even new sites do it.

In recent weeks I have noticed two high profile sites with such mixing of secure and unsecured content: Twitter and Citibank. In both cases the pages in question included external JavaScripts, which would allow an attacker to completely replace the content of the site, and, for example, to use it to steal passwords.

Twitter (contacted June 3rd) have recently been updating their site, including a secure site interface, but have not yet removed all the references to unsecured content on its main page. According to my information, they are working on it.

In <http://www.citi.com/> Citibank's case (contacted June 17th) there are two problems: Their main landing page is not encrypted, and the "Unknown page" (404) error page (e.g. the page for https://www.citibank.com/foo ) on one of their secure severs includes unsecured scripts, meaning that a MITM attacker can replace their main page (by editing the network traffic, for example in a WiFi-router) and is able to redirect the user to a server where he is (by replacing the unsecured script) in complete control over the content. The only way for a user to discover that he is under attack is to notice that there is no padlock and/or that the URL is not the one Citibank actually use for the service they are supposedly using, even though the URL belongs to Citibank.

I think that this is a big chink in the bank's security armor, but apparently Citibank does not think so, referring to the fact that the vulnerable server is not their main site any more (which does not matter as long as the server is online), that their services are secured with encryption (and that does not matter if the attacker can trick the user into believing they are on the right site) and that they have other security policies in place to help users in case their account is compromised. My impression is that they are not planning to fix the problem.

The problem with mixed-security sites will not disappear while they are allowed to work, so we do not gain anything by waiting, rather the opposite.

While I think blocking unsecured content in secure pages is the best solution, there are others who think that one should warn the user with a dialog, or display the page without any indication that it is partly loaded from a secure server, for example by removing the "https" in the URL displayed in the addressbar, or showing it as crossed out, because we "should allow sites to shoot themselves in the foot if they absolutely want to".

The problem with the warning dialog is that most users will usually just click through it to continue their business. Crossing out https is not much different from what clients do today, by not showing a padlock, and the problem with allowing sites to "shoot themselves in the foot" is that the foot actually belongs to the user.

In my opinion, blocking the mixing of secure and unsecured content is the best option, perhaps with an option for the user to manually trigger loading of the unsecured elements. It may break sites during a transition period, but such sites will be quickly fixed if the issue is critical for the site. The end result will be a more secure web.

In standards work, there is a suggestion being circulated which might help in this area: HTTP Strict Transport Security(a video of a presentation by the author is available here). HSTS is designed to let sites specify HTTPS as the only allowed connection method for their site or domain, amd it contains a suggestion to browser implementations that they block mixed-security content. However. it would only work for sites that ask for such a policy.

This is an area where few browser vendors, if any, can make a move on their own, but by joining forces we might be able to do something about the problem.

I therefore urge Adobe, Google, kHTML, Microsoft, Mozilla, Opera, and Safari, as well as other browser and framework vendors, to discuss a common solution to this issue, and agree on a time-line for when we will ship browsers and frameworks that implement that solution.



Previous articles on this topic:

• Secure sites that aren't
• Low security sites, what to do about them?

There's been a number of criticisms directed at the padlock over the years, some of which may be correct, to some extent, at least.

One objection has been that users misunderstand the padlock's meaning, thinking it is an indicator of trustworthiness, rather than a protection rating for the connection.

Another objection (which flies in the face of the first), is that "nobody checks the padlock".

Well, I can't say much about the correctness of the first objection, but the past couple of weeks a growing number of Opera users have been working hard at debunking the second one.

In Opera 9.50 we added some new security features, and changed a some others. Two of these are the following:

• We now use HTTP GET requests to retrieve OCSP revocation information
• Additionally we download further revocation information, the CRLs (Certificate Revocation Lists), from the issuer and check those.

Both of these turned out to encounter unexpected problems, not due to bugs in our implemenation, but at the CA side. In all cases the problem cause full validation of the certificates to fail, and as a result Opera reduces the security level of the connection so that a padlock will not be displayed. Quite a lot of people noticed.

For OCSP we encountered problems with at least three different brands of OCSP responders. These responders did not respond correctly when we sent a request for infromation about a certificate. It wasn't until a couple of weeks ago that the vendor for one of them discovered the reason for the problem, their expectation of input format was wrong. According to my information they have developed a patch, and I assume they are doing QA on it now, before sending it to the two (or more) CAs that are affected by this. The others have shown up recently and I do not have good information about the causes.

With CRLs we encountered two problems. Just before 9.50 was released we got the first reports about the first case, but it was not until a few days after the release that we got an overview of the situation.

It turns out that one specific CA created an intermediate certificate a few years ago for one of their certificate hierarchies. This certificate included an incorrect URL for where we should go to fetch the CRL, so when Opera fetches the CRL it gets a CRL created for a different hierarchy than the one being verified. As a result Opera's ceritificate validation code can't find the right CRL, and this step fails. This certificate became installed on thousands of servers before the mistake was discovered, and despite a campaign to replace the certificates, several hundred sites (many of them banks) still use the old certificate.

In another case, which came to light last week, another CA have issued an intermediate certificate directly below their root that does not contain a URL for a CRL, but the sub-ordinate certificate issued from that intermediate does specify a CRL. As Opera's certificate validation code expects that if one certificate have a CRL they all use CRLs, validation of the topmost intermediate certificate fails because it can't find the CRL for that certificate.

What can be done about this?

• About the OCSP issue, we wait for the vendor patch, but in Opera 9.51 we have added an override that lets us use the certificate update system to specify which OCSP URLs that must use the old POST method. In addition one CA also deployed a workaround.
• About the first CRL issue, the websites need to update their installed certificates, in the second case the CA must also issue a new updated certificate. While waiting for that, in 9.51 we are adding a similar override mechanism as for OCSP, by specifying extra CRL download locations for specific CAs. In the second case we might also be able to fix the issue if the CA has a root for that particular CA name by distributing it to all installations that access the affected sites (that is not a realistic option for the first case).

These changes will be active in the upcoming Opera 9.51 RC2 (Update: Now available), and is already active in the online certificate repository. You will get the updates the next time Opera checks for updates, or if you use Help->Check for updates.

Update July 9: There are some sites with certificates that does not provide any CRL or OCSP information in the site certificate, while the rest of the certificate in the chain have CRLs. Due to a minor bug, and restrictions in the override functionality, the override for that will not become active before 9.52 has been released. At present we are only aware of 10-20 sites affected by this.