In Opera 9 Beta there are a lot of changes, as one expects from a major product release. Some of the changes (e.g. UI updates) are more apparent than other changes. Some of the major, but less obvious, changes have been done in Opera's SSL/TLS engine.

The SSL/TLS engine is Opera's implemention of the Secure Sockets Layer (SSL) protocol and its successor the Transport Layer Security (TLS) protocol. These protocols encrypt the connection between Opera and secure HTTP (HTTPS) servers, or secure mail and news servers.

When we designed Opera 9, we enhanced four major areas of our SSL/TLS
engine:

1. New SSL/TLS implementation

We rewrote the code for the entire protocol implementation almost entirely from scratch. The old code, while quite functional from a practical standpoint, had become difficult to maintain and expand, and some parts overlapped functionality in other areas. The time had come to improve the structure of the engine significantly, and the best way was to do it was to rebuild the basic functionality from the bottom up.

The new engine, while functionally equal to the old one, is now much more flexible, making it easier to add new protocol functionality as it becomes necessary.

2. TLS 1.1 and TLS Extensions are now enabled by default.

When we tested these features in Opera 7.60 TP in September 2004, our users found 100+ sites that would not work with either or both of these features. So why enable these features now, have we lost our minds?

The reason isn't that the problematic sites have disappeared. Unfortunately, they haven't. The reason we are activating these features now is that we have worked around the problems. When connecting to an unknown server Opera now performs several tests of the server's capabilities, finding out if the server tolerates TLS Extensions and/or TLS 1.1 clients, before establishing its connection with the server using the best possible combination of features.

The drawback of this method is that it requires Opera to establish several encrypted connections to the server, or at least start the process of establishing them, before setting up the actual connection to be used. This takes time, usually several seconds, but by doing this we are able to use the most secure set of protocol features possible. The alternative would be to settle for lowest common denominator.

Implementing the standards improperly is, unfortunately, not surprising or new:

• SSL v3 is binary incompatible with SSL v2, and using SSL v3 or TLS to a server that only understands SSL v2 will actually cause an apparent hang on the connection because the server expects more data to arrive.
• Many SSL v3 servers were hardcoded to not accept newer versions of the protocol, despite that being a requirement of the specification.
• A number of other SSL v3 servers accepted connections from TLS 1.0 clients the way they should, but during a vital part of the handshake they used the wrong value when checking the data it received from the client. This broke the very method in the RSA Client Key Exchange that was supposed to prevent an attacker from tricking the client and server into selecting a (possibly) weaker protocol. To be able to establish a connection at all, it became necessary to fall back to the older version. Ooops!

3. We have disabled SSL v2 and the 40 and 56 bit encryption methods supported by SSL and TLS.

SSL v2, originally developed by Netscape, is more than 11 years old. It was replaced by SSL v3 (also developed by Netscape) in 1996. SSL v2 is known to have at least one major weakness. And considering the age of the servers that only supports SSL v2, one can certainly wonder how secure the servers themselves are.

Some may wonder why disabling an outdated protocol is news. Shouldn't these "features" have been removed long ago?

The fact is, as we found out when we tried to disable these methods during the 7.60 TP and 8.0 Beta testing, that despite both the new versions of the protocol and the protocol's security problems, there were actually major sites using it as their single available SSL version as recently as a year ago! It is actually only a few years since a major US financial institution upgraded their servers from SSL v2 to TLS 1.0. This meant that it was not practical from a usability perspective to disable the protocol.

Last year, however, things started happening, the major websites that only used SSL v2 (finally) upgraded, that single ISP that hosted most of the SSL v2-only servers also upgraded (encouraged by Gervase Markham^{1, 2} of the Mozilla Foundation), and the major web browser vendors indicated ^{3, 4} their intention to discontinue support for SSL v2. KDE 4 and IE7 for Vista ^5,6 has already disabled by default these methods, and Mozilla ⁷ is about to do this as well.

The 40 and 56 bit encryption methods are also outdated, their keys can all be cracked in hours, if not less. They can therefore no longer be considered secure.

Encryption is often compared to an envelope that will prevent people handling it from reading the content inside the envelope (without actually opening it, which would be a crime, unless authorized by law). In this context 40 and 56 bit encryption can be considered a half-transparent envelope where, by just fiddling with and shaking the envelope a little, you are able to read what is inside the envelope, even though you cannot by simply glancing at it.

To be secure today you need to use at least 128 bit encryption, and Opera supports up to 256 bit encryption today.

If you find that you actually need to use either SSL v2 or the 40 and 56 bit encryption you can enable them in the security preferences. However, even if you do, you will have to accept a warning the first time you connect to such servers. You should anyway, in such cases, send an email to the webmaster and ask him/her to update the server.

4. The grey Security Toolbar

If there was any problem with the SSL/TLS connection that reduced the security level of the connection below level 3, the color of the security toolbar will not be yellow, but grey. The problems that can give these results are low encryption level, unknown certificate authorities, mismatch with the servername in the certificate, all of which results in a warning dialog, or a failed online check of the server's certificate.

This change is intended to give you a clearer indication than just the level 1 and level 2 padlocks that not everything is OK with the site or the surrounding systems.

(This article is also posted on Opera Labs)