A month ago I wrote about "Secure sites that aren't", and it is time to take a look at what happened, and what didn't.

Sites fixed by their owner:

Hotel "Gamma" relatively quickly fixed the problems with the unsecure parts of their reservation site, the incorrect "secure site" logos, and then upgraded their certificate from using a 512 bit RSA key to a 2048 bit key. I approve of the result, although throughout the entire process it felt like the Certificate Authority involved (who may have contributed the most) and I had to point out every problematic detail to the webmaster before it got fixed.

Hotel "Alpha" took much longer, more than 5 weeks (from when they were first informed about the initial problem), to fix their problems with mixed security and unsecure credit card transactions.

Again, I approve of the result, but as much as the delay in fixing the problems is troubling, just as troubling is the fact that while their emails seemed to claim they were taking the problem seriously, I got the distinct impression that they did not comprehend how seriously they had broken their implied security promises to their customers.

In my opinion Hotel "Alpha" should have fixed the problem by the end of the week I informed them about the problem, and when they learned of the unencrypted booking information they should have taken the system offline until they had fixed it. This may seem extreme, but by not doing so, they were exposing their customers' information to the risk of interception by anyone listening in to the communication with the site.

Sites not fixed:

As before, I never got a reaction from Hotel "Beta", and they have not yet fixed their 512-bit RSA key. It's going to be interesting to see what happens when the certificate expires later this week (Sunday evening).

The UK ISP still haven't fixed their 512-bit RSA certificate either, but at least they have told me they are "working on improving the encryption" at the site.

The UK mobile telecom company also haven't fixed their 56 bit-only encryption site, but they have responded that they are investigating.

The "Epsilon" travel agency is still not putting the creditcard transaction page in a secure frame, but referencing it from an unsecure frame. Based on the response it looks like they are concerned about the cost of maintaining a server for each secure website they think they would need to set up if they want to use secure frames. What they could do is to move the transaction to a frameset on their transaction server, but the drawback is that the travel agencies would no longer get their URL displayed in the addressbar. In my opinion the travel agencies should either pay the cost of getting the secure server for each domain, or accept that the customer won't see their URL for the entire transaction.

Based on the impressions I got (assuming they are correct), it looks like the Canadian ISP with the 40 bit encrypted webmail have a serious knowledge gap in their webmaster team.

If the statements I got from their customer support truly represent the beliefs of their webmasters, there are glaring holes in their knowledge about the capabilities of the SSL/TLS protocol and the implementations using the protocol.

The last email I got from this ISP said:

At this time we still do not have an exact ETA for when this upgrade will be available as some places in Europe are not yet supporting higher than this for encryption. We have to ensure that customers, wherever they are in the world are able to access their email.

Assuming this is correct (and they have not protested, nor answered, my two emails presenting my interpretation of the above quote), and that this statement was not the result of an internal misunderstanding, I can only draw the conclusion that they think that 128-bit SSL/TLS servers are unable to communicate with clients that only support 40-bit encryption. That is almost as far from the reality of this aspect of SSL/TLS capabilities as it is possible to get.

First, I am not aware of any European country that has had any massmarket encryption restrictions in force since France dropped their 40-bit-maximum policy in early 1999. The US basically dropped their export restrictions for massmarket encryption in 2000.

Second, As far as I know all servers capable of supporting 128-bit encryption also support both 40 and 56 bit encryption plus several other methods, it is just a question of whether or not the server is configured to accept them. Even when a server is not configured to accept a weak method it will usually present a page (over the weak connection, and this is one kind of "upgrade your browser"-page I can approve of) to the user explaning that his browser must be upgraded, a method that is mostly used by banks.

And to top it off: All, or almost all, of the old 40 bit-only US-"exportable" versions of MSIE and Netscape, and this also applies to "exportable" SSL servers, are able to use 128 bit encryption when the server presents a certificate containing a special extension that those clients and servers are hardcoded to recognize. These certificates were originally only issued by Verisign to US and non-US financial websites, since the US allowed even foreign banks to use strong encryption for online banking. As far as I know these certificates are now available to any website since the export restrictions are no longer in force.

In other words: Unless the ISP make an active choice, they will not maroon any of their customers that might have only weak encryption available. Or to put it a bit more pointedly: If they applied the same logic to their broadband service they would not be able to offer it to anyone because not every potential customer would be able to buy it because only dialup is available where they live.

Also, any server that only supports 40 and 56 bit encryption must, by definition, be at least 6 years old, possibly more, which most likely mean that the servers have not had any security patches for many years. Even if these servers are behind firewalls, my guess is that they're not able to withstand attacks for very long.

In my opinion the only valid excuse for delaying a system upgrade for all of the 40/56 bit encryption sites is the time needed to test the new system. But they have had years to prepare this migration, and in just a few short weeks (at most) lots of early adopters of IE7 on Vista are going to start complaining, and the Firefox users won't be far behind.

Webmasters: I suggest you expedite that testing.

Update Sep. 9: Hotel "Beta" has moved to a new server with a 1024 bit RSA key :up: .