In an end-of-the-year summary, the Electronic Frontier Foundation noted that deployment of HTTPS grew dramatically in 2016,
By some measures, more than half of page loads in Firefox and in Chrome are now secured with HTTPS—the first time this has ever happened in the Web’s history. That’s right: for the first time ever, most pages viewed on the Web were encrypted! (As another year-in-review post will discuss, browsers are also experimenting with and rolling out stronger encryption technologies to better protect those connections.)
The EFF sites the availability of tools and services such as Let’s Encrypt that make obtaining and deploying certificates easier, as well as increasing pressure on companies to encrypt all traffic rather than just specific subsets.
The one troubling spot is that this increase isn’t necessarily distributed well geographically,
A caveat: data from Google shows that use of HTTPS varies significantly from country to country, remaining especially uncommon in Japan. We’ve also heard that it’s still uncommon across much of East and Southeast Asia. Next year, we’ll have to find ways to bridge those gaps.
I’ve used HTTPS on 99 percent of my server for years now, but there was a tiny portion that was not HTTPS because of a specific application that used its own non-Apache server that did not play well with the Wildcard SSL certificate I use. This year, finally, I was able to use Let’s Encrypt to flawlessly install a certificate just for that. The process for doing so was ridiculously easy and took about 10 minutes from beginning to end to configure and test.
Nice overview of the upcoming TLS 1.3 standard by Cloudflare cryptography experts Filippo Valsorda and Nick Sullivan.
This month, free Certificate Authority Let’s Encrypt issued its 3 millionth free certificate since releasing its first one on September 14, 2015.
So one day my wife wanted a website to highlight her award-winning pottery. She finds WordPress a bit cumbersome to use and after looking at a number of hosting sites settled on Squarespace. After purchasing a site there, I registered a domain name for the site and we sat down and took a look at what needed to be done to point the domain to the site.
And that’s where things got weird. Because I figured while I was reading Squarespace’s documentation about where to point the domain DNS, I’d also see what the process was for adding an SSL certificate. And the answer was shocking–there is no option to for individuals to use SSL on Squarespace sites.
When you login to Squarespace or set up an e-commerce area, Squarespace sends you to a Squarespace.com area that use Squarespace’s SSL certificate. But those are the only times that users will see SSL related to a site they have set up. As Squarespace explains (emphasis added),
Some areas of Squarespace sites are protected by SSL, including checkout for Commerce transactions and wherever you log into your site. However, SSL isn’t currently available for other pages.
We don’t offer the ability to install custom SSL certificates at this time.
This is crazy, and potentially dangerous. Without SSL, browsing Squarespace sites is subject to snooping by third parties. Attackers could potentially perform man-in-the-middle style attacks by intercepting the non-encrypted traffic and injecting malicious code.
One of Squarespace’s competitors, WordPress.com not only supports SSL for the millions of blogs/sites it hosts, but just announced it was using Let’s Encrypt to offer free SSL to every single custom domain on its network.
That Squarespace continues to expose both its visitors and its customers to these sort of risks is inexcusable.
I ran into a ton of problems recently trying to configure SSL on my server’s Exim/Dovecot services.
To solve them, I relied on the excellent CheckTLS.com to give me detailed information about how my server’s security was failing. I probably wouldn’t have been able to troubleshoot my particular problems without this.
In my case, it turned out to be problems with the intermediate certificate. I tried a number of ways to fix this before stumbling upon an answer that I never would have guessed. I kept grabbing the intermediate certificate from my CA, but no matter what I tried it would not authenticate.
I was able to get it to work, however, by copying the content of the CA cert into the exim.cert file using:
$ echo '' >> /etc/exim.cert
$ cat /etc/exim.cacert >> /etc/exim.cert
Oh yeah, and don’t forget to restart the Dovecot service:
Searching for SSL Expired on Twitter is interesting.