PKI Consortium blog

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.

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. With the release of Chrome 53 on Windows, Google has changed the trust indications to introduce the circle-i.

Moving to Always on HTTPS, Part 2 of 2; Upgrading to HTTP Strict Transport Security
February 18, 2016 by Ben Wilson HSTS Mixed Content Policy SSL/TLS Vulnerability W3C
Part 1 of this blog post discussed browser security indicators and how to avoid getting warnings about mixed content on your website. (Mixed content leaves a door open that allows an attacker to snoop or inject malicious content during the browsing session.) This Part 2 discusses other technical measures to implement Always on HTTPS. As I noted previously, one of the difficulties with implementing Always on HTTPS is that content is often provided by third parties.

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.

HTTP/2 Is Speedy and Secure
April 20, 2015 by Wayne Thayer Announcement Chrome Firefox Forward Secrecy Google HSTS IETF Microsoft Mozilla SSL/TLS Vulnerability
Since we last wrote about SSL/TLS performance, there has been a lot of activity in the IETF HTTP Working Group, resulting in the February announcement that the next version of HTTP has been approved. This is big news because it means that major SSL/TLS performance improvements are on the way. Background When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616.

Extra Trips are for Frequent Flyers, Not SSL/TLS Performance
October 30, 2014 by Wayne Thayer Firefox Forward Secrecy Google HSTS OCSP Revocation RSA SSL/TLS
TLS is quickly becoming a de facto requirement for every website due to increased concerns about spying and Google’s recent move to use HTTPS as a factor in search engine ranking. In a recent article we explained how HSTS helps website operators to ensure that their site is always using TLS, but now we want to ensure that your performance isn’t sacrificed in the name of enhanced security. While the myth that TLS slows down a website has been debunked, some basic settings can make a site using TLS even faster.

Secure Your Website with HSTS
October 8, 2014 by Bruce Morton (Entrust) Attack Chrome Encryption Firefox Google HSTS Policy SSL/TLS
Is your website secure? One thing to consider is securing your website with HTTP Strict Transport Security (HSTS). Implementation of HSTS is an extension of the Always-On SSL policy. For each website you want to protect with HSTS, you must first deploy an SSL/TLS certificate (if you haven’t already), and configure that website to be accessible only via HTTPS, not via HTTP. Then you convey to HSTS-enabled browsers that your site is only available with HTTPS, by sending the HSTS header value.

2014 – Looking Back, Moving Forward
January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2
Looking Back at 2013 Protocol Attacks The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4. That being said, RC4 was also attacked, where through 16 million sessions a small amount of plaintext can be recovered.

IETF 88 – Pervasive Surveillance
November 26, 2013 by Bruce Morton (Entrust) Attack CRL Encryption Forward Secrecy HSTS IETF PKI Revocation SSL/TLS Vulnerability Web PKI
Internet Surveillance The big news at IETF 88 in Vancouver was the technical plenary on Hardening the Internet which discussed the issue of pervasive surveillance. Pervasive surveillance is a mass surveillance of an entire or a substantial fraction of a population. The surveillance is usually carried out by government, is not targeted and its occurrence may not be overt. It was noted that pervasive surveillance, of the kind revealed in the Snowden-sourced documents, constitutes a misguided and damaging attack on civic society in general and the Internet in particular.

RSA Recap – Securing Your Site
March 8, 2013 by Ben Wilson BEAST CASC Encryption Firefox Hash Function HSTS OpenSSL Policy RSA SSL/TLS TLS 1.1 TLS 1.2 Vulnerability
At RSA last week a few of us participated in panel discussions that focused on SSL/TLS. During the panel that I moderated on Friday, one theme we addressed was secure server configuration. One of CASC’s goals is to help harden existing SSL/TLS implementations against vulnerabilities—because most SSL/TLS exploits arise from suboptimal website configurations. These vulnerabilities and attacks can be mitigated or even eliminated with proper server configuration and good website design.