A number of the reports I see reported in our bug reporting system or in various forums concern secure sites that does not get a secure ranking by the security toolbar, produces warnings, or where Opera does not manage to negotiate a connection. Now and then I also come across such sites myself.

Some of these cases, in particular when we do not manage to negotiate a connection, can be caused by bugs in Opera, either due to problems with the new SSL stack, or our attempts to handle non-compliant TLS servers, but in many cases it is the configuration of the secure site that is causing the problem.

In this article I'll cover some of the cases I've seen. I will include real-life examples of sites for each category. I have tried to contact these sites, with varying degrees of success, and they may have changed by the time you read this.

As mentioned the problems observed fall into several categories:

1. Mixing secure and unsecured content
2. Weak keys in the site's certificate
3. Sites using 40 and 56 bit encryption
4. Sites pretending to be secure

Mixing secure and unsecured content.

Now and then we get a report about a secure site where the padlock in the security toolbar is open, with the comment that is should be closed and display level 3.

The reason for the open padlock is that the site mixed secure and unsecured content in some fashion (earlier this included redirects from an unsecure site).

Using unsecured content in a secure page casts doubt on the security of the entire site, because it makes it difficult to determine if the unsecured parts actually contain sensitive data. The unsecured data may, even indirectly, reveal information about what you are doing.

In Opera this kind of mixing reduces the security level to zero (0) and a grey security toolbar when the main document is "secure", but I am considering to do what Microsoft implemented in IE7: Don't load unsecured content into a secure document, unless told by the user. IE6 and earlier do give a warning when such mixing is encountered, but it can be disabled.

One such site that recently came to my attention is the online reservation system of Hotel "Alfa" in Las Vegas, where a Flash applet, located on a secure page, retrieves unsecured content which it uses in its presentations to the user. Alfa was informed almost two weeks ago, responded quickly that they were looking into it, but has not yet fixed the problem. But more about "Alfa" below.

I'm aware of a major e-booking site ("Epsilon"), they also host a number of outsourced e-booking sites for travel agencies. This site performs the entire ordering process, including using a credit card number either as identification or payment in a secure frame inside an unsecured frameset. It was not immediately obvious that the site used frames, which initially made me believe the entire process was performed over unsecured connections. It is not possible to tell without investigating the source code and URLs of the frameset.

Weak keys in the site's certificate

When Opera accesses a secure site that is using a site key shorter than 900 bits long (either in the RSA, Diffie-Hellman or DSA methods) Opera will display a warning about the key (Outdated encryption/short public key).

Please note: The encryption methods discussed in this section (public key encryption) need much longer keys (>500 bits RSA/DH/DSA) than the methods implied by the term "128-bit encryption" (symmetric encryption), and that comparing bit-lengths between them as indicators of security are like comparing apples and oranges. For reference though: The strength of 1024 bit RSA encryption keys, the minimum size recommended for protecting information that can be revealed after 2010, is considered equivalent to an 80-bit symmetric encryption key.

We display the above mentioned warning because such keys are no longer considered secure, in particular keys shorter than 800 bits, since a 640 bit RSA key can be broken in 5 months using just 100 computers. Even a 512-bit key (which is by far the most common key size we encounter in this category) can be broken in a couple of weeks using just a handful of PCs.

When a RSA (or a DH or DSA) key is broken, not only does all traffic to and from the server become like an open book to the attacker, they can also change the content of the traffic, and there is no way to tell. These keys are one of the fundamental security pillars of SSL and TLS, and they are used to protect all the encryption keys used between server and client.

I have discussed the problem about these keys with several Certificate Authorities over the past year or so. The feedback I've received is that they have implemented, or are working on, systems that will automatically give warnings about and discourage such keys, but have not yet taken the step of forbidding them.

Curiously, some sites still create such keys, and ignore the warnings from the CAs. The most recent 512-bit certificates that I am aware of were issued within the past week!

Some of the sites I have observed with this kind of key are:

• Hotel "Beta", another Las Vegas Hotel. They have been using this key for two years, and it will expire in a few weeks. I informed them the first time about the problem over a year ago, then twice more some months later, but never got a reply.
• A major UK ISP. Their primary web server is using a 512 bit RSA key, issued last December (2005). I became aware of this site a few days ago, and I've tried to inform them via one of their question forms and an email direct to one of their press contacts, but the last I heard about that email was that it was still trying to find the mail server for the domain.
• Hotel "Gamma", yet another Las Vegas hotel. The online reservation site at their website is using a 512-bit RSA key that was issued just a few days ago. I have no idea why they think they need a 512-bit key (they never responded to the emails I sent last week), after all, every CA certificate is using keys at least 1000 bits long, and even the SSL/TLS export encryption methods used by very old (pre-2000) US produced browsers, e.g. Netscape and IE allowed the certificates to have 1024 bit keys, as long as a temporary 512 bit RSA key was used during negotiation of the connection.

  There are/were more problems with "Gamma" that will be discussed later in this article.

40/56 bit symmetric encryption

In versions before Opera 9 we have classified these weak encryption methods as level 1, and we still do, because it is not possible to adequately protect information encrypted with these methods.

40-bit encryption methods was, before 1999, the strongest keylength permitted in encryption software that was exported from the USA, except to Canada and when the website was a financial website. Unless I am mistaken, these keys can be broken in, at most, seconds by the proper hardware, and therefore they do not provide any security at all.

