Security @ Opera

Early November 2009 the IETF Transport Layer Security Working Group (TLS WG) learned of a serious security vulnerability in the SSL/TLS protocol, the "Renego" problem.

Both TLS servers and clients have the ability to initiate a refresh or complete renegotiation of the encryption parameters used in a TLS connection. This can be used to make encryption keys even less predictable, thus providing less data an attacker can analyze, or as it is frequently used, to ask the users to identify themselves with a client certificate over an already secured connection, thus protecting their personal information better.

What Marsh Ray discovered in September, and started working with others to fix, and Rex Martin independently discovered about two months later, was that an attacker could use this renegotiation feature to (for example) insert a partial HTTP request to the HTTP server over a connection the attacker established, then start to forward the TLS handshake from the client to the server (over the already established secure connection) and let them establish their own secure connection. The problem is that the server would then combine the attacker's partial request with the client's request into a single request controlled by the attacker, and execute the resulting request, e.g. transfer USD 100 000 to another account, but as if the user had approved it. Other variations exists, some involving attacks on the client instead of the server.

The main cause of the problem is that the server thinks the client renegotiated the connection, as far as the client is concerned it just established the connection, and neither side can tell what the other believed was the state of the connection. Another cause of the problem is that many applications, including HTTPS, are not aware of the renegotiation, and does not have procedures to separated data frome before and after the renegotiation.

It must be emphasized that this is not a application vulnerability, it is a protocol vulnerability, as far as I know the worst ever to hit the SSL v3 and TLS protocol ever, and it required that all the SSL and TLS protocol specifications be updated.

This is also a security problem that cannot be fixed by just fixing the client (e.g. Opera), or by just fixing the bank's server. To be secured against this problem both sides, the client and the server must not just be upgraded with the fix, they must be able to tell that the other side of the transaction also support the fix.

After almost two months of extensive discussions in the TLS WG, the rough consensus of the group settled on the following update of all TLS versions (and SSL v3, but they have no authority over that protocol version):

• A new TLS Hello Extension, RenegotiationInfo (RI), is added and used to exchange information between the client and the server about the last TLS handshake done on the currently active connection, which they use to confirm that they are in agreement about the state of the connection they are renegotiating. In the first negotiation of the connection the RI extension contain no data, it is empty. This exchange of information in combination with how TLS secures its hasnshake negotiation, cryptographically binds the current encrypted state of the connection with the next state of the connection, preventing a man in the middle attack.
• As some servers does not properly support TLS Extensions, particularly SSL v3 servers, a special Signaling Cipher Suite Value (SCSV) can be sent by the client to the server to indicate that it supports the RenegotiationInfo extension. A patched server must then respond as if the client sent an empty RI extension, and return an empty RI extension, or abort the connection if it sees that the connection is being renegotiated while the client thinks it is establishing a connection.

In today's 10.50 snapshot release we are starting public testing of our implementation of the "Renego" fix.

At the moment you will not (or should not) notice any differences from the previous versions of Opera that does not have this fix. Part of the reason for releasing this snapshot is to discover if there are problems our testing have not uncovered. Another part of the reason is to allow TLS server vendors to perform interoperability tests of their servers against our client, to discover if there are problems in theirs or our understanding of the revised specification.

As currently implemented Opera's Renego fix have the following features:

• The update affects HTTPS, NNTP/POP/IMAP/SMTP/IRC over TLS
• We will send the RI extension in all handshakes using TLS Extensions
• We will send the SCSV when we don't know whether or not the server tolerates TLS Extensions (patched server MUST tolerate extensions, a reminder is included in the renego specification)
• If we know the server supports the RI extension we will always indicate support for TLS 1.2 and use extensions. If the patched server is incorrectly implemented the connection will fail (the renego specification reminds server vendors about the version tolerance requirement that have existed since SSL v3) and Opera WILL NOT attempt to use an older version in the handshake, as that would expose the user to a different, and currently hypothetical, security vulnerability, the version downgrade attack.
• It is a fatal error for a server (identified by name and port) to indicate RI extension support, and later not use it. We have to assume somebody is attempting to attack the connection.
• There is currently no indication in the UI when a server is vulnerable, but later there will be an indication in the security information dialog about unpatched servers. Currently the unpatched status is only indicated by the XML tag "<RenegExtensionUnsupported/>" in the security information document that you can find in the Info panel for the current document; the link to the document is the TLS Protocol field of the panel information.
• There is an auto-updatable preference, opera:config#SecurityPrefs|CryptoMethodOverrides , that can be used to enable warnings about unpatched servers, or disable support for them.
• In the warn mode renegotiation is disabled against unpatched servers. Servers that rely on renegotiation should be among the first to patch this issue.

