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?

It shouldn't come as a surprise to anyone who is familiar with my opinions on encryption strength that I do not hold 512 bit RSA encryption keys in high regard. To put it mildly.

Unfortunately, I continue to be disappointed by the many sites using such weak keys. But I am even more disappointed by the fact that it turns out there are banks that are still using these keys.

Recently I have become aware of two banks/financial services that are using such weak keys:

• The Israeli Bank Hapoalim's US branch (International site)
• Halifax UK's branded credit card site (e.g. used by Amazon UK MasterCard)

Both of these sites are, as of June 15th, 2007, still using 512 bit RSA keys, and have been doing so for about a year, at least.

I have tried to contact these banks yesterday evening and today, but have so far gotten no response (and I also had trouble submitting the comments to the Israeli bank), and to Amazon UK, who answered quickly that they would forward the information internally.

The problem with 512 bit RSA keys is that an attacker, using (almost literally) a handful of computers, can break them in a couple of weeks, at most.

And when an RSA key is broken the attacker can do a lot of things:

• He can read all previous traffic with the site if he have recorded it (if the site uses Ephemeral Diffie-Hellman keys, then those keys must be broken instead).
• If he is able to intercept current traffic to the site, he can pretend to be the site and read all the data passing back and forth between the site and the users.
• If he is able to pretend to be the site, he can also change the information on the fly, if he wants too.

There is absolutely no way to detect any of these attacks through the SSL/TLS protocol, because the sanctity of the site's secret private key is the fundamental pillar of the protocol. That key is used to agree upon the encryption keys that are used to protect the rest of the
communication.

10 years ago, 512 bit RSA was the highest level of encryption the US government permitted foreign users of US manufactured servers and browsers to use, except for financial services, who could use 1024 bit RSA keys, or better. It was widely assumed that the reason for this limit was that the US government could break 512 bit RSA keys relatively fast. The restriction was lifted in 1999/2000.

The proficiency of RSA key breaking is, as I mentioned a couple of weeks ago, rapidly increasing. At present general 640 bit RSA keys can be broken in 5 months using just 100 computers. But recently a special 1020 bit number was factored (the difficulty of factoring large numbers is what provides RSA with its security) in about 11 months using the same amount of computing power. That means that 1024 bit RSA keys are fast approaching their "consume by" date, if it hasn't already been passed.

Today, I would strongly recommend that secure websites, in particular financial sites, should use 2048 bit RSA keys.

The days of 1024 bit RSA keys are numbered: 1296 days, at most. (See the countdown for the up to date number, on the frontpage).



Update, June 18: Halifax has responded that they are in the process of upgrading the server certificate.