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. Imagine, I’ve been in business, starting say 10 to 15 years ago. I roll out my web pages and secure them with a 20-year-validity SSL certificate.

How a SWEET32 Birthday Attack is Deployed and How to Prevent It
September 7, 2016 by Bruce Morton (Entrust) 3DES Attack Encryption RC4 SSH SSL/TLS TLS 1.0
Details surrounding the SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN can be found in the paper released by Karthikeyan Bhargavan and Gaëtan Leurent from INRIA in France. The paper shows that cipher suites using 64-bit block length ciphers are vulnerable to plaintext recovery attacks. As such, Triple-DES (3DES) and Blowfish are vulnerable. Here’s an overview. Vulnerabilities to a SWEET32 Birthday Attack Certain scenarios are pre-disposed to a SWEET32 Birthday attack.

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.

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.

Server Name Indication and Fewer IP Addresses
June 2, 2015 by Bruce Morton (Entrust) Attack Chrome MITM SSL/TLS
You have a dilemma. You want to continue to deploy your web service but are running out of IPv4 addresses. You consider deploying multiple virtual servers that will use the same IP address. However, your thought is that you can only have one SSL certificate per IP address. How will you make your service secure? Server Name Indication (SNI) is an extension to the SSL/TLS protocol that allows the browser or client software to indicate which hostname it is attempting to connect.

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.

My Website’s SSL Certificate is Fine; Why Do Browsers Downgrade the Security Indicators For My Site?
April 1, 2015 by Rick Andrews Attack Chrome Encryption EV IETF RC4 SSL/TLS
All the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate.

Is Your SSL Server Vulnerable to a FREAK Attack?
March 11, 2015 by Bruce Morton (Entrust) Android Attack Encryption Forward Secrecy Microsoft MITM RSA SSL/TLS Vulnerability
FREAK is a new man-in-the-middle (MITM) vulnerability discovered by a group of cryptographers at INRIA, Microsoft Research and IMDEA. FREAK stands for “Factoring RSA-EXPORT Keys.” The vulnerability dates back to the 1990s, when the US government banned selling crypto software overseas, unless it used export cipher suites which involved encryption keys no longer than 512-bits. The issue is there are still some clients who let crypto be degraded from “strong RSA” to “export grade RSA”.