PKI Consortium blog

The Insecure Elephant in the Room
October 10, 2019 by Paul Walsh 2FA Android Attack Chrome DV Encryption EV Firefox Google Identity Malware Microsoft Mozilla Phishing Policy Revocation SSL/TLS Vulnerability W3C
The purpose of this article The purpose of this article is to demonstrate why I believe browser-based UI for website identity can make the web safer for everyone. I explain in great detail, the reasons why the UI and UX didn’t work in the past. And what’s left is only making the problem worse instead of better. Some people seem to find it difficult to consume my thoughts about the enforcement of “HTTPS EVERYWHERE”, free DV certs and the browser padlock.

Chrome Will Show Not Secure for all HTTP Sites Starting July 2018
February 15, 2018 by Bruce Morton (Entrust) Android Chrome Google HSTS Phishing SSL/TLS Vulnerability
Through 2017 and into 2018, we have seen the use of HTTPS grow substantially. Last Fall Google announced the following status: Over 68% of Chrome traffic on both Android and Windows is now protected Over 78% of Chrome traffic on both Chrome OS and Mac is now protected 81 of the top 100 sites on the web use HTTPS by default Google helped to drive this growth by implementing the “Secure” and “Not secure” status in Chrome’s status bar.

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.

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.

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”.

Public Key Pinning
August 28, 2013 by Bruce Morton (Entrust) Android Chrome Google IETF Mis-issued SHA1 SSL/TLS
The current browser-certification authority (CA) trust model allows a website owner to obtain its SSL certificate from any one of a number of CAs. That flexibility also means that a certificate mis-issued by a CA other than the authorized CA chosen by the website owner, would also be accepted as trustworthy by browsers. This problem was displayed most dramatically by the DigiNotar attack in 2011 and in a mistaken CA certificate issued by TURKTRUST in 2012.