The reason we are currently allowing connections without warning to unpatched servers is that there are too many unpatched servers, essentially all of the ones currently on the net are unpatched. Displaying warnings at this time would be problematic from a user experience point of view.

At a later date, not yet decided, when a large proportion of servers have been updated, we will auto-update the above preference and start warning about unpatched servers.

Some, as yet unspecified, time after we have started to warn about unpatched server we will again auto-update the preference and disable support of unpatched servers. This eventual step is necessary in order to properly secure our users. As long as we allow connections to unpatched servers users are vulnerable to this attack, and if the vulnerable servers are not phased out as soon as possible (which in my personal opinion is at most 12 months) we will have this problem for years to come.

Concerning our new policy of always identifying TLS 1.2 as our highest supported version: Previously Opera have spent time probing each secure server to determine which TLS version it could signal to the server, and whether TLS Extensions could be used with the server. Other clients have similar procedures. The reasons for this procedure is that many servers, about 6% according to my recent tests, does not handle these features well, even though the standards require them to. Clients have therefore had to adjust to these non-compliant servers. But this kind of adjustments make the clients and servers vulnerable to a version downgrade attack, which might become feasible at a later date if a problem is found in one of the older SSL/TLS versions.

In the specification of the RenegotiationInfo Extension there is a reminder to server vendors about how they should handle clients supporting newer versions than the server, and TLS Extensions: They have to tolerate both. In this update, since all secure servers have to be updated to fix the renego issue, we are starting to enforce the version requirement of the SSL/TLS specification by always offering TLS 1.2 to renego patched servers, and expecting them to handle it. The servers does not need to support TLS 1.2 (though that would be preferable), it only have to tolerate clients that does. The Extension tolerance requirement is implied by the renego specification. The result of this policy change is that a second possible vulnerability is removed.

Testserver: https://www.mikestoolbox.net/ which is the same as was used with the TLS 1.2 testing

The CryptoMethodOverrides preference

The CryptoMethodOverrides preference (opera:config#SecurityPrefs|CryptoMethodOverrides ) mentioned above is a new preference we introduced in Opera 10 to allow us to auto-update Opera installations to warn about, or disable, security protocol features when they become critically weak. The preference is a decimal integer consisting of bitwise flags values ORed together.

Currently this preference have the following values (written in hexadecimal notation, the decimal version must be used in the preference) defined since 10.0:

• 0x01/0x02: Warn about/Disable MD5 signed certificates
• 0x04/0x08: Warn about/Disable SHA-1 signed certificates
• 0x10/0x20: Warn about/Disable SSL v3 support

The MD5 and SHA-1 methods are weakening rapidly, though they are not yet broken, and we will likely need to disable support for MD5 in certificates within a couple of years, at most; we completely disabled support for the much weaker MD2 method in Opera 10.00. I expect SHA-1 to hold out for a few more years, but CAs are already preparing a migration to the stronger SHA-256 algorithm.

As SSL v3 is using MD5 and SHA-1 directly, without the extra computational steps used by TLS 1.0 and TLS 1.1, it is likely that once SHA-1 becomes too weak, we should disable that version of the protocol, too.

We expect that there will be time for a period of warnings displayed about these problems before they are completely disabled.

In today's build the following flags are added:

• 0x80: Disable EV indication for unpatched servers with EV certificates. We have not yet decided whether or not to flip this switch, or just use the warning flag. The renego issue is particularly severe for EV sites since the certificates are identifying the party you are talking to, and with the Renogo vulnerability you don't really know who you are talking to throughout the connection, or who the server talked to before it talked to you. Operators of EV sites should upgrade as soon as patched servers become available.
• 0x0100: Warn about servers not having fixed the Renego issue. This triggers a certificate warning dialog, and you can configure an exception policy for the site. Our recommendation is to cancel the connection and report the issue to the web site's server administrator so that they can upgrade their server.
• 0x0200: Disable support of unpatched servers. If enabled you will get a Fatal TLS error page, and will not be able to access the web site until they update their server.

The timings for if/when these settings will be enabled have not been decided, and much will depend on how quickly web site administrators update their servers.


Update February 9th, 2010:

The Mozilla and NSS teams have now released test versions of their implementation of the Renego fix. Futher information can be found at their Wiki, with a test-server located at https://ssltls.de/ . Firefox nightly builds with the fix is available.

Update February 12th, 2010:

The Renego RFC has been published