PKI Consortium blog

It’s Time for TLS 1.2
September 19, 2013 by Wayne Thayer Attack BEAST Chrome Firefox OCSP RC4 SHA2 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.2 Vulnerability

In a previous post titled Getting the Most Out of SSL Part 2, we touched on the recommendation that Web servers be configured to prefer Transport Layer Security (TLS) version 1.2. With the planned release of Firefox 24 and recent release of Chrome 29 adding support for TLS 1.2, now is a great time for website administrators to make the switch.

Transport Layer Security was formerly called Secure Sockets Layer (SSL) and is the protocol that enables secure “https://” connections to websites. TLS 1.2 was defined 5 years ago in RFC 5246, and TLS 1.1 dates all the way back to RFC 4346 in 2006. Both of these versions are updates to the original standard that fix bugs and problems including vulnerability to cipher block chaining (CBC) such as the BEAST attack that made news in 2011. The authors also added newer cipher suites including a replacement for RC4, a popular cipher that has been shown to be susceptible to attack. In short, enabling TLS 1.2 is like a Windows software update – it fixes potential problems and makes your website more secure.

What Is Certificate Transparency and How Does It Propose to Address Certificate Mis-Issuance?
September 9, 2013 by CA Security Council Attack Mis-issued OCSP Revocation SSL/TLS TSA

As originally architected by Netscape and others in the mid-1990s, the certificate issuance process envisioned that the CA would present the certificate and its contents to the named subject who would review and accept the certificate first. Then the CA would publish the certificate to a repository. That process would establish that the certificate’s subject was aware of certificate issuance. (Otherwise, an unscrupulous CA could sign a subscriber’s public key and create a certificate for the subscriber without its knowledge.) The repository was also an independent means of obtaining and verifying the public key prior to initiating secure, authenticated communication without having to obtain it solely from the server during session negotiation.

An Introduction to OCSP Multi-Stapling
May 7, 2013 by CA Security Council CA/Browser Forum CRL IETF OCSP Revocation SSL/TLS Vulnerability

OCSP Stapling

OCSP is a protocol used to check the validity of certificates to make sure they have not been revoked. OCSP is an alternative to Certificate Revocation Lists (CRLs). Since OCSP responses can be as small as a few hundred bytes, OCSP is particularly useful when the issuing CA has relatively big CRLs, as well as when the client has limited memory and processing power.

Self-Signed Certificates Don’t Deliver Trust
April 2, 2013 by Bruce Morton (Entrust) CRL DV EV NIST OCSP Policy SSL/TLS

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

• Owner says who they are
• Owner issues on their own policy
• Owner is responsible for quality
• Owner may not follow industry guidelines
• Owner may not provide certificate status
• Compromised certificates may not be able to be revoked
• Owner is not audited
• Issuer of certificate may not be authorized by the domain owner
• Certificates may not be renewed if there are no reminders
• Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-Trusted CA-Signed Certificate Model

• CA verifies the owner of the domain and the certificate applicant
• CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
• CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
• CA updates policy based on industry best practices
• CA provides certificate status through CRL and OCSP
• Compromised certificates can be revoked
• CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
• Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
• CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
• Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.

IETF 86 – Web PKI Working Group
March 21, 2013 by Bruce Morton (Entrust) CRL Google IETF OCSP PKI Policy Revocation SSL/TLS Web PKI

At the IETF 86 meeting in Orlando last week, there was a working group meeting discussing the operations of the Web PKI. At the previous IETF 85 meeting a birds-of-a-feather was held to discuss the purpose of having such a group. The result of the meeting was an established group with the charter that states purposes such as:

• Working group will work to improve the consistency of Web security behavior
• Address problems as seen by the end-users, certificate holders and CAs
• Describe how the Web PKI actually works
• Prepare documented deliverables as discussed below

The meeting discussed the charter and the four following deliverables. More information is in the presentation slides; look under the Operations and Management Area, then under WPKOPS.

The Importance of Revocation Checking Part 2: A Real World Example
March 11, 2013 by Wayne Thayer Attack Code Signing CRL Encryption Identity Malware OCSP Revocation SSL/TLS

Just last week, a new security incident related to certificate revocation checking made headlines. It was discovered that a legitimate website was hosting a malicious Java application that installed malware on the computers of people who visited the site. This comes after recent updates that introduced Security Level settings in Java, and then raised the default from Medium to High. At the high level, users are shown a warning before any unsigned Java code is executed. Unfortunately, this recent incident exposed a method that allows an attacker to bypass the warning.

The Importance of Checking for Certificate Revocation
March 9, 2013 by Rick Andrews Attack CRL Identity Malware MITM OCSP Revocation SSL/TLS

Certificates are typically valid for one to three years, and during that time it’s possible that the web site owner or the CA realizes that end users should not trust the certificate. There are several cases in which this might happen, including these:

• The web site owner ceases doing business, no longer owns the domain name used in the certificate, has changed their organization name, or wishes to shut down the web server.
• The subscriber learns that an unauthorized party has gained access to the private key associated with the public key in the certificate.
• The CA learns that errors were made in authentication, the subscriber misrepresented some material info used in the authentication process, or the subscriber has violated the terms of its agreement with the CA.

When the subscriber or CA makes the decision to revoke a certificate, that decision must be conveyed to end users who encounter the certificate in use. There are two different methods for this:

OCSP Stapling: Improved Performance and Security, a Win-Win
February 14, 2013 by Jeremy Rowley CASC OCSP Revocation SSL/TLS

The launch of the CASC has given its members a unique platform through which we can educate users about online security and the best practices in utilizing SSL. That’s why we’ve decided to pair the group’s launch with a focused effort on OCSP stapling.

Why OCSP stapling? For one, stapling is already supported by IIS and the newest versions of Apache and nginx. Although server software does not enable OCSP by default, servers can be re-configured with a little education. OCSP stapling is a significant improvement on traditional CRLs and OCSP revocation mechanisms because it eliminates the communication between the browser and CA when establishing the SSL connection. This leads to an increase in browsing performance and eliminates an attacker’s ability to successfully block a CA’s ability to provide revocation information. Stapled OCSP responses are cached by the web administrator and sent back to the relying party during the communication, effectively reducing bandwidth requirements and speeding up the SSL connection.

Certificate Revocation and OCSP Stapling
February 14, 2013 by CA Security Council Attack CASC CRL IETF OCSP Revocation SSL/TLS

Revocation

As a body of global CAs, the CA Security Council is committed to educating server administrators, end-users and other interested parties about SSL enhancements and best practices that can better protect everyone. An important initiative that can make a practical difference right now is addressing easily implemented improvements to certificate status services that handle revocation of invalid or expired certificates, specifically the implementation of OCSP stapling.

World’s Leading Certificate Authorities Come Together to Advance Internet Security and the Trusted SSL Ecosystem
February 14, 2013 by CA Security Council CA/Browser Forum CASC CRL OCSP Revocation SSL/TLS

San Francisco, CA. – February 14, 2013 – Leading global certificate authorities announced the creation of the Certificate Authority Security Council (CASC), an advocacy group, committed to the exploration and promotion of best practices that advance the security of websites and online transactions. Through public education, collaboration, and advocacy, the CASC strives to improve understanding of critical policies and their potential impact on the internet infrastructure. Members of the CASC include Comodo, DigiCert, Entrust, GlobalSign, Go Daddy, Symantec, and Trend Micro.