Posts Tagged ‘Technical’

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 »

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 »

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 »