Implementer's notes

In the past couple of weeks I have been sewing up most of the loose threads in Opera's support for Extended Validation (EV) certificates, and have actually started testing something that resembles the final system.

The work to add Extended Validation has been going on for a while, the basic functionality was implemented last year, but there hasn't been time to build the surrounding infrastructure until this year.

Now, we are finally starting to see the end of the road.

However, I have started to notice something that could become a problem: Not all EV sites, such as Verisign's and PayPal's sites, are coded the way I think they should be coded, or the way Opera's EV support need to be able to recognize them as EV sites.

The sites themselves and the content they serve are not the problem. The thirdparty content they have chosen to include on their site is; Content that is NOT served from EV servers. Apparently, MSIE 7 does not take this external content into consideration when deciding to show the EV indication.

One of the most prominent examples of this third-party content is Google Analytics, which is added to a web page by an external Javascript from a non-EV secure server hosted by Google. Since Google's servers are not using EV certificates, Opera's EV support does not consider the site to be an EV site.

This is due to how Opera's security evaluation system works. Each URL loaded is evaluated based on which protocol was used, what kind of encryption, keylengths, and whether or not the certificate validated correctly. All of this is summed up as a Level in the range of 0 to 3 as follows

• 0: No encryption (example, plain HTTP)
• 1: Weak encryption (40 and 56 bit symmetric methods), weak keys (less than 900 bits RSA/DH/DSA), certificate errors, authentiction only. Additionally a combination of problems that would result in Level 2 security being displayed if only one of them were encountered.
• 2: One, and only one, of these: medium strength keys (900-999 bit RSA/DH/DSA) or failure to get a valid OCSP response. A combination of both results in Level 1 being chosen.
• 3: Only when using 128 bit encryption, 1000 bit or more RSA/DH/DSA keys, no certificate validation problems.

EV is implemented as Level 4 in this ranking, and a Level 3 resource is only escalated to Level 4 if it contains the necessary EV identificator.

For a group of URLs, such as a web page with redirects, images, CSS, scripts, frames, and so on, the URL with the weakest security level determines the security level for the entire document. This means that a web page with a single unencrypted 1-by-1 image gets Level 0, and that an EV website which includes a 1-by-1 image from a Level 3 non-EV site does not get the EV status. The only exception to this rule is that, on certain conditions, the first request may be a HTTP to HTTPS redirect.

The reason for this design is simple:

• It is difficult, and in most cases impossible, for a web browser to determine how sensitive a particular element of a page is.
• Some elements can affect the meaning of the site (for example, a big image, a script, or a frame).
• In some cases, such as unencrypted requests, analyzing that traffic may reveal what the user is working on (for example, evaluating a stock transaction).

One can make the argument that since the page is secure we can assume that the owners of the site know what they are doing, and that any use of less secure resources is intentional and does not represent a security problem. That assumption is wrong. They may know what they are doing, and have no intention of lowering the security level, but they can still make a mistake somewhere. In at least two cases I have seen, misconfiguration of proxies or redirects caused content that was not secure to be included in otherwise secure banking/payment pages. In one of the cases this content was an external JavaScript used in a payment page, and an attacker could have gotten full access to the secure page if he had changed the JavaScript in transit.

With respect to EV one can make the same argument, but it is flawed in this case, too:

• The primary point of using an EV certificate on a site is to know the identity of the site's owner.
• The EV site's owner may or may not know who owns a non-EV third-party site, the client has no way of determining that. We do not know, and cannot know, if the agreement is just a click-wrap or the result of months long lawyer negotiations.
• In several of the observed cases the third-party content was external JavaScript, which means the third-party is essentially granted full access to manipulate the site's content, and all of it.
• By allowing non-EV third-party content in a EV site it becomes possible to set up EV "redirector" sites that let non-EV sites look like they are using EV by embedding their content in a frame.

Part of the reason for creating Extended Validation certificates was raising the bar for identification on the Internet, so that is what we will do: Raise the bar.

When Opera ships a version with EV, probably in Kestrel, a site will not be considered as having EV unless all resources used in the rendered page are using Extended Validation certificates.

"It ain't EV 'til it's EV, all EV"