Implementer's notes

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/
  

As I explained in "NOT in Kestrel #4", the certificate is the passport of the website. What was not significatly mentioned in that article is that if there is any non-fatal problem with the verification of the certificate, or with other related information, Opera (and other clients) will display
a certificate warning.

Problems that cause certificate warnings to be displayed can for example be:

• The certificate issuer is unknown (and it is not possible to discover a link to a known Root).
  
• The certificate is expired
  
• The name of the server does not match any of the servers named in the
  certificate.
  
• Weak encryption keys (now only public keys)
  

These warnings are displayed the first time in a session that you connect to a given server, and would not be displayed again for the rest of the session if the user accepted the certificate.

This has (understandably) caused some irritation when a user is frequently visiting a site causing such warnings to be displayed, and there has been frequent requests to be able to accept such certificates more permanently.

I have been, and still am, skeptical to such an ability, because I think a serious and secure website should not trigger security warnings.

I have, however, decided to meet the requests halfway. In Opera 9.50 it is now possible from the security panel of the certificate warning to "permanently" accept a certificate for the given SSL/TLS server (and port). Although accepted by the user, Opera will (same as before) not display a padlock for these sites because Opera has not been able to properly establish the server's credentials.

The acceptance isn't, however, quite "permanent" (therefore the quotes). A certificate that has not expired will be accepted until it expires (at which time the webmaster SHOULD replace it), and for periods of 90 days at a time after expiration.

Enjoy, but use with caution.

Seasons Greetings! See you in the new year.

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

I've just submitted updated versions of my HTTP Cookie and Cache related Internet-Drafts to the IETF.

I've covered the background for these drafts previously in these articles: Cookie-1, Cookie-2, Cache Context.

If you have comments, suggestions, corrections, etc., feel free to discuss them here, or directly with me. General discussion of the proposal should take place on the IETF's HTTP Work Group mailing list.

In a couple of days the drafts should become available in the IETF Internet-Draft repository at these locations:

draft-pettersen-dns-cookie-validate-02.txt

draft-pettersen-subtld-structure-02.txt

draft-pettersen-cookie-v2-01.txt

draft-pettersen-cache-context-01.txt


Archive copies can be found here:

draft-pettersen-dns-cookie-validate-02.txt

draft-pettersen-subtld-structure-02.txt

draft-pettersen-cookie-v2-01.txt

draft-pettersen-cache-context-01.txt

April 30th, 1997 (give or take a few days; remembering exact days can be hard) was the first time Opera's SSL implementation completed a full transaction.

The four months prior to this largely unnoticed (but for Opera significant) event, had been very busy. I had to study and learn about SSL and general cryptography, then do intense design and development work, followed by a lot of testing and debugging.

The SSL support in Opera was my first assignment when I started working at Opera. You might say that I was thrown in at the deep end. The benefit, of course, was that my hands weren't tied by a pre-exisiting design.

