Archive for the ‘Technical’ Category

Chain Certificates

Tuesday, August 31st, 2010 | Bruce Morton

What are chain certificates? Chain certificates are referred to by many names — CA certificates, subordinate CA certificates or intermediate certificates.  Confused yet? Let’s break it down.

It all starts with something called a root certificate. The root certificate is generated by a certification authority (CA) and is embedded into software applications. You will find root certificates in Microsoft Windows, Mozilla Firefox, Mac OS X, Adobe Reader, etc. The purpose of the root certificate is to establish a digital chain of trust. The root is the trust anchor.

The presumption is that the application developer has pre-screened the CA, ensured it meets a minimum level of trust and has accepted the CA’s root certificate for use. Many application developers, including Adobe, Apple, Mozilla, Microsoft, Opera and Oracle, have root certificate programs. Others rely on the roots provided by the underlying operating system or developer toolkit.

One of the main functions of the root is to issue chain certificates to issuing CAs — the first link in the chain of trust. Your Web browser will inherently trust all certificates that have been signed by any root that has been embedded in the browser itself or in an operating system on which it relies.

Why do you need an issuing CA? The purpose of the issuing CA is to isolate certificate policy from the root. Issuing CAs can be used to issue many different certificate types: SSL, EV SSL, Code Signing, Secure Email, Adobe CDS, etc. These certificate types are subjected to different requirements and risks, and as such have different certificate policies. The certificates may have different assurance levels such as high, medium and low. Issuing CAs may also be controlled by an organization other than that which controls the root.

The last link of trust is that between the end entity certificate and the issuing CA. In the case of an SSL certificate, the end entity certificate represents the linkage between a website owner and the website domain name. The SSL certificate is installed on the Web server along with the chain certificate. When a user browses to the website protected by the SSL certificate, the browser initiates the verification of the certificate and follows the chain of trust back to the embedded root.

In some cases, the CA may have chosen to issue end entity certificates directly from the root CA. This is an outdated practice; issuing directly from the root increases risk and limits how certificate policy can be managed and enforced. Issuing directly from the root can also impact performance as the browser may have to verify a large certificate revocation list (CRL) during its chain validating process. Major public CAs are discontinuing or limiting this practice.

When you receive an Entrust certificate, we provide any required chain certificate complete with installation instructions.

Tags: , , ,
Posted in Browsers, EV SSL, Technical | Add Comment | No Comments »

Black Hat and DEF CON Follow-up

Friday, August 20th, 2010 | Bruce Morton

Here is a follow-up to my earlier post SSL Security Silly Season.  Black Hat USA 2010 and DEF CON 18 conferences held at the end of July had three presentations that addressed SSL issues. Here is a quick summary and where you can get more information.

Internet SSL Survey 2010 by Ivan Ristic
In this study, Qualys SSL Labs searched large numbers of internet domain names for HTTPS servers and used their assessment engine to collect statistics about SSL usage.  In total, they found 867,361 unique certificate chains offered by HTTPS servers.  By their estimate, this accounts for 25-50% of all commercial certificates.  Issues found were incomplete certificate chains, chains that are too long, certificates presented in the wrong order, and certificates with Debian weak keys.

HTTPS Can Byte Me by Robert Hansen and Josh Sokol
This presentation was about the flaws in the browser implementation of HTTPS or rather flaws that can be exploited even when the user is connecting to a site over HTTPS. The researchers focused on 24 issues all related to man-in-the-middle (MitM) attacks. They concluded that some of the attacks were hard or flakey and that there are better ways to exploit people and learn their vital information. In Hansen and Sokol’s associated white paper, they state: “Using proper tab isolation, better cookie management in the browser and better ‘white-noise’ generation in the SSL stream could help prevent the majority of these attacks presented.”

An Observatory for the SSLiverse by Peter Eckersley and Jesse Burns
Electronic Frontier Foundation (EFF) SSL Observatory collected x.509 Certificates used for HTTPS on the internet. They looked for odd behavior and were basically checking up on CAs. They were able to identify “trusted” intermediaries (foreign, security agencies, companies) and found many “weird, wonderful and suspicious certificates.” They will be opening their data to the public for further review.

Tags: , , ,
Posted in Browsers, Technical | Add Comment | No Comments »

Quality vs. Quantity: SSL Certificate Verification Practices

Monday, August 9th, 2010 | Bruce Morton

VeriSign announced that GeoTrust (a VeriSign subsidiary) SSL certificates are most often used to secure the most-visited web sites. This was established by cross-referencing the Alexa 1 Million with the July 2010 Netcraft SSL survey. The results revealed 35,142 unique domains protected by GeoTrust SSL certificates out of approximately 165,000 of the Alexa 1 Million on which Netcraft found certificates.

I took a closer look at the Netcraft SSL Survey data. It found 334,777 GeoTrust certificates of which 304,199 were domain-only validated.  As VeriSign states, “the chief intended purpose of SSL is authenticating sites and protecting transactions”; however, 91% of the time GeoTrust SSL certificates fail to provide any identifying information with regards to who controls the web site.

Domain-only validated (DV) certificates are typically verified and issued through automated processes. Human intervention is minimized and organization checks are eliminated to support issuing the certificates quickly and cheap. As such, a DV certificate contains no identifying information in the organization name field. Typically this value just re-states the domain name or simply says “Persona Not Validated”. This means that although the certificate supports transaction encryption, the end user cannot confirm who is on the other end. So the transaction is encrypted for whom? 

