Archive for the ‘Technical’ Category

« Older Entries

TURKTRUST Unauthorized CA Certificates

Friday, January 4th, 2013 | Bruce Morton

Although unrelated to Entrust, I thought you might be interested in the news about TURKTRUST.

It has been reported that the TURKTRUST certification authority (CA) inadvertently issued two intermediate CA certificates in August 2011. The certificates were issued in error due to test code being moved into production. The certificates issued were for “*.EGO.GOV.TR” and “e-islem.kktcmerkezbankasi.org.”

According to TURKTRUST, on December 6, 2012, the “*.EGO.GOV.TR” intermediate CA certificate was moved to a Check Point firewall, which was configured for inspection. In this mode, the Check Point firewall automatically generates certificates for all SSL connections. In this case, it issued a “*.google.com” certificate. TURKTRUST stated that the certificate was not issued for dishonest purposes.

It is not acceptable, but mistakes do happen. In this case, the mistake was again detected by Chrome’s public key pinning, which indicated that a fraudulent Google certificate had been issued.

Most of the browsers (Google Chrome, Microsoft IE and Mozilla Firefox) took corrective action and blacklisted the inadvertent intermediate CA certificates.

What else can be done? Here are some ideas:

Limit CA Functionality – If a CA is not supposed to issue CA certificates, then disable this functionality. If the CA is only supposed to issue SSL certificates, then disable the functionality for Code Signing and S/MIME. Limited functionality will limit the risk.

Automated Certificate Inspection – All certificates that have been issued should be inspected to meet certain criteria. All issued certificates could be inspected for minimum key size, signing algorithm, CRL CDP, OCSP AIA and basic constraints criteria. If the basic constraints indicates “Subject,” then an investigation should be performed to ensure that the CA certificate issuance was authorized.

Audit – Both internal and external audits could be performed to manually inspect issued certificates. If a CA certificates is found, then an investigation should be performed to ensure it was authorized.

Certificate Transparency – We can help domain owners check for fraudulent website certificate issuance. This could be done with the further development and deployment of Certificate Transparency (CT). CT will make it possible for domain owners to inspect logs to see if any certificates were issued for one of their domains.

Updated January 7, 2013: TURKTRUST has provided an announcement and technical details.

Tags: , , , ,
Posted in Certificate Management, SSL Deployment, Technical | Add Comment | No Comments »

SHA-3

Tuesday, October 9th, 2012 | Bruce Morton

On October 2, 2012, the National Institute of Standards and Technology (NIST) announced that the winner of the new SHA-3 hash function competition was Keccak. The plan is SHA-3 will eventually replace SHA-1 and the SHA-2 hash families.

To support digital certificates, the hashing function is used by the certification authority (CA) to put its signature on the certificates and CRLs. The signature needs to be strong enough so it cannot be replicated or predicted.

Bruce Schneier, a security guru, was a in the SHA-3 competition. Schneier states there is no need to rush to implement SHA-3; to date, SHA-256 (a SHA-2 variant) is still looking good. Upon the announcement of the winner, he stated Keccak is a fine hash function, but so are the four variants of SHA-2. He will take some time before making specific recommendations on when to move to SHA-3.

The SSL certificate industry still has CAs that are removing MD5-signed certificates. The industry is slowly implementing SHA-2, but most certificates are signed with SHA-1 due to backwards compatibility issues with browsers and other applications.

I think the next step will be for NIST to develop a schedule as to when SHA-3 should be used. We will then see how well the software industry supports SHA-3.

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

Adobe Code-Signing Certificate Compromised

Wednesday, October 3rd, 2012 | Bruce Morton

Adobe announced they received two malicious utilities signed by a valid Adobe code-signing certificate. The code-signing certificate was compromised though an attack on their code-signing system.

The code-signing certificate will be revoked on October 4, 2012, and will impact all code being signed after July 12, 2012. A supporting security advisory has been issued.

The compromise of the code-signing certificate does not impact Adobe Certified Document Services (CDS) or any root certificate in the CDS system. As such, there is no impact to customers who have purchased CDS signing certificates.

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

Short-Lived Certificates

Tuesday, August 21st, 2012 | Bruce Morton

Certificate revocation is a current SSL industry issue. There are many causes to the problem. Some end-users do not have certificate-revocation checking turned on. Browsers support CRL or OCSP, but in some cases not both. The certification authorities (CA) may not provide reliable revocation responses. And what if there are no revocation responses from a CA; should there be a hard or soft fail?

One result is the CA/Browser Forum is looking into revocation to see what can be done to improve the situation. Another result is that the short-lived certificates are now being discussed.