56-bit encryption method were considered strong for a while, but in the 90's these methods started to become weaker as well, and in 1999 this level of encryption was broken in 24 hours (to a price of about USD 50 000, plus USD 200 000 to design the system), and today I expect that to be less than an hour. They therefore do not provide any real security, either.

In Year 2000 the US government lifted the export restrictions, and with an easy-to-get licencse it is now possible to export any encryption.

Due to this increased weakness in the methods Opera 9.0 disabled them by default (you can enable them, but we still display the warning message). Opera is not the only client to disable these methods: IE7+ for Vista will also disable these methods by default, and the Mozilla team is also looking at disabling them.

The problem with these kinds of sites in Opera 9.0 is that we are not able to tell exactly why we could not connect to the server, not without actually testing the ciphers we have disabled (and the server might require a cipher not known to Opera). This means that we can only tell the user that we were not able to establish contact, and that the reason my be disabled encryption methods-

Unfortunately there are still sites that are, for some reason, using these outdated methods, such as:

• The webmail of a major Canadian ISP. I find it odd that they are using a 40-bit only server; after all, being Canadian they were never prohibited from importing a US (or internationally) produced 128-bit secure webserver. They have reported back to me that they are working on replacing the server, but were unable to give any date.
• The online account manager service of a major UK Mobile telecom is using 56 bit encryption. I have not received any response to my email informing them about the problem.

Sites pretending to be secure

There are some sites that are handling sensitive data, such as credit card numbers and login forms, that are not using secure connections for part of the process, or aren't using it for the entire process.

These kind of sites do not normally trigger any warnings, because sites without encryption are the normal type of site, and it is very hard, if not impossible, for the browser to tell which data are sensitive and which are not. The only way to detect such sites is for the user to look for the padlock or yellow security toolbar or similar security indicators, before entering sensitive data into webforms. There is no way for a browser to detect most of these problems.

One category of sites put the login field on an unsecured server, e.g. the front page (very popular with some banks), and claims that this is secure because the credentials are sent securely to the server, ignoring the fact that the unsecured form could be modified by anyone with the ability to listen in on your network connection, or that it is no easy way to detect the tampering.

The second category are sites that perform all the sensitive operations over an unsecured connection, including credit card transactions.

A special sub-category are those that put keys, padlocks or other "this is secure"-images on their unsecured page.

A couple of sites in the second category recently came to my attention:

• Hotel "Gamma", which was mentioned above. Besides originally (last week) having several links to a completely unsecured reservation and payment page, this site sported a couple of "This site is secure" logos from a well known CA. The "interesting" thing about this is that the certificate referenced by the logo was issued to another server than the reservation page is hosted on, and the 512-bit RSA certificate for the secure version of that site was not issued by that particular CA. In plain words: They were pretending to be secure. They have since gotten a new certificate for that site from the original CA so the logos are now correct, but as mentioned above they are still using a 512-bit key in the certificate.

  I sent an email to the info address at the design company for this site last week (using an email address link on the design company homepage). That email bounced!

  However, it looks like somebody did get the email that was CCed to postmaster, because after a few hours sombody had fixed the *precise* URL I had mentioned in my email so that it redirected to the secure server, and another problem was also fixed. Several days later they also fixed the other unsecured methods available to enter the reservation system (e.g., when you do not have Flash 8 installed).

• Hotel "Alfa", which was also mentioned above. Beside the mixing of secure and unsecured content I also discovered that they send all the booking information, including the credit card information, over an unsecured connection, from a Flash applet located on a secure(!) page!

  This is by far the worst case I have seen in a long time, and I am not sure if "Alfa" or the "Zeta" e-booking site (which is hosting the reservation system) is to blame, but I'd say both are equeally responsible; "Alfa" for not configuring and checking the security of their system properly, the e-booking site for making it possible by having a unsecured mirror of their booking system (I discovered that there are at least two other hotels using this e-booking site that used the unsecured version for part of their booking service).

Summary

Security is not easy, there is both the external and the internal web site security to get right. The webclient cannot detect anything about the internal security (such as protecting the server itself), but the browser can give an indication about the visible external security, such as how strong encryption is used.

Beside making sure that the scripts and databases on the server are secure, a website administrator should make sure he has followed the best practices for configuring a secure site, which include at least the following:

• It should support at least 128 or 256-bit encryption for TLS 1.0.
• The certificate for the server should have a key that is at least 1024 bits long.
• All pages dealing with sensitive (e.g. credit card number or login info) or potentially sensitive data (e.g. booking information) should be on the secure server.
• Frames should be avoided, but when used, all of the frames, not just some, MUST be from secure servers.
• In my opinion it should also be possible for the users to discover where their information is sent before they hit the submit button.
• It should be easy to report problems with the site.

As a user you can protect yourself by looking for the following when entering a page that asks for sensitive data by:

• Looking for the yellow security toolbar and the padlock
• In pages with a collapsed addressbar, the bar with the hostname will turn yellow for secure pages.
• Making sure that you did not get any certificate warnings when entering the site.

If you cannot see a secure site indication (yellow) you are not on a secure page, and should at least ask the website manager to provide one.

Remember: Even if we browser vendors and the websites have done our best to make your surfing secure, at the end of the day it is you, the user, who have the ultimate responsibility to make sure you, your money, and your identity information are safe.

Updates:

02/08 19.00 : Hotel "Gamma" has now upgraded the key of their certificate, quite a bit actually.

26/08 : A few days ago Hotel "Alpha" at least fixed the mixed security loading. I have not yet tested if the booking data are sent securely.