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.

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. “Secure” was provided for HTTPS sites. “Not secure” was implemented progressively, first resulting for HTTP pages requiring a password or credit card number. Then resulting for HTTP pages where text input was required.

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.

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.

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”. These clients use OpenSSL, Apple’s Secure Transport and Windows Secure Channel. As such, users of Android mobiles, Apple Macs, iPhones and iPads, and Windows platforms will be impacted.

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. In these cases, certificates were issued to domains that were not approved by the domain owner. Fortunately, the problem was detected in both cases by public key pinning, which Google implemented in Chrome.