Implementer's notes

The most important security pillar in SSL/TLS is the strength of the method used when agreeing on the encryption keys. If the method used for this is inherently weak, then it doesn't really matter how secure the rest of the encryption we are using really is.

The primary method used for this is the Public Key encryption methods, the most famous of which is RSA. These methods work by breaking the encryption key into two parts; one secret/private key and one public which is known by all (certificates are used to confirm who the public key belongs to). The relationship between these is that a message encrypted by one key can only be decrypted by the other. This means that anything encrypted with the private key can be read by everyone, but one will know that only the secret key could have created the message, and this property is used in digital signatures. Similarly a message encrypted with the public key can only be read using the private key to decrypt, and this is used in SSL/TLS to agree on the encryption keys used for the connection.

The security of this step depends on how difficult it is to break the encryption used to protect the encryption keys. For these methods breaking the private key means you can break all messages protected by it, and that when you have broken the key you can impersonate the owner. The difficulty of breaking an RSA key is generally determined by how long the key is. Given present technology, I estimate that the work doubles for every 25-30 bits that are added to the key length (as opposed to work doubling for every additional bit when attacking keys for a symmetric method, like AES). At present, 640 bit RSA keys have been broken in 5 months using less than 100 workstations, but even the commonly used 1024 bit keys are threatened now and are not recommended for messages that need to be secure past 2010. As a result, Opera will warn (and is the only browser that does) when these keys are shorter than 900 bits.

A way to make exposure of past messages more difficult is to change the key used to protect the messages very often. This means that there are more keys to break if you want access to all messages. With sufficiently strong private keys, massive attack becomes infeasible and even attacking a single key becomes impracticable.

In SSL/TLS these kind of rapidly changing keys are implemented using the Public Key method, also known as the Diffie-Hellman (DH) key agreement. The system most commonly works by having the server send a temporary (ephemeral) DH key (or DHE key) to the client, which then confirms the authenticity of the key by digitally signing it with its RSA key. The client then uses this DHE key to agree with the server on the encryption keys. Given that these keys are changed every few minutes there will be hundreds of keys used by a server every day, making the task of breaking the keys infeasible if the tasks take even a short time. But best of all, even if the RSA key of the site is broken, the attacker won't get the secret parts of the DHE keys. To be able to do this, they would have to break each key.

Given that the RSA and Diffie-Hellman algorithms are based on the same math, they are equally strong for a given key-size. This means that to provide the same level of security for a given connection as the RSA key, the DHE key has to be as long as the RSA keys. This is where an increasing number of secure servers fall short.

Both RSA and DHE secret key operations are very time consuming and therefore reduce the number of connections a server can handle. While most sites are using RSA keys that are sufficiently long, the fact that there are lots of DHE keys have led some vendors to mistakenly think that they can reduce the length of the DH keys so that more transactions can be performed. Most of these reduced keys are either 512 bits or 768 bits long (which Opera warns about), but I have actually seen servers sending 256(!) bit DHE keys (Hint: I estimate that these can be broken in minutes or hours).

What these vendors seem to forget is that not all attackers are interested in every transaction performed at a site. An attacker might just be interested in one individual visiting the site, and in such cases the size of the DHE key becomes significant. If the key is too short it may become economically feasible for the attacker to break the DHE key. This is why Opera also warns about weak DHE keys, which are shorter than 900 bits.

As reports about weak DHE keys seem to increase, I found it necessary to take a few steps to counter this problem.

The first step was to ask the TLS Work Group to specify clearer how these keys are created. In addition, specify what steps a client should take to ensure the DHE keys are adequately secure. This is currently being worked on for TLS 1.2.

The second step was to evaluate the size of the DHE key when we receive it. If the key is shorter than 1024 bits, we close down the connection after sending an Insufficient Security (71) fatal error to the server, and automatically try to establish a new connection where the DHE methods are listed as less preferred than they normally are. By doing this we will most likely be able to establish a sufficiently secure connection using the RSA-only methods instead. If the server still selects a DHE method, then a warning may be displayed if necessary. This extra round trip will usually not take extra time because it will be handled as part of our usual TLS feature testing of the server (watch this space for news about that). A known issue we are working to fix is that for mail servers where this dialog have been shown previously, this will not take effect until the second time you check email, and that the first attempt will fail.

The end result is that (normally) you will no longer see the weak public key warning, except if the site is using a weak key in the certificate. We can't do anything about the certificate keys because the size of that key is selected directly by the Webmaster. If you get any of those warnings, please notify the webmaster!

Further reading about crypto on Wikipedia:

Public Key Cryptography
RSA
Diffie-Hellman (DH)
SSL and TLS
About Keysizes

As I've written earlier, in Opera 9.0 we disabled SSL v2 by default, but if necessary a user could enable it.

In Opera 9.5 (Kestrel) we've taken this one step further, and completly disabled the support for SSL v2. That is, as of Opera 9.5 Opera is no longer able to connect to servers that only supports SSL v2.