Geir^1,2, who was then developing the network code, as well as the rendering engine, had been looking at the SSLeay crypto-library (it's now known as OpenSSL), which had an SSL implementation, but hadn't gotten much further than starting to look at the specification and download SSLeay by the time I started at Opera.

After looking at SSLeay's interfaces and code I reached the conclusion that the SSL implementation would not work well with our network code and decided that an independent implementation of the protocol would be better, although I kept SSLeay around for the crypto support, which was independent of the protocol.

A couple of other decisions were:

• Avoid implementing the basic crypto functions myself. It is far too easy to get something wrong in that code, both with respect to performance and correctness (and security). Also, it would take far too long to implement all the necessary functionality. So we used SSLeay for the encryption and certificate support.
  
• Isolate the encryption and certificate handling code from the rest of the protocol implementation so that we could, if necessary, replace the crypto support library without major changes to the rest of the code.
  
• Isolate atomic structures as much possible, as well, in object oriented classes, because it made coding easier. This is very easy in C++, and I could do this using techniques I learned during my masters thesis work.
  

I started by implementing SSL v3, since it was then the most recent definition, and also quite well defined. I still hold the SSL v3 and TLS specifications as some of the best written protocol specifications I have seen (with PKCS #7 and S/MIME as some of the worst ones). SSL v2 I postponed until later.

Implementing something from scratch is hard work, and you often have to backtrack as you find that the current solution design did not work out as expected. But it is, of course, this challenge that is a large part of what attracts many to software development.

After a couple of months, and having integrated the new protocol with the network code, we were ready to make it work.

This also involved a lot of work, and some situations can be a little bizarre. One time I got to the point where I had sent the encrypted keymaterial (used to calculate the encryption keys) to the server, and the server slammed the door in my face (which is what it almost always did when I made a mistake).

All right, that indicated (of course) that something was wrong with the data we sent.

So, I checked that we encrypted correctly, that we encoded the message correctly according to the specification. Everything checks out. OK, let's take a look at what the competition is doing: Huh, it's *not* following the spec?! I test that "method", and it works to get me to the next stage.

I send off an email to the specification authors, and ask what is going on? The answer: It looks like Netscape (who wrote the spec) implemented it wrong in their clients and servers, and so it stuck (but they said TLS 1.0 was going to do it right).

This incident has an amusing follow up story. Almost two years later I was testing against the newest SSLeay development version which was going to support TLS 1.0, and ran into the same problem. I double checked with the TLS spec authors, but the spec had not changed, so I told Eric Young he had made a mistake, and to be sure I had it right he put the question to the TLS work group mailing list, and got the same answer I got.

Finally though, April 30th the code worked well enough that we could actually get a web page back.

The implementation was by no means finished, and work would continue for the rest of the year to get the SSL implementation into a shape fit to be shipped in Opera 3.0. But just to "round" that day off, I spent two or three hours implementing the TLS 1.0 version, even though I wasn't able to test it until early 1999, at which time it took just a week to get it working properly and mostly ready for Opera 3.50.

The SSL implementation wasn't static (and still isn't). Work on improving it continued, and is continuing:

• In 1999 we added TLS 1.0 support, as one of the first clients to do so.
  
• A while ago I started a complete rewrite of the protocol control engine
  because I was encountering more trouble with adding new functionaliy. Part of what I did was to take the design methods I had used earlier and go even further along that route (I get the impression a few colleagues would say I went too far , I suspect they just got caught up in the details). This new engine became active in 9.0.
  
• We have regularly updated the version of SSLeay and later OpenSSL, although the first major upgrade was the worst, due to the major internal changes in the certificate system made in the 0.8.x compared to the 0.6.x version we were using at the time.
  
• We have added new encryption methods as they became available.
  
• We have improved the security related information we show users.
  
• We were among the first (if not the first) to deploy a client supporting TLS 1.1 and TLS Extensions, in fact so early we had to disable it and develop a workaround before we could enable it by default (I actually got a question from Microsoft , about them having the same problems with TLS Extensions that we had).
  

What is in the future of Opera's SSL/TLS implementation?


[*]We are adding support for Extended Validation certificates.
[*]There are some big changes coming in the certificate management system.
[*]In Kestrel we are planning to completely remove support for SSL v2 and the weak 40 and 56 bit ciphers.


Some may wonder why we are still using our own implementation of SSL and TLS when there are several implementations around. After all, some of the original reasons for the choice no longer exist.

Well, while we do use other implementations on some platforms, for technological reasons, one major reason is that it gives us more control of what functionality we support. For example, we implemented TLS 1.1 and TLS Extension 3 years ago, and we are actually still the only major TLS 1.1 client around, and other TLS Extension clients did not show up until second half of 2006 (although that is a chicken and egg situation). We are also more at liberty to integrate the code better with our own processes and techniques.

Having our own implementation also makes it easier to move the functionality to a new platform, although Open Source implementations have the same benefit.

Another reason may be a bit more philosophical, as Opera's engine is one of only four major SSL/TLS clients deployed, and at least two of the other three are also developed with the server side. This means that Opera's client may be able to keep the others from implementing mistakes that then get turned into de-facto standards (which is what happened with the above mentioned specification). Diversity is what will keep the net working.

But, that question is also similar to a few other questions: Why develelop our own HTML parser, webpage rendering engine, our own browser, and so on? In this context, another obvius reason becomes clear, we think we can implement these things better ourselves.

Although we have hit the occasional troublespot, I think (if I may be so bold) that the design I chose in 1997 has worked out quite well. While there has been some big changes in parts, the basic design and functionality of Opera's SSL implementation are still quite similar to the original implementation.