Certificates verified using Organization validation (OV) or Extended validation (EV) practices contain the verified name of the entity that controls the web site. Certification Authorities issuing these certificates check with third parties to establish the official name of the organization and where they are located.  The CA takes further steps to contact the requesting organization to confirm that they did indeed request the certificate and that the requester is authorized to receive the certificate on behalf of the organization. When visiting a web site using an OV or an EV certificate, the end user can use the certificate to verify that they are sending their transaction data to the intended recipient.

At Entrust, 100% of our SSL certificates provide organization identity. All of our SSL certificates are intended to provide security, accountability, and trust.

Posted in EV SSL, Technical | Add Comment | No Comments »

SSL Security Silly Season

Thursday, July 8th, 2010 | Bruce Morton

You can tell that summer is here as the SSL security silly season is just warming up. This is the time of year when we start to get a preview of what will be presented at the annual Black Hat and DEF CON conferences.  The season was in full swing when at a recent Black Hat Preview Webcast, noted security expert Ivan Ristic of Qualys, was quoted as stating “we have about 22 million SSL servers with certificates that are completely invalid because they do not match the domain name on which they reside.”

This bold statement and has alarmed many in the internet security community. Security provider Comodo got so excited, they issued a press release urging Mr. Ristic to “review these figures before publishing or presenting this to an informed audience.”  In his blog post, Mr. Ristic refuted the alleged quotes and stated “they’ve generally focused on the wrong aspect of the study and that, in fact, I made no such sensational claims.” He went on to clarify as follows:

The important number is the 720,000 certificates whose names do match the domain names on which they reside. For each of those, someone made an effort to match the names, and those are the servers that are worth investigating further.

Sadly, some people chose to focus on the numbers that help make an interesting headline, but which aren’t very interesting from the research point of view. The reason we have so many domain names that do not have proper SSL certificates installed is that most of them are not _intended_ to have them. Multiple domain names will point to the same IP address and, thus, to the same SSL server. (Remember, virtual SSL hosting is not yet mainstream.) The difference in numbers is because of the widespread use of virtual web hosting, which is available for non-SSL sites, but not yet for SSL sites. You can host a million plain-text web sites on a single IP address, but if you want a million secure sites, you’d need a million IP addresses.

We in the SSL industry are getting used to the Black Hat and DEF CON excitement at this time of year.  The last two years have provided SSL security “revelations” from respected researchers Dan Kaminsky, Michael Zusman, and Moxie Marlinspike. This year should be no exception with talks from Ivan Ristic at Black Hat 2010 and from Peter Eckersley at DEF CON 18.

At Entrust, we look forward to the silly season.  The security experts draw their line in the sand, throw down the gauntlet, and we as security providers must review and respond.  It keeps us sharp.  Its healthy.  As such, we’ll keep an eye on the goings on at Black Hat and DEF CON and will respond accordingly.

Tags: ,
Posted in Technical | Add Comment | No Comments »

What’s the deal with 2048-bit keys?

Wednesday, June 23rd, 2010 | Bruce Morton

Entrust has been getting a lot of questions about the move to 2048-bit RSA keys.  The move is causing some web administrators concern, so we thought it would be a good time to clarify the reasoning behind the move to 2048-bit keys.

The US National Institute of Standards and Technology (NIST) prepared a special report SP 800-57 in 2005 for comment.  The updated report SP 800-57 in March 2007 Part 1 and subsequent reports Part 2 and Part 3, laid the foundation for how application developers and certification authorities would manage key sizes for digital certificates such as those used for SSL/TLS, code signing, and document signing. The recommendation was that 1024-bit RSA keys should only be depended on until 31 December 2010, after which the minimum key size should be 2048-bit RSA.  This recommendation has been adopted and published by a number of organizations:

Adobe CDS Certificate Policy

  • CDS Subordinate CAs shall use an RSA key pair with at least 2048 bits.
  • CDS Subscriber certificates shall use an RSA key pair with at least 2048 bits.

CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates

  • Requires a minimum of 2048-bit RSA keys for Root and Subordinate CAs.
  • Requires a minimum of 1024-bit RSA keys for end entity certificates and 2048-bit keys for end entity certificates that expire after 31 December 2010.

Microsoft Certificate Root Program

  • All new Root certificates must have a minimum be 2048-bit RSA keys.
  • 1024-bit Roots will be removed from the Microsoft Root Certificate Program by 31 December 2010.
  • All end entity certificates issued after 31 December must have a minimum of 2048-bit RSA keys.

Mozilla Foundation dates for phasing out MD5-based signatures and 1024-bit moduli

  • December 31, 2010 – CAs must stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs must stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root.
  • December 31, 2013 – Mozilla will disable or remove all root certificates with RSA key sizes smaller than 2048 bits.

The reason for moving to stronger subscriber keys is to protect the data of Subscribers and Relying Parties.  Cryptanalytic attacks against a particular key size become more practical as computing power increases and new techniques are developed.  See, for instance, 768-bit RSA key in December 2009.  A broken end-entity key could expose encrypted session data or allow a man-in-the-middle attack.

Entrust has been proactive in adopting the standards and recommendations. Entrust has put in restrictions that all certificates that expire after 2010 have a minimum of 2048-bit RSA keys. In addition Entrust is actively moving to 2048-bit root certificates. As times move forward, we will keep our eyes on the technology and the standards and implement policy to protect our subscribers and relying parties.

Tags: , ,
Posted in Technical | Add Comment | No Comments »

Getting really technical: The first 220 milliseconds of SSL

Friday, December 11th, 2009 | Steve Duncan

Anybody want a really technical description of what happens when an SSL session starts?  With the help of some network tools and a special version of Firefox, Jeff Moser details exactly what happens to change the address bar color and put a lock in the corner.  It’s not as simple as you might think.  Check out Jeff’s article here

Tags:
Posted in Technical | Add Comment | No Comments »