Implementer's notes

A few hours ago the new online certificate repository that the most recent weeklies are using was updated with several new roots, and an additional CA, Comodo, was also provisionally EV-enabled

The new and the updated CAs are

• America OnLine
  
• Cisco
  
• Comodo
  
• Digicert
  

There is no need to download an updated Weekly (if you have one of the two recent ones). When you next restart one of the Opera 9.50 Weeklies with support for online certificate updates, it will immediately download the indexes, and download the new certificates when necessary. Please give it a minute to finish the update.

Here are a couple of testsites:

• AOL: https://new.aol.com/ . This site will verify in newer versions, but not in older (Warning about issuer). Known problem: The security level is low due to problems with the CRL (Unsupported format, and currently no plans to support it. The connection will fail in the first build). AOL is aware of the problem, and was already working on updating their CRL system
  
• Comodo EV sites:
  
• https://www.sslcertificaten.nl/
  
• https://comodocertificationauthority-ev.comodoca.com/
  
• https://secure.comodo.com/example.html
  

Known Issues: The complex certificate chain system used by Comodo encounters some, mostly hidden, problems with our OpenSSL certificate verification support, and that will cause some EV sites to not be recognized. We will try to fix it, but it may not be advisable to include a fix in 9.50.
[*] DigiCert:

• https://vpn.osrmedical.com/Citrix/AccessPlatform1/auth/login.aspx In older versions this will validate to an Entrust root (see in the Certificate details view of the security toolbar dialog), after this remote update of 9.50 the root will instead be "Digicert High Assurance".
  
• https://www.iwanttss.com/ In older versions this site will trigger an unknown issuer warning, after this update it will also validate to "Digicert High Assurance"
  

I do not currently have testcases for Cisco, as they have not yet started issuing certificates from the new root.

More about known issues:

• We know there are some problems with OCSP and CRL responses (the two kinds of revocation information) from some Certificate Authorities. These problem may lead to the website getting a lower security level. We are looking into these problems together with the CAs. In last week's build some of the CRL problems will cause a "Fatal Error 50", in the most recent build that has been fixed. We may decide to work around some of these, but they should preferably be fixed by the CA.
  
• At least one CA (who is not in our repository) is using CRLs with a critical extension, which will cause the secure connection to fail with error code 554. In this case we are following the standard, although one might wonder why the specification says "Although the extension is critical, conforming implementations are not required to support this extension". The problem have been "fixed" internally by recognzing the extension, then ignore it, as we do not need it.
  

.

Today we're releasing the first Kestrel Weekly with Extended Validation (EV) support.

As I've written before, Extended Validation is a new way to indicate, in a Web site certificate, that the identity of the company behind the Web site has been verified according to a rigorous standard. The guidelines for this process is defined by the CA/Browser forum, which is a group consisting of many certificate issuers (CAs), browser vendors, and others.

We are now ready to start public alpha testing.

So, how does it work?

When a Web site is recognized as an EV site, Opera will change the background color of the security toolbar to green, instead of yellow as it is for normal secure Web sites. There will be a few further adjustments done in this area, the most major being that we have stopped displaying the Organization Name field and country in the security toolbar for non-EV sites, because this name might not have been properly verified for non-EV certificates.


What is required to be permitted to issue EV certificates?

Root CAs that want to issue EV certificates must first pass a rigorous audit to prove that they have the proper procedures in place to identify accurately the company requesting a certificate, and that this company is in control of the given server. Further, an agreement between the Root CA and the browser vendor is required before the browser can recognize the CA's certificates as EV certificates.

How does Opera know it is an EV certificate?

All EV certificates contain an identifier (called an EV-OID, actually a Certificate Policy identifier). The CA will insert this identifier when it has verified all the information. Only certificates issued from specific Roots are allowed to use these identifiers.

How does Opera know that a Root is allowed to issue EV certificates?

Each Opera instance will regularly download a digitally-signed list identifying the CA, its certificate, and which EV-OID(s) it is permitted to use (different CAs can use different EV-OIDs). When Opera verifies a certificate issued from this Root, it will "sift" through the data where the EV-OIDs are stored to see if it contains one of the EV-OIDs recognized for this Root. If such an EV-OID is present, Opera will proceed to check if the other requirements (see below) for saying the Web site is an EV site are fulfilled.