A short-lived certificate is issued for a limited validity period, say seven days instead of one year. The certificate is re-issued every few days, so that the subscriber can update the certificate on their server on a continuous basis. The technical difference is that the short-lived certificate would not have any information about where revocation data can be found. If there is a breach that requires certificate revocation, then the CA would just stop re-issuing the certificate.

Revocation would be complete within the validity period of the last certificate issued. In this case, the period would be seven days, which is also the same validity period of a typical CRL or OCSP response. The result is 100 per cent revocation, as all browsers provide a trust dialogue on expired certificates.

A study has been prepared by a group of Stanford and Carnegie Mellon University researchers. Their conclusion was short-lived certificate complement the CRL by adding security when software updates do not make sense (e.g. mobile platforms), rebalances power between browsers and CAs and removes Google as a single point of failure. In the case where a CRL is not supported, short-lived certificates provides the security guarantees equivalent or better than OCSP. Short-lived certificates are fully backwards compatible, incrementally deployable, impose no performance penalty, and add another layer of protection to Web users.

The study authors reference Google and Chrome, as Google has declared that Chrome will not use CA provided revocation information.

Is this the answer for everyone? No, primarily it’s a solution for highly technical certificate subscribers with a high-value Web domain that can update their certificates on a continuous basis. It is unlikely that this solution will be implemented by smaller users until Web servers support methods to continuously update the SSL certificates or until Web-hosting providers support the solution.

You don’t have to worry about short-lived certificates yet. The CA/Browser Forum Baseline Requirements specifies that SSL certificates support CRL and OCSP. If the concept is accepted, I’m sure there will be a proposal to update the requirements to allow short-lived certificates.

Tags: , , , , , ,
Posted in Secure Browsing, Technical | Add Comment | 2 Comments »

SSL Certificate Baseline Requirements 1.0

Wednesday, December 14th, 2011 | Bruce Morton

The CA/Browser Forum has completed release 1.0 of the Baseline Requirements for the Issuance and Management of Publicly Trusted (SSL) Certificates. This document, fondly referred to as the BRs, is a major step forward for the SSL certificate industry. The leading browser vendors and the SSL CAs have come together to set a minimum standard for the issuance of SSL certificates. It will act as the benchmark for all SSL certificate issuance moving forward, once it becomes effective on July 1, 2012.

Prior to the BRs, there was no common standard for the issuance of SSL certificates. Microsoft and Mozilla have their stated requirements and policies that must be considered. The AICPA/CICA has WebTrust for CA and, of course, there are “industry best practices.” Industry best practices? Try to find those; well, now you can. The BRs have considered the browser policy requirements and have been reviewed by the WebTrust auditor community.

Over the years, security researchers and hackers have found cracks in SSL certificate issuance practices. Mike Zusman defeated the common practice of using email addresses to confirm domain control in the issuance of Domain Validated (DV) certificates. The ComodoHacker issued fraudulent certificates by attacking third-party registration authorities. Most recently, due to a spear-phishing attack, some SSL CAs were found to be issuing certificates with weak 512-bit keys. All of these short-comings have either been addressed directly or mitigated in the BRs.

The CAB/Forum acknowledges that the BRs are not a panacea for all SSL certificate issues. Nonetheless, the BRs establish a baseline from which more improvements can be made.

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

Code Signing

Friday, June 17th, 2011 | Bruce Morton

Although this is the Entrust Insight SSL Blog, Entrust Certificate Services issues other types of certificates such as Code Signing, Adobe CDS and Client S/MIME. The purpose of this post is to kick off a series on Code Signing. When the series is completed, this post can be used as an index to all other related posts.

Here is what we plan to cover:

  1. Why Code Sign?
  2. What is Code Signing?
  3. Verifying Code Authenticity
  4. How to Digitally Code Sign
  5. Code Installation Trust Decision
  6. What is Time-Stamping?
  7. Self-Signed Versus Trusted CA Certificates
  8. Code Signing: Best Practices
  9. Application Reputation

The above list may change as the articles are written. Reader feedback would be greatly appreciated to help refine the topics.

Entrust offers Code Signing certificates to sign and certify the following:

  • Authenticode (most Microsoft® Windows® platforms)
  • Java
  • Microsoft® Office® macros and Visual Basic script

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

Public Key Pinning

Thursday, May 26th, 2011 | Bruce Morton

In the wake of the Comodo attack, the Internet industry is looking for ways to mitigate similar attacks in the future. Public key pinning may prove to be effective.