There are several reasons for this:

• SSL v2 is OLD. It was added in Netscape 2, back in 1994! SSL v3 replaced it 1996, which means that any service that only wants to use SSLv2 was designed in 1996, or earlier. And it hasn't received a significant upgrade since! Think about what that means about the technology used, and the security of the site...
  
  
• SSL v2 is binary incompatible with SSL v3 and TLS; you cannot send a modern TLS handshake to a SSL v2-only server, it won't understand it. In fact, one of the very few things SSL v2 and SSL v3 have in common is the name! Given new TLS functionality Opera 9.x had already put SSL v2 as the last thing it will try before giving up.
  
  
• SSL v2 itself is known to have at least one major security vulnerability. This particular vulnerability is not present in SSL v3
  
  
• There are few, if any, publicly accessible SSL v2 servers left. A major reason for this is Gerv from Mozilla's campaign two years ago; he managed to convince the hosting company with almost 90% of the servers to upgrade. According to my information Netcraft stopped counting them last year, because there were so few left.
  
  If you do encounter a "secure" site that requires SSL v2, what can you do? Well, I don't recommend it, but you can go back to Opera 9.2x and enable SSL v2. But before you do, perhaps you should ask the system administrator this question: "Why are you running the site with 12 year old software?"
  

Earlier this week news arrived about the successful factoring of a 1020 bit (307 digit) number using just 11 months and about 100 computers to perform the necessary calculations.

The number that was factored is a specially structured number, meaning that it was much easier to factor than a general number of the same size. The largest general factorings accomplished so far are 640 and 663 bits. Both were announced last year.

This is important because the difficulty of factoring a large number determines the security of the RSA encryption method, one of the primary supporting pillars of SSL/TLS, as well as PGP and S/MIME, as they are used today. If the RSA key used by a site is broken, an attacker can not just read all communcation with the site protected by that key, he can also impersonate the site from then on, and he would be able to read all communication with the site that was ever protected by that key, assuming he had archived them.

At present there is no immediate danger that an attacker can break a 1024 bit key, the keylength used by most website certificates (and also CAs) at present. However, like what has been happening to SHA-1 which is another cornerstone of SSL/TLS, this is a warning shot across the bow of the world's 1024 bit RSA keys. Within a few years (it could be 3-4 years, or it could be 10 or more) it is quite likely that the methods used will dramatically reduce the security of 1024 bit RSA keys.

There is currently no indication that RSA itself is broken, but as computation power increases and factorization methods improve this will change the properties of which RSA keys can be considered secure. 10 years ago 768 bits were considered reasonably secure, that limit was later raised to 1024 bits, now it is time to raise the limit even further.

Effects for Opera

I have already taken steps to increase the default length of client certificate keys generated by Opera to 1536 bits.

We are also considering changing the default value of opera:config#SecurityPrefs|MinimumSecurityLevel from "0" to "1". This would raise the lower limit of what is Level 3 (L3) security for RSA from 1000 bits to at least 1020 bits (For settings "0"-"3" Level 1 security is everything below 900 bits).

The consequence of such a change is that sites using certificates issued by at least one root (that was issued with a 1000 bit key) would lose the padlock, as they would be classified as having Level 2 security. We haven't made a decision on this yet, because we first need to find out how problematic the change would be.

Within a few years, probably between 2009 and 2012 (depending on what happens on the factorization front), it is likely that this preference will be raised to "2" (L3 = 1100 bits) or "3" (L3 = 1200 bits).

And before somebody asks: Yes, I am investigating Elliptic Curve Cryptography (ECC). But before it can be implemented and released in a public version, there are still several legal requirements that have to be met.

Last week I also suggested to the W3C's Web Security Context (WSC) group that browsers should not consider a connection secure (and show a padlock) unless the encryption keys used to protect the communication was 2³² (4 billion) times more difficult to break than what can reasonably be broken in one year using currently known methods and technology. The other members of WSC has not yet considered my suggestions.

Such a rule will ensure that, short of revolutionary leaps in technology and/or methods (such as a complete solution of the factoring problem), not even enormous amounts of money can compromise the keys by brute-force computation (if somebody is that interested in some piece of informaiton there are other, less expensive, ways to get hold of the key, such as "buying" it, although that would reveal the interest).

Given the current state of the art, this proposed rule puts 1024 bit RSA in the unsafe zone.

General effects

My recommendation to the world's RSA users would be to use longer keys, at least 1536 bits ( only if performance is an issue), but preferably 2048 bits, and get their certificates issued from Certificate Authorities (CAs) using keys that are at least 2048 bit long (ask the CA if you are not sure).

Thanks to Bruce Schneier for the first post. Bruce also says: "I hope[d] RSA applications would have moved away from 1024-bit security years ago, but for those who haven't yet: wake up."

Thanks also to Eric Rescorla.

See also http://en.wikipedia.org/wiki/RSA_Factoring_Challenge for more on factoring big numbers

I've recently posted^1,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.

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.