PKI Consortium blog

TLS 1.3 Includes Improvements to Security and Performance
April 10, 2018 by Tim Shirley Forward Secrecy IETF SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

Last month saw the final adoption, after 4 years of work, of TLS version 1.3 by the Internet Engineering Task Force (IETF). This latest iteration of the protocol for secure communications on the internet boasts several noteworthy improvements to both security and performance:

Security

All cipher suites that do not provide forward secrecy have been eliminated from TLS 1.3. This is a very important security property, because without forward secrecy, if a server’s private key is compromised today, any previously-recorded conversations with that server dating back as long as the key was in use could be decrypted. While it is possible (and highly recommended) to configure a server with TLS 1.2 to prefer (or only support) cipher suites that provide forward secrecy, under TLS 1.3 these are the only option. Other cryptographic modernizations in TLS 1.3 include the elimination of DSA, custom DHE groups, and compression.

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.

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.

Quantum Computing: Real or Exaggerated Threat to the Web PKI?
August 30, 2017 by Dean Coclin, Tim Hollebeek Encryption PKI Quantum RSA SSL/TLS Web PKI

Twenty years ago, paying your phone or electric bill involved receiving it in the mail, writing a check and mailing it back to the company. Today, that has largely been replaced by email and web-based payment submittals. All of this is secured by digital certificates and encryption, which provide privacy and authentication of information transiting the open Internet (aka Web PKI).

The web PKI is predominantly secured by RSA encryption algorithms; mathematical theorems which have been improved over time. These algorithms depend on the difficulty of computers in factoring large prime numbers in a reasonable time. The current state of binary computers would require 6.4 quadrillion (See: https://www.digicert.com/TimeTravel/math.htm) years to solve this mathematical problem and subsequently decrypt a message.

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.

Stricter Standards for SSL Server Test Coming in 2017
December 13, 2016 by Bruce Morton (Entrust) 3DES CASC Forward Secrecy RC4 SSL/TLS TLS 1.3 Vulnerability

This is a good time to offer a reminder that the CASC has a great tool for secure server testing, the SSL Server Test. The tool grades your server installation and reviews the: certificate, protocol support, key exchange and cipher strength for security against standards and known vulnerabilities.

The grading tool also provides feedback on handshake simulations with various versions of browsers and operating systems. This lets the server administrator know which implementations are supported. The test also checks the server mitigation for known vulnerabilities such as: DROWN, BEAST, POODLE and Heartbleed.

Leading Certificate Authorities and Microsoft Introduce New Standards to Protect Consumers Online
December 8, 2016 by CA Security Council CASC Code Signing FIPS HSM Identity Malware Microsoft Revocation SSL/TLS TSA

San Francisco –December 8, 2016 – the Certificate Authority Security Council (CASC), an advocacy group committed to the advancement web security, today announced the Code Signing Working Group has released new Minimum Requirements for Code Signing for use by all Certificate Authorities (CA). These requirements represent the first-ever standardized code signing guidelines. Code signing is the method of using a certificate-based digital signature to sign executables and scripts in order to verify the author’s identity and ensure that the code has not been changed or corrupted. Helping to verify software authenticity and avoid downloading malware and other malicious software is critical to protecting consumers’ online interactions. Microsoft is the first applications software vendor to adopt these guidelines, with others expected to follow.

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?