PKI Consortium blog

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.

Chrome to Show HTTP Sites as Not Secure
September 15, 2016 by Bruce Morton (Entrust) Chrome Google HSTS SSL/TLS Vulnerability

Always-On SSL should be deployed to prevent the “Not secure” warning

Website owners who do not secure their website with an SSL/TLS certificate will have to rethink their online strategy.  In a push to make the Internet safer for all users, Google will soon be issuing a stronger warning to visitors who navigate to a website that does not have the protection of an SSL/TLS certificate.

SSL 2.0 and DROWN
April 4, 2016 by Bruce Morton (Entrust) Attack IETF OpenSSL SSL 3.0 SSL/TLS Vulnerability

A team of researchers has announced a vulnerability with SSL 2.0 called Decrypting RSA with Obsolete and Weakened eNcryption; otherwise known as DROWN.

SSL 2.0 is a version of the SSL/TLS security protocols. It was released in February 1995, but due to security flaws was superseded by SSL 3.0 in 1996.

DROWN is a cross-protocol attack where the bugs in SSL 2.0 can be used to attack the security of connections that use TLS. The vulnerability applies to servers:

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.

Moving to Always on HTTPS, Part 1 of 2; Marking HTTP as Unsecure
February 3, 2016 by Ben Wilson Chrome Firefox Google HSTS Malware Mixed Content Mozilla SSL/TLS Vulnerability

Over the past several years there has been increased discussion about deprecating HTTP and making HTTPS the default protocol for the World Wide Web.  (HTTP stands for “HyperText Transfer Protocol” and the “S” in HTTPS is enabled with an SSL/TLS digital certificate properly installed and configured on a web server.)  These discussions have taken place in the context of browser security indications and technical improvements simplifying the global movement to “Always on HTTPS.”   Part 1 of this two-part blog post will address browser security indicators, while Part 2 discusses technical developments to make HTTPS the default protocol when browsing the web.

What Will Happen With SHA-1 and Browser Users on January 1st, 2016?
January 5, 2016 by Bruce Morton (Entrust) Android Apple Chrome Firefox Google Mozilla SSL/TLS Vulnerability

On January 1, 2016, the public trust certification authorities (CAs) will stop issuing SHA-1 signed SSL/TLS certificates. What will happen?

Will all websites using SHA-1 fail? No. SHA-1 will be supported by browsers and operating systems through 2016. Microsoft and Mozilla have announced that Windows and Firefox will not support SHA-1 in 2017, but no change for 2016. We expect Apple to follow the same protocol.

What about Chrome? Chrome will still provide warning indications in the browser status bar for SHA-1 signed certificates which expire in 2016 and in 2017 or later. No change.

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.

OpenSSL High Severity Vulnerability
July 10, 2015 by Bruce Morton (Entrust) Attack DTLS Google MITM OpenSSL SSL/TLS Vulnerability

OpenSSL has announced a high severity vulnerability, CVE-2015-1793 which will require an upgrade to some OpenSSL installations.

The vulnerability was discovered by Google personnel Adam Langley and David Benjamin on June 24, 2015. Google has been working on an alternative to OpenSSL called BoringSSL. This has allowed Google to reduce vulnerabilities in their installations, but is also a benefit to OpenSSL as issues have been reported. Note that BoringSSL is not impacted.

The Insecurity of Mobile Applications
June 11, 2015 by Rick Andrews Android Attack MITM OpenSSL SSL/TLS Vulnerability

Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see these studies). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three (#3) in its top 10 list of mobile security problems of 2014. Apps that don’t use SSL/TLS are particularly vulnerable, given the ease of reading and modifying unsecured traffic at Wi-Fi hot spots, for example. But even apps that use SSL/TLS must be careful to implement proper checking to ensure that attackers can’t exploit weaknesses.

Practical Steps to Counter the Logjam Attack
May 26, 2015 by Kirk Hall (Entrust) Apple Attack Encryption Google MITM SSL/TLS Vulnerability

Another flaw has been found in the basic encryption algorithms that secure the Internet. This flaw, named the Logjam attack by its discoverers (researchers from various universities and companies), allows an attacker that can carry out man-in-the-middle (MitM) attacks to weaken the encryption used in secure connections (such as HTTPS, SSH, and VPNs). In theory, this means that an attacker (with sufficient resources) can break the encryption and read the “secure” traffic.