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
Searching for SSL Expired on Twitter is interesting.
In a recent blog post, Microsoft said it may follow Mozilla in accelerating its timetable for blocking SHA-1 signed TLS certs.
Mozilla, Microsoft and Google have all announced plans to block SHA-1 signed certs beginning in 2017, but the cost and time to create SHA-1 collisions just keeps plunging.
In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.
In an October blog post, Mozilla said it was considering a July 1, 2016 date for blocking SHA-1 signed certs,
We are re-evaluating when we should start rejecting all SHA-1 SSL certificates (regardless of when they were issued). As we said before, the current plan is to make this change on January 1, 2017. However, in light of recent attacks on SHA-1, we are also considering the feasibility of having a cut-off date as early as July 1, 2016.
Both Mozilla and Microsoft are spooked by this report that found,
Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months. By contrast, security expert Bruce Schneier previously projected (based on calculations from Jesse Walker) the SHA-1 collision cost to be ~173K$ by 2018. Note that he deems this to be within the resources of a criminal syndicate. Large corporations and governments may possess even greater resources and may not require Amazon EC2. Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 based SSL certificates by 2017 (and that SHA-1-based certificates should not be issued after 2015). In conclusion, our estimates imply SHA-1 collisions to be now (Fall 2015) within the resources of criminal syndicates, two years earlier than previously expected and one year before SHA-1 will be marked as unsafe in modern Internet browsers. This motivates our recommendations for industry standard SHA-1 to be retracted as soon as possible. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (discussion closes October 9 2015, vote closes October 16).
Peter Eckersley gave an impressive presentation about the Let’s Encrypt initiative at CCCamp15.
Let’s Encrypt is mainly known for it’s plan to offer free SSL certificates, which is cool, but the most interesting part of Eckersley’s presentation starts about 25 minutes in where he discusses how the initiative plans to address issues surrounding vulnerabilities related to the Certificate Authority system itself.
The only thing I see personally that I wish Let’s Encrypt supported right out of the gate is Wildcard Certs, but Eckersley indicates in the Q&A session that they will be looking into things like Wildcard Certs after they’re certain the basic functionality of their CA is rock solid.
This ad leaves a lot of nuance out, but is still a clever depiction of the cryptographic strength of 2048-bit cert.