PKI Consortium blog

2017 – Looking Back, Moving Forward
January 13, 2017 by Bruce Morton (Entrust) 3DES Apple Attack CA/Browser Forum CAA Chrome Code Signing Encryption Firefox Google Identity Malware MITM Policy Revocation RSA SSL 3.0 SSL/TLS TLS 1.3 TSA Vulnerability

Looking Back at 2016

Fortunately, 2016 was not a year full of SSL/TLS vulnerabilities. Although some researchers did prove old cryptography algorithms should be put out to pasture. The year showed the end of public-trusted SHA-1 SSL/TLS certificates. It also showed more transparency should be considered due to issues discovered with a few certification authorities (CAs). The great news is HTTPS is no longer the minority — after 20 years, connections using HTTPS has surpassed HTTP.

Google Certificate Transparency (CT) to Expand to All Certificates Types
November 8, 2016 by Jeremy Rowley Announcement CA/Browser Forum Chrome DV EV Google IETF OV Policy SSL/TLS

The policy change goes into effect October 2017

A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser.

Why Is Certificate Expiration Necessary?
October 19, 2016 by Bruce Morton (Entrust) Attack CA/Browser Forum EV Hash Function Identity OCSP Policy RSA SSL/TLS Vulnerability

The Long Life Certificate – Why It Doesn’t Exist

Why is certificate expiration even necessary? Wouldn’t it be better if I could just buy a certificate with a long life before expiration? It would really simplify certificate management if it could be installed and forgotten. Simple, no management required, just file-and-forget.

Always-On SSL
September 30, 2016 by Rick Andrews, Ben Wilson Encryption Firefox Google Identity Microsoft Mixed Content OpenSSL Policy Qualified 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.

TLS Certificates on the Web – The Good, The Bad and The Ugly
May 17, 2016 by Rick Andrews CA/Browser Forum Code Signing ECC Encryption EV Hash Function PKI Policy RSA SSL/TLS

It might be hard to believe, but the SSL/TLS Ecosystem is nearly 20 years old. It’s time to take stock and see how we’re doing with regards to TLS certificates. In this article, we’ll primarily discuss certificates themselves and not web server configuration, although that is often a source of problems.

In the last few years, we’ve endured three major certificate-based migrations:

• Away from the MD2 and MD5 hash algorithms to SHA-1
• Away from small RSA keys to 2048-bit keys or larger
• Away from the SHA-1 hash algorithm to SHA-256

What’s driving these migrations? Primarily, it’s the relentless march of attacks. As Bruce Schneier says, “Attacks always get better; they never get worse.” To stay ahead of these attacks, Certification Authorities and browser vendors joined together several years ago to form the CA/Browser Forum, and published several requirements documents: the Baseline Requirements, the EV SSL Guidelines and the EV Code Signing Requirements.

Moving to Always on HTTPS, Part 2 of 2; Upgrading to HTTP Strict Transport Security
February 18, 2016 by Ben Wilson HSTS Mixed Content Policy SSL/TLS Vulnerability W3C

Part 1 of this blog post discussed browser security indicators and how to avoid getting warnings about mixed content on your website.  (Mixed content leaves a door open that allows an attacker to snoop or inject malicious content during the browsing session.)  This Part 2 discusses other technical measures to implement Always on HTTPS.  As I noted previously, one of the difficulties with implementing Always on HTTPS is that content is often provided by third parties.  I suggested that you require HTTPS from them as well. However, until you are able to get them to do this you will need to find another way to serve up content via HTTPS.  One approach is to collect the material locally and serve it up from the same origin – your HTTPS server.

2016 – Looking Back, Moving Forward
December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2015

A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks.  MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements.  This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.

Fighting the Good Fight for Online Trust
April 2, 2015 by CA Security Council Apple CAA CASC Google HSM Mis-issued MITM Mozilla Policy Root Program SSL/TLS WebTrust

Once again Browsers and Certificate Authorities are in the news over the reported mis-issuance of an SSL server certificate to a google.com domain. Discovered by Google most likely via technology known as key pinning and discussed by Google’s Adam Langley in this blog, a Chinese certificate authority, CNNIC (Chinese Internet Network Information Center), apparently issued an intermediate certificate to an Egyptian company called MCS Holdings. Because the CNNIC root certificate is included in the root store of most major browsers, users would not see any warnings on sites that have certificates issued by CNNIC or MCS Holdings. When MCS installed their intermediate into a Man in the Middle (MITM) proxy device, that device could then issue certificates for sites which users connected to that proxy would visit. (MITM is described in more detail in our previous blog here: https://casecurity.org/2015/01/08/gogo-found-spoofing-google-ssl-certificates/)

SSL Certificate Validity Periods Limited to 39 Months Starting in April
February 19, 2015 by Jeremy Rowley CA/Browser Forum ETSI Policy SSL/TLS Vulnerability WebTrust

In accordance with the CA/Browser Forum Baseline Requirements, effective April 1, 2015, Certificate Authorities (CAs) will no longer be able to issue SSL Certificates with a validity period longer than 39 months.

Shortening the validity period to 39 months is the result of much consideration within the CA/Browser Forum to arrive at a duration that allows optimal usability while maintaining the tightest network security. A shortened validity period will significantly improve Internet security by requiring administrators to renew and verify their certificates more often. It will also make it easier for users to keep up-to-date on new advances in security and remain aware of their control over private keys.

2015 – Looking Back, Moving Forward
January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2014

End of 1024-Bit Security

In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030.