PKI Consortium blog

Always-On SSL, Part I
January 16, 2014 by Rick Andrews Encryption Google Identity Microsoft Mixed Content OpenSSL SSL/TLS

There is no doubt that content owners and publishers have a duty to encourage trust and the confidence during internet usage by adopting security best practices. If a customer believes that their data and identity are safe and protected, they are more inclined to continue their online transactions. Industry best practices for website protection should be vendor-neutral, easy to implement, and globally accessible. Websites should take all the reasonable steps possible to adopt best practices in secure design and implementation, and this includes using Always-On SSL across the entire website.

Intermediate CA Certificates and Their Potential For Misuse For Man-In-The-Middle Attacks
January 9, 2014 by Robin Alden (Sectigo) Attack Firefox Google MITM Policy Root Program SSL/TLS Vulnerability

We have seen recently that Google detected that publicly trusted TLS/(SSL) certificates had been created for Google domains without having been requested by Google themselves.

The existence of such certificates might usually be taken as an indication of misissuance by the issuing CA (i.e. a failure or mistake by the CA which allowed the issuance of an end-entity certificate otherwise than in accordance with their policy) or as an indication of compromise of the issuing CA.

2014 – Looking Back, Moving Forward
January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2

Looking Back at 2013

Protocol Attacks

The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4.

ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
December 18, 2013 by Jeremy Rowley Announcement CA/Browser Forum CASC ICANN MITM Mozilla PKI Policy Qualified Revocation SSL/TLS Vulnerability

After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .corp and .home reserved as high risk gTLDs. This post serves as an advisory for interested network administrator on how the newest ICANN decisions may affect their networks and certificates.

SHA-1 Deprecation, On to SHA-2
December 16, 2013 by Bruce Morton (Entrust) Code Signing Microsoft PKI Policy SHA1 SSL/TLS

We have previously reviewed implementation of SHA-2, but with Bruce Schneier stating the need to migrate away from SHA-1 and the SHA-1 deprecation policy from Microsoft, the industry must make more progress in 2014.

Web server administrators will have to make plans to move from SSL and code signing certificates signed with the SHA-1 hashing algorithm to certificates signed with SHA-2. This is the result of the new Microsoft Root Certificate Policy where Microsoft deprecates SHA-1 and imposes the following requirements:

Java Secures Supply Chains Through Code Signing
December 9, 2013 by Bruce Morton (Entrust), Erik Costlow (Oracle) Code Signing Identity PDF

We have recently discussed the benefits of code signing in two posts: Securing Software Distribution with Digital Signatures and Improving Code Signing. These posts covered the role of code signatures as a “digital shrinkwrap” designed to answer a simple question: Did the software I am about to run actually come from the author or has someone changed it along the way?

As software is downloaded, assembled, copied, distributed and redistributed, it can be modified at any point along the supply chain. Some modifications are designed to insert advertising into software, others add tracking capabilities, and others could be more nefarious, such as compromising the entire host or stealing data.

IETF 88 – Pervasive Surveillance
November 26, 2013 by Bruce Morton (Entrust) Attack CRL Encryption Forward Secrecy HSTS IETF PKI Revocation SSL/TLS Vulnerability Web PKI

Internet Surveillance

The big news at IETF 88 in Vancouver was the technical plenary on Hardening the Internet which discussed the issue of pervasive surveillance. Pervasive surveillance is a mass surveillance of an entire or a substantial fraction of a population. The surveillance is usually carried out by government, is not targeted and its occurrence may not be overt. It was noted that pervasive surveillance, of the kind revealed in the Snowden-sourced documents, constitutes a misguided and damaging attack on civic society in general and the Internet in particular.

How Organizations Are Authenticated for SSL Certificates
November 22, 2013 by Kirk Hall (Entrust) CA/Browser Forum CSR DV EV Identity OV Phishing Policy SSL/TLS

Certification Authorities (CAs) are trusted third parties that authenticate customers before issuing SSL certificates to secure their servers.

Exactly how do CAs authenticate these organizations? And where are the rules that determine what CAs must do during authentication?

The Rules on Customer Authentication

In the past, there were no common rules applicable to CAs as to minimum steps required to authenticate a customer before issuing an SSL certificate. Instead, each CA was permitted to create its own authentication processes, and was only required to describe the process in general terms in its public Certification Practice Statement (CPS). In many cases, the CPS authentication description was vague and hard to understand, and some CAs were less diligent than others during authentication.

Improving Code Signing
November 14, 2013 by Jeremy Rowley CA/Browser Forum Code Signing Identity Malware SSL/TLS

Previously, we discussed how code signing certificates play a key role in the trust framework by proving the authenticity of software. As mentioned, code signing certificates act as a certification that the software was unmodified after publication. Although current code signing practices greatly reduce the threats of malware and adware embedded in signed objects, the sophistication of threats has risen and there is a need for improvement. When code signing was new, skilled criminal hackers were the exception and script kiddies were the norm. Now, the skill level and sophistication of criminal networks, and even nation states, have advanced to the point where customized malware is being used to penetrate company networks, steal valuable information, and even tamper with sensitive infrastructure.

Certificate Chains, Key Management and the Number of CAs Counted by Web Crawlers – Oh My
November 4, 2013 by Ryan Hurst CRL Microsoft OCSP PKI Policy Revocation SSL/TLS

Have you ever wondered why your web server certificate has a “chain” of other certificates associated with it?

The main reason is so that browsers can tell if your certificate was issued by an organization that has been verified to meet the security, policy and operational practices that all Publicly Trusted Certificate Authorities are mandated to meet. That certificate at the top of the chain is commonly called the “root.” It’s signature on a certificate below it indicates that the organization operating the root believes that practices of the CA below it meets that same high bar.