PKI Consortium blog

2018 – Looking Back, Moving Forward
January 6, 2018 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Certificate Expiry Chrome ECC Encryption Google Microsoft Mis-issued OV PDF PKI ROCA RSA SSL/TLS TLS 1.3 Vulnerability

Looking Back at 2017

2017 saw the end of SHA-1 in public trust SSL/TLS certificates and the start of Certification Authority Authorization (CAA) allowing domain owners to authorize their CA. A “Not secure” browser indication was propagated to push more websites to support HTTPS. There was also a change in the certification authority (CA) ownership with DigiCert acquiring Symantec’s SSL and related PKI business and Francisco Partners buying Comodo’s CA.

How Browser Security Indicators Can Protect You from Phishing
June 6, 2017 by Chris Bailey (Entrust), Kirk Hall (Entrust) Chrome DV Encryption EV Google Identity Phishing SSL/TLS

The media is full of stories about how phishing sites are moving rapidly to encryption using anonymous, free DV certificates they use to imitate login pages for popular sites, such as paypal.com.

As noted in the article PayPal Phishing Certificates Far More Prevalent than Previously Thought, more than 14,000 DV SSL certificates have been issued to PayPal phishing sites since the start of 2016.  Based on a random sample, 96.7% of these certificates were intended for use on phishing sites.

Certificate Transparency Deadline Moved to April 2018
May 3, 2017 by Bruce Morton (Entrust) Chrome Google IETF Policy SSL/TLS

Google just announced they will not be enforcing certificate transparency (CT) logging for all new TLS certificates until April 2018. In a previous blog post, we advised that Google provided a new policy, which required new TLS certificates to be published to the CT logs in order for the domain to be trusted by Chrome.

The reason for the delay was not clear, but Google needs to consider the following:

• Overall CT policy discussions with the major stakeholders are underway, but we are still far away from a conclusion.
• Other browsers appear to be supporting CT, but have yet to determine their policies or advance their browser code.
• The CT deployment document, RFC 6962-bis, tracked by IETF standards has not been released.
• The proposed document for CT Domain Label Redaction that addresses privacy has started, but has not been adopted or completed by the IETF.
• Sufficient, scalable, and reliable CT logs have not been deployed by the ecosystem to address the increase in requirements.

Certification authorities (CAs) as well as TLS certificate subscribers will welcome the extra time to help ensure that deployment of CT logging is efficient and seamless.

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.

The Web Is Moving From HTTP to HTTPS
November 21, 2016 by Dean Coclin Chrome Encryption Google SSL/TLS

The four letters, “http”, are known to technical and non-technical users alike as the beginning of any web address. These have been ubiquitous for many years. But things are about to change. Pretty soon, you won’t be able to go to many popular websites just by using those 4 letters. You will need to add an “s” at the end (https). Why is this happening? What are the reasons for this change?

Trust on the Public Web – The Consequences of Covert Action
November 11, 2016 by Dean Coclin Apple Chrome Firefox Mis-issued Mozilla SSL/TLS

You may have heard in the news that the Chinese Certificate Authority, WoSign, was caught backdating SHA-1 certificates to make it look like they were issued before the December 31, 2015 deadline. Why is this newsworthy?  For web-based security to remain an integral part of an ecosystem used every day by millions of people around the world, it all comes down to Trust; trust in the organization issuing the certificates, trust in the browsers that validate and display certificate information to the user, and trust by relying parties browsing web pages secured by certificates. Without trust, worldwide commerce and security on the web are at risk.

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.

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.

Trust Indication Change in Google Chrome
August 24, 2016 by Bruce Morton (Entrust) Chrome EV Google ISO SSL/TLS

Google is making security icon changes in the Chrome status bar. The changes are based on a research paper prepared by members of Google and University of California, Berkeley. The research evaluated forty icons, seven complementary strings and surveyed 1,329 people.

The goal is to make it easier for browser users to determine how secure their connection to a site is and indicate if the site is dangerous or deceptive. In addition, the icons are to indicate to people that HTTP is less secure than HTTPS. Below are representations of the old icons and the selected new icons which are to be used in Chrome.

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.