Posts Tagged ‘SSL’

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 »

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 »

EV, what’s the difference?

Wednesday, June 16th, 2010 | Bruce Morton

With the acquisition of the VeriSign SSL business by Symantec, we’re getting a lot of questions about EV SSL certificates.  Is your EV the same as theirs?  Why is your EV so much cheaper?  What’s the difference?

The bottom line is yes; our EV SSL certificates are the same as theirs.  In fact, EV SSL certificates from all certification authorities are the same.  This is because all EV SSL certificates are issued and managed in accordance with the same standard.  This standard is called the Guidelines For Issuance And Management Of Extended Validation Certificates (EV Guidelines). The EV Guidelines were developed by an industry group called the CA/Browser Forum (CAB Forum) which Entrust has chaired since 2005. 

In addition to following the same guidelines, all EV SSL certification authorities are audited by third party security auditors in accordance with criteria based on the guidelines. Proof of which is posted on the CA’s website in the form of a WebTrust for Extended Validation seal and auditor’s report.

So what’s the difference?  The difference is customer service.  Entrust provides the industry leading certificate management, combined with great customer service, and a choice of licensing models. We let our customers manage their certificates the way they want them managed … in accordance with the guidelines of course.

So why are our EV certificates so much cheaper?  Simply, we charge less. We deliver great value at a reasonable price.

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

Site Seals: Reasons to use them. Reasons not to.

Sunday, January 17th, 2010 | Steve Duncan

Every SSL vendor offers a site seal, a small graphic that can be displayed on the pages that offer SSL encryption.  But are they worthwhile displaying?  Here’s some reasons a website should consider using a site seal, and some reasons not:

Three good reasons to display a site seal:

  1. Just another trust indicator.  Savvy users know to look for the green colored address bar, the small lock, or the “https” at the beginning of a secure website address.  But does everyone know that?  A site seal may be the one thing that your customers look for as a symbol of trust.  In a perfect world users should be trained to look for all visual indicators of website security, but the reality is that you need to offer as many trust indicators as possible to keep customer confidence high.
  2. If there’s a look-up function.  Those savvy users know they can click on the green bar and the small lock in the browser.  Likewise those who look to a site seal for verification should know that if you click on it, a confirmation from the SSL vendor is shown from the SSL vendor’s website.
  3. Brand reinforcement. Displaying a site seal indicating security from a reputable vendor reinforces your own brand image.  You are essentially associating your brand with the brand you display.

So what are three reasons you wouldn’t want to use a site seal?

  1. Poor brand association.  The last thing you want to do is associate your company with one that doesn’t present the same positive brand identity.  You want to make sure you’re displaying a brand that doesn’t represent unprofessionalism, sexism, or values that you don’t want attributed to your brand.
  2. Just the graphic. A properly installed  SSL site seal lets users click on the graphic to get confirmation of the company and website.  If the site seal is just a graphic, it’s often a sign of a phishing site or an improperly installed seal.
  3. A Pseudo seal.  You don’t have to search the web too much to find questionable companies selling “site seals” that are nothing more than a graphic with little or no verification or security behind it.  Since consumers are becoming more educated that a true SSL site seal reinforces the other secure visual indicators, it stands to reason you’ll lose more customers than you’ll gain.

One can conclude that a site seal is a good way to reinforce your brand, enhance consumer confidence and decrease customer drop-outs.  But only if installed properly and from a reputable source.

You can find out more about Entrust’s site seal by visiting our FAQ here.

Tags: , ,
Posted in Site Seal | Add Comment | No Comments »