What is required by a Web site to be considered an EV site?

The primary requirement is, of course, that it is eligible to get an EV certificate, and that it has purchased and installed one. The certificate, and all the intermediate certificates must (of course) still be valid, and cannot have been revoked by the issuer (we now check both OCSP and CRLs). Further, there must be no problems verifying the certificate; that is, there must be no unknown issuers, no mismatch of server name, and no weak encryption.

There are also a couple of specific encryption key requirements: The Web site's key should (for RSA) be at least 2048 bits long, but non-root certificates which expire before 23:59:59 UTC/GMT December 31, 2010 MAY use RSA keys of at least 1024 bits. Except for the Root key, which (for RSA) must be at least 2048 bit long, all signing keys must be at least as long as the key of the certificate it is used to sign.

And lastly, if the Web site includes content from other Web servers, those servers must *also* be hosting EV-sites. This is a point at which we are much stricter than the other EV-capable browsers currently. As I said earlier: "It ain't EV 'til it is EV, all EV".

The reason for this requirement is that these other servers may provide content that directly controls the appearance of the entire site, either through frames or external Ecmascript embedded in the page (and the latter has full control of the site's content).

Considering how many click-wrap licensed Web services (such as for Web statistics) there are, it is not likely that the Web designers signing their sites up for these services will have done anything close to good-enough legal identity check of the service. Also, don't forget all the liability disclaimers such contracts include. It is impossible to check the contracts, but we can check that the sites have been able to get an EV certificate.

EV is intended to give you better information about who provided the content with which you are viewing and interacting. If not all the servers providing the content are providing this kind of information, do you really know who provided the important part of the content? Our answer is that you don't, therefore such sites, which at the moment include Paypal.com, will not get the EV indication unless they either remove all references to the non-EV content, or those providers upgrade to provide EV content, as well.

Which Root CAs are currently recognized as issuing EV certificates?

During the test period starting with this release we have provisonally configured three Roots as EV Roots (in alphabetic order)

• Entrust's EV Root
  
• GlobalSign's EV Root
  
• VeriSign's G5 Class 3 (EV) Root
  

Other CAs and Roots may be added later.

About the online repository

As mentioned above, Opera retrieves information about which CAs are recognized as EV-issuers from an online repository. This repository, hosted at https://certs.opera.com/, contains a digitally-signed file listing all the EV issuers and a (separately) signed list of the EV-OIDs they are using.

This repository is refreshed every 6 hours, so we can start updating clients very quickly. At present Opera will check this repository immediately when it starts, but the final version will only check once a week at the same time as we check for other updates.

Examples of EV sites

• https://www.dnbnor.no/
  
• https://nettbank.sparebank1.no/
  
• https://healthcare.searchamerica.com/
  
• https://taxcube.kpmgabogados.es/
  
• https://meine.deutsche-bank.de/mod/WebObjects/dbpbc.woa?lang=en
  
• https://ev.globalsign.com/
  

One of the new SSL/TLS features we added in 9.0 was the TLS Certificate Status Extension, which is essentially asking the TLS server to do the revocation check for its own certificate (OCSP), thus telling the client whether or not the certificate it presents is valid.

At first this can look pretty much like putting the fox to guard the henhouse, but there is no real danger as even a malicious server can't get away with sending the wrong data for long. This is because the status information is generated and signed by the certificate issuer (CA), meaning it can't be faked, and is only valid for a few days at most, reducing the window of opportunity to a minimum.

The primary reason for using this method is reducing the traffic load on the OCSP servers. Once all clients support OCSP the load on those servers will be tremendous, so it is prudent to look at solutions to reduce not just the network load on the CA's servers, but also the time used to check the validity of the certificate. It is a fact that making a direct OCSP check takes time, and that it increases the time to establish a connection, slowing down the user's surfing.

Therefore, using the TLS server as a proxy makes sense, and we introduced it in 9.0.

Unfortunately, it turned out that the implementation had a problem. Due to a mistake in the way the Extension was read, a method introduced in 9.0, Opera 9.0 to 9.25 will crash when the server tells it that it will send the status message.

This showed up only when Microsoft started testing its Windows 2008 server (IIS 7), due to be released this month.

Unfortunately, it was not until less than two weeks ago I learned of the problem, when Microsoft contacted me directly with a testcase (Thanks). It didn't take me long to find and fix the problem, but it still requires releasing a new Opera version.

In this case I will strongly recommend that users of Opera 9.0 to 9.25, inclusive, upgrades to the upcoming Opera 9.26 (Update: It is now available), due to be released later this week (but an RC is available). The next 9.50 weekly will also contain a fix for the problem. In particular, you should upgrade if your installation crashes when it tries to connect to an SSL/TLS/HTTPS site.

We apologize for the inconvenience, in this case we were a little bit too far out on the (b)leading edge.

One of the most important parts of SSL/TLS, as it is used in browsers, is the use of certificates to identify the website you are visiting, and to identify the keys used to agree on the encryption keys used for the connection.

The certificate is the website's passport, and like a passport it is issued by an authority trusted by the people checking them. For passports this is the government of a country, for certificates it is a trusted Certificate Authority (CA).

As with passports, there are a lot of things that have to be checked to make sure the certificate is not forged.

Each certificate contain, among other things the name of who the certificate is issued to (the website); the public key of the website; who issued it (the CA); and a digital signature of the data in the certificate, which is signed by the CA.

To verify the signature the browser must use the public key of the CA to decrypt the signature (which could only be created by using the associated private key), and compare the result with the calculated "checksum" of the certificate. The public key is stored in another certificate issued to the CA - the CA certificate.

There are two types of CA certificates, the ones that are signed by yet another CA, called Intermediate CA certificates, and certificates signed by the CA itself, which are known as the Root Certificates or Self Signed Certificates.

The Intermediates CA certificates are verified using the public key of the signing CA, while the Root CA certificates are verified using the public key in the certificate itself.

The Root CA certificate is a special case. By itself it only verifies that somebody claiming to be the named issuer issued the Root Certificate, and by extension vouches for the named identity in the certificates issued from it. But that does not carry any real assurances.

To be sure that the Root CA is valid the signature on the certificate have to be verified by a trusted copy of the Root Certificate, stored in the client's list of such certificates. These certificates are usually shipped with the client, and are accepted and trusted by the vendor to be reasonably careful about who they issue certificates to and how they store the private key. The user can elect to not trust some of these roots, and may add his own list of certificates.

Only a certificate and its associated certificate chain that can be verified and traced back to a Root in the Trusted Root store on the client is accepted automatically. If a certificate cannot be verified because the signature does not validate this is a fatal error; if we can't trace the certificate to a known root we display a certificate warning.

A problem often encountered is that a web site gets a certificate from a CA that is issued from an Intermediate CA (Most CAs do this now, for convenience and security reasons, as well as for selling CA certificates to CAs without their own root or to cross-sign roots) but the web site administrator forgets to install the Intermediate CA certificate on the server. This means that the client will not be able to trace the certificate to a known Root, even if it has the Root in its repository, because clients usually do not, and are not expected to, know specific Intermediate CA certificates; the result (for the user) is an unexpected Unknown Issuer certificate warning.

SSL/TLS servers that do not send intermediate certificates are actually not operating in compliance with the SSL/TLS standard. The standard requires the server to send any CA certificates it cannot reasonably expect the client to have already, and the only thing it can expect the client to have is the root certificate, and not any intermediates.

There is however a mechanism (called Authority Information Access, AIA) defined in the specification of the certificate format that let the CA specify a "CA Issuer" download location for the Intermediate CA certificates. This mechanism is already used by at least one other browser (which neatly explains why so many badly configured sites get past testing), and now Opera 9.50 also use this mechansism.

When Opera 9.50 encounters a site with a certificate chain that is missing an Intermediate CA certificate linking it to the Root, but the certificate specifies an AIA issuer download location, Opera will download the specified certificate. If the verification then succeeds (without other incidents) to link the certificate with a known root, the certificate will be accepted as normal, and the intermediate CA certificate will be "cached" in the new Intermediate CA certificate store in Opera's certificate manager for future reference, to avoid downloading it again later.

What this means is that you will no longer get any certificate warnings about unknown CAs when the certificate is issued from a root and a CA that also includes an AIA issuer download location for the intermediate certificate(s) for the Intermediate CA(s) that issued the certificate.

Special thanks to Gary and Les in Verisign for helping me debug this new functionality.

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