Google has developed the public key pinning concept that will debut in Chrome version 13 for most Google Internet properties (e.g., https://www.google.com).

Public key pinning means that a certification authority public key will be white-listed in the browser for a specific domain or set of domains. The white-listed public key is referred to as an HTTPS pin. If the pin is not present when browsing a protected website, then an error will occur in the browser and the requested page will not be presented.

The idea is that Google knows who it has authorized to issue its SSL certificates. If a certificate is found to be issued by another CA – even a legitimate publicly trusted CA - then the certificate will not be trusted. The result is that an unsuspecting browsing party will not be compromised with the help of a fraudulent SSL certificate.

Potential incompatibility issues with corporate man-in-the-middle (MITM) proxies, parental controls and debugging tools have been addressed by allowing user-installed CA certificates to override the pins.

Google appears to be open to offering pinning to other large, high-security websites. For others, the expectation is that pinning will be available through HTTP Strict Transport Security (HSTS). We’ll have to wait and see if other browsers will support Public Key Pinning as well.

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

SSL False Start Performance Results

Thursday, May 19th, 2011 | Bruce Morton

As a follow-up to ‘Google is speeding up SSL’, Google has reported very favorable SSL False Start performance results. In summary, False Start reduces the latency of a SSL handshake by 30 percent. In addition, Google has implemented False Start into Chrome so that it is basically 100 percent backwards-compatible.

Google Chrome is the only browser implemented with False Start. The results are encouraging enough that hopefully more browsers will consider this approach as well.

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

Is it SSL, TLS or HTTPS?

Thursday, May 12th, 2011 | Bruce Morton

Throughout this blog I appear to use (or misuse) the terms SSL, TLS and HTTPS interchangeably. From time to time I catch myself and say, “Which one should I be using?” Frankly, my default is to use SSL. When I reference an article or site, I do tend to side with the term it prefers. So what’s the difference?

Secure Sockets Layer (SSL) is a cryptographic protocol that enables secure communications over the Internet. SSL was originally developed by Netscape and released as SSL 2.0 in 1995. A much improved SSL 3.0 was released in 1996. Current browsers do not support SSL 2.0.

Transport Layer Security (TLS) is the successor to SSL. TLS 1.0 was defined in RFC 2246 in January 1999. The differences between TLS 1.0 and SSL 3.0 were significant enough that they did not interoperate. TLS 1.0 did allow the ability to downgrade the connection to SSL 3.0. TLS 1.1 (RFC 4346, April 2006) and TLS 1.2 (RFC 5246, August 2008) are the later editions in the TLS family. Current browsers support TLS 1.0 by default and may optionally support TLS 1.1 and 1.2.

Hypertext Transfer Protocol Secure (HTTPS), or “HTTP Secure,” is an application-specific implementation that is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS. HTTPS is used to provide encrypted communication with and secure identification of a Web server.

In addition to HTTPS, SSL/TLS can be used to secure other application-specific protocols such as FTP, SMTP, NNTP and XMPP.

What terminology should we use? Since TLS has succeeded SSL, logic dictates that we should be using the term TLS instead of SSL. However, SSL is by far most common on the Internet, so SSL will continue to be my default acronym of choice when making non-application specific references. From time to time, I will use SSL/TLS. When talking about HTTPS, I may use SSL, SSL/TLS or HTTPS, who knows?

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

Elliptic Curve Cryptograph (ECC) Demo

Friday, April 22nd, 2011 | Bruce Morton

Elliptic curve cryptography (ECC) for use on the Internet is gaining more support and interoperability amongst application developers. Entrust is proud to announce that ECC-based digital certificates are now supported by the full suite of Entrust Authority solutions.

The promise of ECC is greater security for a given key length. This allows implementations to use smaller keys for equivalent security which saves computation time, memory and power. This can be very attractive for deploying security in constrained environments such as PDAs and smartphones. So attractive that BlackBerry mobile device maker Research In Motion (RIM) acquired Certicom, the leader in ECC technology, in 2009. RIM and Certicom will host their annual ECC Conference in June in Toronto.

As the need to move off of 1024-bit RSA keys intensifies, more companies may turn to ECC. Switching from 1024- to 2048-bit RSA (RSA-2048) results in signing operations that take up to six times longer. In many instances, a performance penalty of this magnitude may simply be unacceptable.

One alternative that can offer better performance and equivalent security is ECC. For example, a 224-bit prime modulus elliptic curve key (EC-P-224) and a RSA-2048 key both offer 112-bits of security; however, tests in Entrust labs indicate a signing operation using EC-P-224 can be as much as 35 times faster than a signing operation with RSA-2048.

It will take some time before ECC certificates are widely available on the Internet. In the meantime, Entrust is offering free ECC demonstration certificates to assist in your ECC solution development, interoperability testing and rollout plans.

Entrust also has plans for publicly trusted ECC SSL certificates. Stay tuned. More on that in a later post.

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

« Older Entries