Extended Validation Update
Friday, 12. September 2008, 13:32:03
Today we have formally EV-enabled the first two CAs.
For more information, please see The Rootstore's announcement
For more information, please see The Rootstore's announcement
Posts tagged with "TLS"
W3C Web Security Context: User Interface Guidelines
Thursday, 24. July 2008, 19:46:13
The W3C's Web Security Context Working Group have just released the Last Call version of its "User Interface Guidelines" document, which is a set of recommendations for the security related UI in Web User Agents.
If you want to comment on the document you are welcome to do so:
This specification deals with the trust decisions that users must make online, and with ways to support them in making safe and informed decisions where possible.
This document specifies user interactions with a goal toward making security usable, based on known best practice in this area. Subsequent testing of this specification will include conformance, interoperability, and usability testing.
If you want to comment on the document you are welcome to do so:
The W3C Membership and other interested parties are invited to review the document and send comments to public-usable-authentication@w3.org (with public archive) through 15 September 2008. We appreciate if comments follow these guidelines for writing good issues.
Announcing "The Rootstore"
Thursday, 3. July 2008, 16:52:55
We have now created a homepage for the Opera Root Certificate repository: The Rootstore.
The Rootstore will be where we announce updates and general information about the root repository.
If you are a Certificate Authority, or generally interested in Opera's certificate store, The Rootstore will be the place to watch.
The Rootstore will be where we announce updates and general information about the root repository.
If you are a Certificate Authority, or generally interested in Opera's certificate store, The Rootstore will be the place to watch.
"Nobody checks the padlock" debunked by Opera users
Friday, 27. June 2008, 13:53:06
There's been a number of criticisms directed at the padlock over the years, some of which may be correct, to some extent, at least.
One objection has been that users misunderstand the padlock's meaning, thinking it is an indicator of trustworthiness, rather than a protection rating for the connection.
Another objection (which flies in the face of the first), is that "nobody checks the padlock".
Well, I can't say much about the correctness of the first objection, but the past couple of weeks a growing number of Opera users have been working hard at debunking the second one.
In Opera 9.50 we added some new security features, and changed a some others. Two of these are the following:
Both of these turned out to encounter unexpected problems, not due to bugs in our implemenation, but at the CA side. In all cases the problem cause full validation of the certificates to fail, and as a result Opera reduces the security level of the connection so that a padlock will not be displayed. Quite a lot of people noticed.
For OCSP we encountered problems with at least three different brands of OCSP responders. These responders did not respond correctly when we sent a request for infromation about a certificate. It wasn't until a couple of weeks ago that the vendor for one of them discovered the reason for the problem, their expectation of input format was wrong. According to my information they have developed a patch, and I assume they are doing QA on it now, before sending it to the two (or more) CAs that are affected by this. The others have shown up recently and I do not have good information about the causes.
With CRLs we encountered two problems. Just before 9.50 was released we got the first reports about the first case, but it was not until a few days after the release that we got an overview of the situation.
It turns out that one specific CA created an intermediate certificate a few years ago for one of their certificate hierarchies. This certificate included an incorrect URL for where we should go to fetch the CRL, so when Opera fetches the CRL it gets a CRL created for a different hierarchy than the one being verified. As a result Opera's ceritificate validation code can't find the right CRL, and this step fails. This certificate became installed on thousands of servers before the mistake was discovered, and despite a campaign to replace the certificates, several hundred sites (many of them banks) still use the old certificate.
In another case, which came to light last week, another CA have issued an intermediate certificate directly below their root that does not contain a URL for a CRL, but the sub-ordinate certificate issued from that intermediate does specify a CRL. As Opera's certificate validation code expects that if one certificate have a CRL they all use CRLs, validation of the topmost intermediate certificate fails because it can't find the CRL for that certificate.
What can be done about this?
These changes will be active in the upcoming Opera 9.51 RC2 (Update: Now available), and is already active in the online certificate repository. You will get the updates the next time Opera checks for updates, or if you use Help->Check for updates.
Update July 9: There are some sites with certificates that does not provide any CRL or OCSP information in the site certificate, while the rest of the certificate in the chain have CRLs. Due to a minor bug, and restrictions in the override functionality, the override for that will not become active before 9.52 has been released. At present we are only aware of 10-20 sites affected by this.
One objection has been that users misunderstand the padlock's meaning, thinking it is an indicator of trustworthiness, rather than a protection rating for the connection.
Another objection (which flies in the face of the first), is that "nobody checks the padlock".
Well, I can't say much about the correctness of the first objection, but the past couple of weeks a growing number of Opera users have been working hard at debunking the second one.
In Opera 9.50 we added some new security features, and changed a some others. Two of these are the following:
- We now use HTTP GET requests to retrieve OCSP revocation information
- Additionally we download further revocation information, the CRLs (Certificate Revocation Lists), from the issuer and check those.
Both of these turned out to encounter unexpected problems, not due to bugs in our implemenation, but at the CA side. In all cases the problem cause full validation of the certificates to fail, and as a result Opera reduces the security level of the connection so that a padlock will not be displayed. Quite a lot of people noticed.
For OCSP we encountered problems with at least three different brands of OCSP responders. These responders did not respond correctly when we sent a request for infromation about a certificate. It wasn't until a couple of weeks ago that the vendor for one of them discovered the reason for the problem, their expectation of input format was wrong. According to my information they have developed a patch, and I assume they are doing QA on it now, before sending it to the two (or more) CAs that are affected by this. The others have shown up recently and I do not have good information about the causes.
With CRLs we encountered two problems. Just before 9.50 was released we got the first reports about the first case, but it was not until a few days after the release that we got an overview of the situation.
It turns out that one specific CA created an intermediate certificate a few years ago for one of their certificate hierarchies. This certificate included an incorrect URL for where we should go to fetch the CRL, so when Opera fetches the CRL it gets a CRL created for a different hierarchy than the one being verified. As a result Opera's ceritificate validation code can't find the right CRL, and this step fails. This certificate became installed on thousands of servers before the mistake was discovered, and despite a campaign to replace the certificates, several hundred sites (many of them banks) still use the old certificate.
In another case, which came to light last week, another CA have issued an intermediate certificate directly below their root that does not contain a URL for a CRL, but the sub-ordinate certificate issued from that intermediate does specify a CRL. As Opera's certificate validation code expects that if one certificate have a CRL they all use CRLs, validation of the topmost intermediate certificate fails because it can't find the CRL for that certificate.
What can be done about this?
- About the OCSP issue, we wait for the vendor patch, but in Opera 9.51 we have added an override that lets us use the certificate update system to specify which OCSP URLs that must use the old POST method. In addition one CA also deployed a workaround.
- About the first CRL issue, the websites need to update their installed certificates, in the second case the CA must also issue a new updated certificate. While waiting for that, in 9.51 we are adding a similar override mechanism as for OCSP, by specifying extra CRL download locations for specific CAs. In the second case we might also be able to fix the issue if the CA has a root for that particular CA name by distributing it to all installations that access the affected sites (that is not a realistic option for the first case).
These changes will be active in the upcoming Opera 9.51 RC2 (Update: Now available), and is already active in the online certificate repository. You will get the updates the next time Opera checks for updates, or if you use Help->Check for updates.
Update July 9: There are some sites with certificates that does not provide any CRL or OCSP information in the site certificate, while the rest of the certificate in the chain have CRLs. Due to a minor bug, and restrictions in the override functionality, the override for that will not become active before 9.52 has been released. At present we are only aware of 10-20 sites affected by this.
Lowering the EV bar
Friday, 23. May 2008, 14:48:32
Last week at the W3C's Web Security Context Working Group's meeting at Opera HQ here in Oslo we discussed what should be the criteria for displaying the Extended Validation (EV) indicator, or the Augmented Assurance (AA) indicator, as the WG has decided to call this technology.
As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.
The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.
The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.
In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.
We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.
As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:
As I have said earlier, we are of the opinion that the EV indicator should not be displayed unless all content is loaded from EV servers.
The opposing view is that, so long as all content is loaded over secure connections, the displayed document is what the author of the main document intended (bugs, vulnerabilities, and all), and that it is therefore only necessary to verify that the main document is served from an EV server, as this will provide the information necessary to identify the author.
The decision of the WG was in favour of the less restrictive position: if an AA/EV document loads all resources over strongly TLS-protected connections, then the document can be displayed with an AA/EV indicator.
In the interest of providing a common user experience with respect to EV we have decided to follow this recommendation, and today's Kestrel snapshot include this policy change.
We have, however, left the old logic in place, controlled by a preference that can be updated remotely. This permits us to quickly change to a stricter mode if the consensus about what constitutes an AA/EV site changes in the future.
As a consequence of this policy change a large number of sites, such as Paypal, with mixed EV and non-EV content will now get the "Green Bar" in Opera:
More testing: Updated EV information and new Roots
Friday, 18. April 2008, 18:22:12
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
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:
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:
I do not currently have testcases for Cisco, as they have not yet started issuing certificates from the new root.
More about known issues:
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.
New in Kestrel: Faster Root Certificate updates
Tuesday, 8. April 2008, 15:55:26
Extended Validation (EV) is not the only new feature in the most recent Weekly; we've also improved the certificate database by making it able to download new Roots automatically. This means that we can add new Roots to the Certificate Authority database without requiring users to update their installation.
Root Certificates are one the fundamental pillars of Internet security. They are used to confirm the identity of secure webservers by acting as a trusted third party. The introduction of a third party is what makes it possible for two parties that have had no previous contact to determine who the other is, and, based on that, establish an encrypted connection. That is the true "magic" of Public Key Cryptography.
The problem with Root Certificates has been that before they can be used, each relying party (in particular, TLS clients, as in our case) must have a copy of it. If a party doesn't have a trusted copy of the Root it cannot verify the certificate that the other party sent, and can therefore not make any statement about the identity, nor establish a secure connection to that other party.
In SSL/TLS clients like Opera, much of this initial problem has been handled by the vendor shipping a list of trusted Roots with each installation, as well as some update mechanism to add new Roots when necessary. In Opera, this update mechanism has until now been rather crude, as a new version of Opera would have to be installed by each user.
In this Weekly, we are adding an automatic certificate download capability that works like this:
The certificates are downloaded from a repository hosted at https://certs.opera.com/, which is also the server hosting the EV information, and the information is refreshed every 6 hours. The certificate files hosted on this server, whose names are constructed from a SHA-256 digest of the CA name and other information that uniquely identifies them, are all digitally signed to prevent forgery.
A separate list in the repository identifies all the certificates that are included in the repository. This list is used to stop Opera from checking the repository for unknown issuers. The list is currently retrieved every time Opera starts, but will later be checked when Opera checks for other updates, that is, once a week when Opera starts.
We are particularly interested in your experiences with this new functionality and would like you to test it in various environments, such as:
Also, somebody may ask, "Does this mean Opera now have the ability to automatically remove a Root certificate?". Yes, in extreme cases, such as the unlikely event (I hope) of a Root Key compromise, we now have the ability to do what previously would have required an emergency security update.
We also have the ability to add certificates to the new "Untrusted" certificate store, which might be necessary in cases where an important certificate has been issued in error.
Root Certificates are one the fundamental pillars of Internet security. They are used to confirm the identity of secure webservers by acting as a trusted third party. The introduction of a third party is what makes it possible for two parties that have had no previous contact to determine who the other is, and, based on that, establish an encrypted connection. That is the true "magic" of Public Key Cryptography.
The problem with Root Certificates has been that before they can be used, each relying party (in particular, TLS clients, as in our case) must have a copy of it. If a party doesn't have a trusted copy of the Root it cannot verify the certificate that the other party sent, and can therefore not make any statement about the identity, nor establish a secure connection to that other party.
In SSL/TLS clients like Opera, much of this initial problem has been handled by the vendor shipping a list of trusted Roots with each installation, as well as some update mechanism to add new Roots when necessary. In Opera, this update mechanism has until now been rather crude, as a new version of Opera would have to be installed by each user.
In this Weekly, we are adding an automatic certificate download capability that works like this:
- A number of frequently used Roots are still shipped with Opera.
- If a Web site presents a certificate issued from a Root that is not in the local Certificate store, but is available in the online repository, it will be downloaded and installed in the repository. (Please note that this means that if you delete a certificate rather than marking it as untrusted, it will be downloaded again if necessary.)
- If a Root is added to the repository, and is closely associated with another Root, we can instruct all Opera instances to download that root if they have the other Root. This is particularly important in relation to how EV certificate chains have to be organized.
The certificates are downloaded from a repository hosted at https://certs.opera.com/, which is also the server hosting the EV information, and the information is refreshed every 6 hours. The certificate files hosted on this server, whose names are constructed from a SHA-256 digest of the CA name and other information that uniquely identifies them, are all digitally signed to prevent forgery.
A separate list in the repository identifies all the certificates that are included in the repository. This list is used to stop Opera from checking the repository for unknown issuers. The list is currently retrieved every time Opera starts, but will later be checked when Opera checks for other updates, that is, once a week when Opera starts.
We are particularly interested in your experiences with this new functionality and would like you to test it in various environments, such as:
- performing an upgrade of a used test installation of 9.2x
- clean installs,
- whether or not secure sites that worked in 9.2x and previous Kestrel Weeklies work OK in this build.
Also, somebody may ask, "Does this mean Opera now have the ability to automatically remove a Root certificate?". Yes, in extreme cases, such as the unlikely event (I hope) of a Root Key compromise, we now have the ability to do what previously would have required an emergency security update.
We also have the ability to add certificates to the new "Untrusted" certificate store, which might be necessary in cases where an important certificate has been issued in error.
New in Kestrel: End of the Extended (Validation) wait
Tuesday, 8. April 2008, 15:54:39
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)
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
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
The trouble with the (b)leading edge: It's sharp!
Tuesday, 19. February 2008, 18:21:18
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.
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.
New^W NOT in Kestrel #5: As many certificate warnings (if you don't want them)
Friday, 21. December 2007, 16:01:34
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:
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.
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.
Showing posts 1 - 10 of 31.
Yngve Nysæter Pettersen
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
 September 2008November 2008 | ||||||
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 | |
Tags
Countdowns
810 days until
1024 bit RSA encryption/signing officially deprecated
Recent visitors
A proud member of the My Opera community. | Help | Disclaimer